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

令牌身份验证

令牌是保险柜中身份验证的核心方法。 令牌身份验证需要使用配置提供静态令牌。 作为回退,还可以从中检索令牌,该令牌是Vault CLI用于缓存令牌的默认位置。~/.vault-token

令牌身份验证是默认身份验证方法。 如果令牌被泄露,则意外方将获得对保险柜的访问权限,并可以访问目标客户端的机密。
application.yml
spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000
  • authentication设置此值以选择令牌身份验证方法TOKEN

  • token设置要使用的静态令牌。如果缺少或为空,则将尝试从 ~/.vault-token 中检索令牌。

另请参阅:

令牌身份验证是默认身份验证方法。 如果令牌被泄露,则意外方将获得对保险柜的访问权限,并可以访问目标客户端的机密。

Vault Agent 身份验证

自 0.11.0 版起,Vault 代理附带了 sidecar 实用程序。Vault Agent 通过其自动身份验证功能实现了 Spring Vault 的功能。 应用程序可以依靠在 上运行的 Vault Agent 来重用缓存的会话凭据。 Spring Vault 可以在没有标头的情况下发送请求。 禁用 Spring Vault 的身份验证基础结构以禁用客户端身份验证和会话管理。SessionManagerlocalhostX-Vault-Token

application.yml
spring.cloud.vault:
    authentication: NONE
  • authentication将此值设置为 disables 和 。NONEClientAuthenticationSessionManager

另请参阅:Vault 文档:代理

AppId 身份验证

保险柜支持由两个难以猜测的令牌组成的 AppId 身份验证。 AppId 默认为静态配置。 第二个标记是 UserId,它是由应用程序确定的部分,通常与运行时环境相关。 IP 地址、Mac 地址或 Docker 容器名称就是很好的例子。 Spring Cloud Vault Config支持IP地址,Mac地址和静态UserId(例如,通过系统属性提供)。 IP 和 Mac 地址表示为十六进制编码的 SHA256 哈希。spring.application.name

基于 IP 地址的 UserId 使用本地主机的 IP 地址。

application.yml使用 SHA256 IP 地址 UserId
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: IP_ADDRESS
  • authentication设置此值以选择 AppId 身份验证方法APPID

  • app-id-path设置要使用的 AppId 装载的路径

  • user-id设置 UserId 方法。 可能的值是 ,或实现自定义的类名IP_ADDRESSMAC_ADDRESSAppIdUserIdMechanism

从命令行生成 IP 地址 UserId 的相应命令为:

$ echo -n 192.168.99.1 | sha256sum
将潜在客户的换行符包含在不同的哈希值中,因此请确保包含该标志。echo-n

基于 Mac 地址的 UserId 从 localhost 绑定的设备获取其网络设备。 该配置还允许指定提示以选择正确的设备。 的值是可选的,可以是接口名称或接口索引(从 0 开始)。network-interfacenetwork-interface

application.yml使用 SHA256 Mac 地址 UserId
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: MAC_ADDRESS
        network-interface: eth0
  • network-interface设置网络接口以获取物理地址

从命令行生成 IP 地址 UserId 的相应命令为:

$ echo -n 0AFEDE1234AC | sha256sum
Mac 地址指定为大写,不带冒号。 将潜在客户的换行符包含在不同的哈希值中,因此请确保包含该标志。echo-n

自定义用户 ID

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

更高级的方法允许您设置为类名。 此类必须位于类路径上,并且必须实现接口和方法。 Spring Cloud Vault 每次使用 AppId 进行身份验证时都会调用 UserId 来获取 UserId。spring.cloud.vault.app-id.user-idorg.springframework.cloud.vault.AppIdUserIdMechanismcreateUserIdcreateUserId

application.yml
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: com.examlple.MyUserIdMechanism
MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {
    String userId = ...
    return userId;
  }
}
将潜在客户的换行符包含在不同的哈希值中,因此请确保包含该标志。echo-n
Mac 地址指定为大写,不带冒号。 将潜在客户的换行符包含在不同的哈希值中,因此请确保包含该标志。echo-n

AppRole 身份验证

AppRole 用于计算机身份验证,类似于已弃用的(自 Vault 0.6.1 起)AppId 身份验证。 AppRole 身份验证由两个难以猜测的(机密)令牌组成:RoleId 和 SecretId。

Spring Vault 支持各种 AppRole 方案(推/拉模式和包装模式)。

RoleId 和可选的 SecretId 必须由配置提供,Spring Vault 不会查找它们或创建自定义 SecretId。

使用 AppRole 身份验证属性进行application.yml
spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

支持以下方案以及所需的配置详细信息:

表 1.配置

方法

角色 Id

SecretId

角色名称

令 牌

提供 RoleId/SecretId

提供

提供

提供不带 SecretId 的 RoleId

提供

提供 RoleId、Pull SecretId

提供

提供

提供

拉取 RoleId,提供 SecretId

提供

提供

提供

全拉模式

提供

提供

包裹

提供

包装的 RoleId,提供 SecretId

提供

提供

提供 RoleId,包装 SecretId

提供

提供

表 2.拉/推/包矩阵

角色 Id

SecretId

支持

提供

提供

提供

提供

包裹

提供

缺席

提供

包裹

缺席

包裹

提供

包裹

包裹

包裹

包裹

缺席

通过在上下文中提供已配置的 Bean,您仍然可以使用推/拉/包装模式的所有组合。 Spring Cloud Vault 无法从配置属性派生所有可能的 AppRole 组合。AppRoleAuthentication
AppRole 身份验证仅限于使用反应式基础结构的简单拉取模式。 尚不支持完全拉取模式。 将 Spring Cloud Vault 与 Spring WebFlux 堆栈一起使用可启用 Vault 的反应式自动配置,该配置可以通过设置 来禁用。spring.cloud.vault.reactive.enabled=false
application.yml所有 AppRole 身份验证属性
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设置 RoleId。

  • secret-id设置 SecretId。 如果在不需要 SecretId 的情况下配置了 AppRole,则可以省略 SecretId(请参阅)。bind_secret_id

  • role:设置拉取模式的 AppRole 名称。

  • app-role-path设置要使用的 AppRole 身份验证挂载的路径。

表 1.配置

方法

角色 Id

SecretId

角色名称

令 牌

提供 RoleId/SecretId

提供

提供

提供不带 SecretId 的 RoleId

提供

提供 RoleId、Pull SecretId

提供

提供

提供

拉取 RoleId,提供 SecretId

提供

提供

提供

全拉模式

提供

提供

包裹

提供

包装的 RoleId,提供 SecretId

提供

提供

提供 RoleId,包装 SecretId

提供

提供

表 2.拉/推/包矩阵

角色 Id

SecretId

支持

提供

提供

提供

提供

包裹

提供

缺席

提供

包裹

缺席

包裹

提供

包裹

包裹

包裹

包裹

缺席

通过在上下文中提供已配置的 Bean,您仍然可以使用推/拉/包装模式的所有组合。 Spring Cloud Vault 无法从配置属性派生所有可能的 AppRole 组合。AppRoleAuthentication
AppRole 身份验证仅限于使用反应式基础结构的简单拉取模式。 尚不支持完全拉取模式。 将 Spring Cloud Vault 与 Spring WebFlux 堆栈一起使用可启用 Vault 的反应式自动配置,该配置可以通过设置 来禁用。spring.cloud.vault.reactive.enabled=false

AWS-EC2 身份验证

aws-ec2 身份验证后端为 AWS EC2 实例提供安全引入机制,允许自动检索文件库令牌。 与大多数保险柜身份验证后端不同,此后端不需要首先部署或配置对安全敏感的凭据(令牌、用户名/密码、客户端证书等)。 相反,它将 AWS 视为受信任的第三方,并使用唯一表示每个 EC2 实例的加密签名动态元数据信息。

application.yml使用 AWS-EC2 身份验证
spring.cloud.vault:
    authentication: AWS_EC2

默认情况下,AWS-EC2 身份验证使 nonce 遵循首次使用信任 (TOFU) 原则。 任何获得PKCS#7身份元数据访问权限的意外参与方都可以针对Vault进行身份验证。

