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_ADDRESSMAC_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

也可以看看: