Docs4dev
Docs
spring-cloud / Finchley.SR2 / reference / multi_vault.config.authentication.html

103. 身份验证方法

不同组织对安全性和身份验证有不同的要求。 Vault 通过提供多种身份验证方法来反映这种需求。 Spring Cloud Vault 支持令牌和 AppId 身份验证。

103.1 令牌认证

令牌是 Vault 中验证的核心方法。令牌认证需要使用Bootstrap Application Context提供静态令牌。

令牌认证是默认的认证方法。如果披露了令牌，则非预期的一方可以访问 Vault 并可以访问预期的客户端的秘密。

示例 103.1. bootstrap.yml

spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

  • authentication将此 value 设置为TOKEN选择令牌验证方法

  • token _set 要使用的静态令牌

另见：Vault 文档：令牌

103.2 AppId 身份验证

Vault 支持由两个难以猜测的令牌组成的AppId身份验证。 AppId 默认为静态配置的spring.application.name。第二个标记是 UserId，它是由 application 确定的部分，通常与运行时环境相关。 IP 地址，Mac 地址或 Docker 容器 name 就是很好的例子。 Spring Cloud Vault Config 支持 IP 地址，Mac 地址和静态 UserId(e.g. 通过 System properties 提供)。 IP 和 Mac 地址表示为 Hex-encoded SHA256 哈希。

IP address-based UserId 使用本地 host 的 IP 地址。

示例 103.2. bootstrap.yml 使用 SHA256 IP-Address UserId 的

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: IP_ADDRESS

  • authentication将此 value 设置为APPID选择 AppId 身份验证方法

  • app-id-path _set 要使用的 AppId 挂载的路径

  • user-id sets UserId 方法。可能的值是IP_ADDRESS，MAC_ADDRESS或 class name 实现自定义AppIdUserIdMechanism

从命令 line 生成 IP 地址 UserId 的相应命令是：

$ echo -n 192.168.99.1 | sha256sum

包括echo的 line break 会导致不同的 hash value，因此请确保包含-n flag。

Mac address-based UserId 从 localhost-bound 设备获取其网络设备。 configuration 还允许指定network-interface提示来选择正确的设备。 network-interface的 value 是可选的，可以是接口 name 或接口索引(0-based)。

示例 103.3. bootstrap.yml 使用 SHA256 Mac-Address UserId 的

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: MAC_ADDRESS
        network-interface: eth0
  • network-interface sets 网络接口获取物理地址

从命令 line 生成 IP 地址 UserId 的相应命令是：

$ echo -n 0AFEDE1234AC | sha256sum

Mac 地址指定为大写且没有冒号。包括echo的 line break 会导致不同的 hash value，因此请确保包含-n flag。

103.2.1 自定义 UserId

UserId 生成是一种开放机制。您可以将spring.cloud.vault.app-id.user-id设置为任何 string，配置的 value 将用作静态 UserId。

更高级的方法允许您将spring.cloud.vault.app-id.user-id设置为类名。此 class 必须位于 classpath 上，并且必须实现org.springframework.cloud.vault.AppIdUserIdMechanism接口和createUserId方法。 Spring Cloud Vault 将通过调用createUserId来获取 UserId，每次使用 AppId 进行身份验证以获取令牌。

示例 103.4. bootstrap.yml

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: com.examlple.MyUserIdMechanism

示例 103.5. MyUserIdMechanism.java

public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {
    String userId = ...
    return userId;
  }
}

另见：Vault 文档：使用 App ID auth 后端

103.3 AppRole 身份验证

AppRole用于机器身份验证，例如已弃用(自 Vault 0.6.1)第 103.2 节，“AppId 身份验证”。 AppRole 身份验证包含两个难以猜测的(secret)令牌：RoleId 和 SecretId。

Spring Vault 支持各种 AppRole 场景(push/pull 模式和包装)。

RoleId 和可选的 SecretId 必须由 configuration 提供，Spring Vault 不会查找这些或创建自定义的 SecretId。

示例 103.6. bootstrap.yml with AppRole authentication properties

spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

所需的 configuration 详细信息支持以下方案：

表格 1_.组态
方法 ****角色 ID ****的 SecretID **** ROLENAME ****令牌
提供 RoleId/SecretId 提供 提供
提供没有 SecretId 的 RoleId 提供
提供了 RoleId，Pull SecretId 提供 提供 提供 提供
提供 RoleId，提供 SecretId 提供 提供 提供
全拉模式 提供 提供
包裹 提供
包含 RoleId，提供了 SecretId 提供 提供
提供了 RoleId，包含了 SecretId 提供 提供

表格 1_.Pull/Push/Wrapped Matrix
****角色 ID ****的 SecretID 支持的
提供 提供 ✅
提供 拉 ✅
提供 包裹 ✅
提供 缺席 ✅
拉 提供 ✅
拉 拉 ✅
拉 包裹 ❌
拉 缺席 ❌
包裹 提供 ✅
包裹 拉 ❌
包裹 包裹 ✅
包裹 缺席 ❌

您可以通过在 bootstrap context 中提供已配置的AppRoleAuthentication bean 来使用 push/pull/wrapped 模式的所有组合。 Spring Cloud Vault 无法从 configuration properties 派生所有可能的 AppRole 组合。

AppRole 身份验证仅限于使用 reactive Infrastructure 的简单拉模式。尚不支持全拉模式。使用 Spring Cloud Vault 与 Spring WebFlux 堆栈启用 Vault 的 reactive auto-configuration，可以通过设置spring.cloud.vault.reactive.enabled=false来禁用它。

示例 103.7. bootstrap.yml 与所有 AppRole 身份验证 properties

spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
        secret-id: 1696536f-1976-73b1-b241-0b4213908d39
        role: my-role
        app-role-path: approle

  • role-id sets RoleId。

  • secret-id sets the SecretId。如果配置 AppRole 而不需要 SecretId(参见bind_secret_id)，则可以省略 SecretId。

  • role：设置拉模式的 AppRole name。

  • app-role-path _set 要使用的认证认证安装的路径。

另见：Vault 文档：使用 AppRole 身份验证后端

103.4 AWS-EC2 认证

aws-ec2 auth 后端为 AWS EC2 实例提供安全的引入机制，允许自动检索 Vault 令牌。与大多数 Vault 身份验证后端不同，此后端不需要 first-deploying 或配置 security-sensitive 凭据(令牌，username/password，客户端证书，etc.)。相反，它将 AWS 视为可信第三方，并使用加密签名的动态元数据信息，该信息唯一代表每个 EC2 实例。

示例 103.8. bootstrap.yml 使用 AWS-EC2 身份验证

spring.cloud.vault:
    authentication: AWS_EC2

AWS-EC2 authentication 默认情况下启用 nonce 遵循 Trust On First Use(TOFU)原则。任何能够访问 PKCS#7 身份元数据的非预期方都可以对 Vault 进行身份验证。

在第一次登录期间，Spring Cloud Vault 生成一个存在于 auth 后端的 nonce，除了实例 Id。 Re-authentication 要求发送相同的随机数。任何其他方都没有 nonce 并且可以在 Vault 中发出警报以进行进一步调查。

nonce 保存在 memory 中，并在 application restart 期间丢失。您可以使用spring.cloud.vault.aws-ec2.nonce配置静态随机数。

AWS-EC2 身份验证角色是可选的，默认为 AMI。您可以通过设置spring.cloud.vault.aws-ec2.role property 来配置身份验证角色。

示例 103.9. bootstrap.yml 配置角色

spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server

示例 103.10. bootstrap.yml 与所有 AWS EC2 身份验证 properties

spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server
        aws-ec2-path: aws-ec2
        identity-document: http://...
        nonce: my-static-nonce

  • authentication将此 value 设置为AWS_EC2选择 AWS EC2 身份验证方法

  • role sets 设置正在尝试登录的角色的 name。

  • aws-ec2-path 设置要使用的 AWS EC2 装载的路径

  • identity-document sets PKCS#7 AWS EC2 身份文档的 URL

  • nonce用于 AWS-EC2 身份验证。空 nonce 默认为 nonce 生成

另见：Vault 文档：使用 aws auth 后端

103.5 AWS-IAM 认证