在首次登录期间,Spring Cloud Vault 会生成一个随机数,该随机数存储在身份验证后端的实例 ID 旁边。 重新身份验证需要发送相同的随机数。 任何其他方都没有随机数,可以在保险柜中发出警报以进行进一步调查。

随机数保存在内存中,并在应用程序重新启动期间丢失。 您可以使用 来配置静态随机数。spring.cloud.vault.aws-ec2.nonce

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

具有已配置角色的application.yml
spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server
application.yml所有 AWS EC2 身份验证属性
spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server
        aws-ec2-path: aws-ec2
        identity-document: http://...
        nonce: my-static-nonce
  • authentication设置此值以选择 AWS EC2 身份验证方法AWS_EC2

  • role设置尝试登录的角色的名称。

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

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

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

AWS-IAM 身份验证

aws 后端为 AWS IAM 角色提供安全身份验证机制,允许根据正在运行的应用程序的当前 IAM 角色使用文件库进行自动身份验证。 与大多数保险柜身份验证后端不同,此后端不需要首先部署或配置对安全敏感的凭据(令牌、用户名/密码、客户端证书等)。 相反,它将 AWS 视为受信任的第三方,并使用调用方及其 IAM 凭证签名的 4 条信息来验证调用方是否确实在使用该 IAM 角色。

系统会自动计算运行应用程序的当前 IAM 角色。 如果您在 AWS ECS 上运行应用程序,则应用程序将使用分配给正在运行的容器的 ECS 任务的 IAM 角色。 如果您在 EC2 实例上裸运行应用程序,则使用的 IAM 角色将是分配给 EC2 实例的角色。

使用 AWS-IAM 身份验证时,您必须在文件库中创建一个角色,并将其分配给您的 IAM 角色。 默认为空的友好名称为当前 IAM 角色。role

application.yml具有必需的 AWS-IAM 身份验证属性
spring.cloud.vault:
    authentication: AWS_IAM
application.yml所有 AWS-IAM 身份验证属性
spring.cloud.vault:
    authentication: AWS_IAM
    aws-iam:
        region: aws-global
        role: my-dev-role
        aws-path: aws
        server-name: some.server.name
        endpoint-uri: https://sts.eu-central-1.amazonaws.com
  • region设置 AWS 区域的名称。如果未提供,则区域将由 AWS 默认值确定。

  • role设置尝试登录的角色的名称。 这应该绑定到您的 IAM 角色。 如果未提供,则当前 IAM 用户的友好名称将用作文件库角色。

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

  • server-name设置用于防止某些类型的重放攻击的标头的值。X-Vault-AWS-IAM-Server-ID

  • endpoint-uri设置用于用于参数的 AWS STS API 的值。iam_request_url

AWS-IAM 需要 AWS Java 开发工具包 v2 依赖项 (),因为身份验证实施使用 AWS 开发工具包类型进行凭证和请求签名。software.amazon.awssdk:auth

Azure MSI 身份验证

azure 身份验证后端为 Azure VM 实例提供安全的引入机制,允许自动检索保管库令牌。 与大多数保险柜身份验证后端不同,此后端不需要首先部署或配置对安全敏感的凭据(令牌、用户名/密码、客户端证书等)。 相反,它将 Azure 视为受信任的第三方,并使用可绑定到 VM 实例的托管服务标识和实例元数据信息。

application.yml所需的 Azure 身份验证属性
spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
application.yml所有 Azure 身份验证属性
spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
        azure-path: azure
        metadata-service: http://169.254.169.254/metadata/instance…
        identity-token-service: http://169.254.169.254/metadata/identity…
  • role设置尝试登录的角色的名称。

  • azure-path设置要使用的 Azure 装载的路径

  • metadata-service设置用于访问实例元数据服务的 URI

  • identity-token-service设置用于访问标识令牌服务的 URI

Azure MSI 身份验证从实例元数据服务获取有关虚拟机的环境详细信息(订阅 ID、资源组、VM 名称)。 Vault 服务器的资源 ID 默认为 。 要更改此设置,请进行相应的设置。vault.hashicorp.comspring.cloud.vault.azure-msi.identity-token-service