AWS后端为 AWS IAM 角色提供安全的身份验证机制，允许基于 running application 的当前 IAM 角色使用 vault 进行自动身份验证。与大多数 Vault 身份验证后端不同，此后端不需要 first-deploying 或配置 security-sensitive 凭据(令牌，username/password，客户端证书，etc.)。相反，它将 AWS 视为可信第三方，并使用由呼叫者签署的 4 条信息与他们的用于验证调用方确实正在使用该 IAM 角色的 IAM 凭据。

application 正在运行的当前 IAM 角色会自动计算。如果您在 AWS ECS 上运行 application，则 application 将使用分配给 running 容器的 ECS 任务的 IAM 角色。如果您在 EC2 实例上运行 application，那么使用的 IAM 角色将是分配给 EC2 实例的角色。

使用 AWS-IAM 身份验证时，您必须在 Vault 中创建角色并将其分配给您的 IAM 角色。空role默认为友方 name 当前 IAM 角色。

示例 103.11. bootstrap.yml with required AWS-IAM Authentication properties

spring.cloud.vault:
    authentication: AWS_IAM

示例 103.12. bootstrap.yml 所有 AWS-IAM 认证 properties

spring.cloud.vault:
    authentication: AWS_IAM
    aws-iam:
        role: my-dev-role
        aws-path: aws
        server-id: some.server.name

  • role sets 设置正在尝试登录的角色的 name。这应该与您的 IAM 角色绑定。如果未提供，则当前 IAM 用户的友好 name 将用作 vault 角色。

  • aws-path 设置要使用的 AWS 挂载的路径

  • server-id _set value 用于X-Vault-AWS-IAM-Server-ID标头，防止某些类型的重播攻击。

AWS-IAM 需要 AWS Java SDK 依赖关系(com.amazonaws:aws-java-sdk-core)作为身份验证 implementation 使用 AWS SDK 类型进行凭据和请求签名。

另见：Vault 文档：使用 aws auth 后端

103.6 TLS 证书身份验证

cert auth 后端允许使用由 CA 或 self-signed 签名的 SSL/TLS client 证书进行身份验证。

要启用cert身份验证，您需要：

示例 103.13. bootstrap.yml

spring.cloud.vault:
    authentication: CERT
    ssl:
        key-store: classpath:keystore.jks
        key-store-password: changeit
        cert-auth-path: cert

另见：Vault 文档：使用 Cert auth 后端

103.7 Cubbyhole 认证

Cubbyhole 身份验证使用 Vault primitives 来提供安全的身份验证工作流程。 Cubbyhole 身份验证使用令牌作为主要登录方法。一个短暂的令牌用于从 Vault 的 Cubbyhole secret 后端获取第二个登录 VaultToken。登录令牌通常是 longer-lived 并用于与 Vault 交互。登录令牌将从存储在/cubbyhole/response的包装响应中检索。

创建包装的令牌

响应包装创建令牌需要 Vault 0.6.0 或更高版本。

示例 103.14. 创建和存储令牌

$ vault token-create -wrap-ttl="10m"
Key                            Value
---                            -----
wrapping_token:                397ccb93-ff6c-b17b-9389-380b01ca2645
wrapping_token_ttl:            0h10m0s
wrapping_token_creation_time:  2016-09-18 20:29:48.652957077 +0200 CEST
wrapped_accessor:              46b6aebb-187f-932a-26d7-4f3d86a68319

示例 103.15. bootstrap.yml

spring.cloud.vault:
    authentication: CUBBYHOLE
    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

也可以看看：

103.8 Kubernetes 认证

Kubernetes 身份验证机制(自 Vault 0.8.3 以来)允许使用 Kubernetes 服务帐户令牌对 Vault 进行身份验证。身份验证基于角色，角色绑定到服务帐户 name 和命名空间。

包含 pod 的服务帐户的 JWT 令牌的文件将自动安装在/var/run/secrets/kubernetes.io/serviceaccount/token。

示例 103.16. bootstrap.yml 与所有 Kubernetes 认证 properties

spring.cloud.vault:
    authentication: KUBERNETES
    kubernetes:
        role: my-dev-role
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • role sets the Role。

  • service-account-token-file _set 包含 Kubernetes 服务帐户令牌的文件的位置。默认为/var/run/secrets/kubernetes.io/serviceaccount/token。

也可以看看：