另请参阅:

TLS 证书身份验证

身份验证后端允许使用由 CA 签名或自签名的 SSL/TLS 客户端证书进行身份验证。cert

若要启用身份验证,需要:cert

  1. 使用SSL,请参阅Vault Client SSL配置

  2. 配置包含客户机证书和私钥的 JavaKeystore

  3. spring.cloud.vault.authenticationCERT

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

Cubbyhole 身份验证

Cubbyhole 身份验证使用 Vault 基元来提供安全的身份验证工作流。 Cubbyhole 身份验证使用令牌作为主要登录方法。 临时令牌用于从 Vault 的 Cubbyhole 秘密后端获取第二个登录 VaultToken。 登录令牌的有效期通常较长,用于与保险柜进行交互。 登录令牌将从存储在 的包装响应中检索。/cubbyhole/response

创建包装的令牌

用于创建令牌的响应包装需要 Vault 0.6.0 或更高版本。
创建和存储令牌
$ 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
application.yml
spring.cloud.vault:
    authentication: CUBBYHOLE
    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

另请参阅:

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

GCP-GCE 身份验证

gcp 身份验证后端允许使用现有的 GCP (Google Cloud Platform) IAM 和 GCE 凭证登录保险柜。

GCP GCE(Google Compute Engine)身份验证以 JSON Web 令牌 (JWT) 的形式为服务帐号创建签名。 Compute Engine 实例的 JWT 是使用实例标识从 GCE 元数据服务获取的。 此 API 创建可用于确认实例身份的 JSON Web 令牌。

与大多数保险柜身份验证后端不同,此后端不需要首先部署或配置对安全敏感的凭据(令牌、用户名/密码、客户端证书等)。 相反,它将 GCP 视为受信任的第三方,并使用唯一表示每个 GCP 服务帐户的加密签名动态元数据信息。

application.yml具有必需的 GCP-GCE 身份验证属性
spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        role: my-dev-role
application.yml所有 GCP-GCE 身份验证属性
spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        gcp-path: gcp
        role: my-dev-role
        service-account: [email protected]
  • role设置尝试登录的角色的名称。

  • gcp-path设置要使用的 GCP 挂载的路径

  • service-account允许将服务帐户 ID 覆盖为特定值。 默认为服务帐户。default

另请参阅:

GCP-IAM 身份验证

gcp 身份验证后端允许使用现有的 GCP (Google Cloud Platform) IAM 和 GCE 凭证登录保险柜。

GCP IAM 身份验证以 JSON Web 令牌 (JWT) 的形式为服务账户创建签名。 服务帐号的 JWT 是通过调用 GCP IAM 的 projects.serviceAccounts.signJwt API 获取的。调用方根据 GCP IAM 进行身份验证,从而证明其身份。 此保险柜后端将 GCP 视为受信任的第三方。

IAM 凭证可以从运行时环境(特别是 GOOGLE_APPLICATION_CREDENTIALS 环境变量、Google Compute 元数据服务)获取,也可以从外部以 e.g. JSON 或 base64 编码的形式提供。 JSON 是首选形式,因为它带有调用所需的项目 ID 和服务帐户标识符。projects.serviceAccounts.signJwt

application.yml具有必需的 GCP-IAM 身份验证属性
spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        role: my-dev-role
application.yml所有 GCP-IAM 身份验证属性
spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        credentials:
            location: classpath:credentials.json
            encoded-key: e+KApn0=
        gcp-path: gcp
        jwt-validity: 15m
        project-id: my-project-id
        role: my-dev-role
        service-account-id: [email protected]
  • role设置尝试登录的角色的名称。

  • credentials.location包含 JSON 格式的 Google 凭据的凭据资源的路径。

  • credentials.encoded-keyOAuth2 帐户私钥的 base64 编码内容,采用 JSON 格式。

  • gcp-path设置要使用的 GCP 挂载的路径

  • jwt-validity配置 JWT 令牌有效性。 默认值为 15 分钟。

  • project-id允许将项目 ID 覆盖为特定值。 默认为从获取的凭据中获取的项目 ID。

  • service-account允许将服务帐户 ID 覆盖为特定值。 默认为从获取的凭据中的服务帐户。

GCP IAM 身份验证需要 Google Cloud Java SDK 依赖项 ( 和 ),因为身份验证实施使用 Google API 进行凭证和 JWT 签名。com.google.apis:google-api-services-iamcom.google.auth:google-auth-library-oauth2-http

Google 凭据需要 OAuth 2 令牌来维护令牌生命周期。 因此,所有 API 都是同步的,不支持响应式使用所需的 API。GcpIamAuthenticationAuthenticationSteps

另请参阅:

Google 凭据需要 OAuth 2 令牌来维护令牌生命周期。 因此,所有 API 都是同步的,不支持响应式使用所需的 API。GcpIamAuthenticationAuthenticationSteps

Kubernetes 身份验证

Kubernetes 身份验证机制(从 Vault 0.8.3 开始)允许使用 Kubernetes 服务帐户令牌向 Vault 进行身份验证。 身份验证基于角色,角色绑定到服务帐户名称和命名空间。

包含容器服务帐户的 JWT 令牌的文件会自动挂载到 。/var/run/secrets/kubernetes.io/serviceaccount/token

application.yml所有 Kubernetes 身份验证属性
spring.cloud.vault:
    authentication: KUBERNETES
    kubernetes:
        role: my-dev-role
        kubernetes-path: kubernetes
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token
  • role设置角色。

  • kubernetes-path设置要使用的 Kubernetes 挂载的路径。

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

另请参阅:

Pivotal CloudFoundry 身份验证

pcf 身份验证后端为在 Pivotal 的 CloudFoundry 实例中运行的应用程序提供了安全的引入机制,允许自动检索 Vault 令牌。 与大多数Vault身份验证后端不同,此后端不需要首先部署或配置对安全敏感的凭据(令牌、用户名/密码、客户端证书等),因为身份配置由PCF本身处理。 相反,它将 PCF 视为受信任的第三方,并使用托管实例标识。

application.yml具有必需的 PCF 身份验证属性
spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
application.yml所有 PCF 身份验证属性
spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
        pcf-path: path
        instance-certificate: /etc/cf-instance-credentials/instance.crt
        instance-key: /etc/cf-instance-credentials/instance.key
  • role设置尝试登录的角色的名称。

  • pcf-path设置要使用的 PCF 挂载的路径。

  • instance-certificate设置 PCF 实例身份证书的路径。 默认为 env 变量。${CF_INSTANCE_CERT}

  • instance-key设置 PCF 实例身份密钥的路径。 默认为 env 变量。${CF_INSTANCE_KEY}

PCF 身份验证要求 BouncyCastle (bcpkix-jdk15on) 位于 RSA PSS 签名的类路径上。
PCF 身份验证要求 BouncyCastle (bcpkix-jdk15on) 位于 RSA PSS 签名的类路径上。

ACL 要求

本节介绍Spring Vault访问哪些路径,以便您可以从所需的功能中派生策略声明。

能力 关联的 HTTP 谓词

创造

POST/PUT

GET

更新

POST/PUT

删除

DELETE

列表

LIST (GET)

能力 关联的 HTTP 谓词

创造

POST/PUT

GET

更新

POST/PUT

删除

DELETE

列表

LIST (GET)

认证

登录:POST auth/$authMethod/login

KeyValue 挂载发现

GET sys/internal/ui/mounts/$mountPath

SecretLeaseContainer

SecretLeaseContainer根据配置的租约终结点使用不同的路径。

LeaseEndpoints.Legacy

  • 撤销:PUT sys/revoke

  • 更新:PUT sys/renew

LeaseEndpoints.Leases (SysLeases)

  • 撤销:PUT sys/leases/revoke

  • 更新:PUT sys/leases/renew

会话管理

  • 代币查找:GET auth/token/lookup-self

  • 更新:POST auth/token/renew-self

  • 撤回:POST auth/token/revoke-self