身份验证方法

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

令牌身份验证

令牌是 Vault 中身份验证的核心方法。令牌身份验证需要使用配置提供静态令牌。作为后备，令牌也可以从 ~/.vault-token 中检索，这是 Vault CLI 用于缓存令牌的默认位置。

令牌身份验证是默认的身份验证方法。如果令牌被泄露给意外方，则该方可以访问 Vault 并访问目标客户端的密钥。
application.yml
spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

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

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

另请参阅

Vault Agent 身份验证

Vault 从 0.11.0 版本开始提供了一个名为 Vault Agent 的 sidecar 实用程序。Vault Agent 使用其自动身份验证功能实现了 Spring Vault 的 SessionManager 的功能。应用程序可以通过依赖于在 localhost 上运行的 Vault Agent 来重用缓存的会话凭据。Spring Vault 可以发送请求而不带 X-Vault-Token 标头。禁用 Spring Vault 的身份验证基础设施以禁用客户端身份验证和会话管理。

application.yml
spring.cloud.vault:
    authentication: NONE

  • authentication 将此值设置为 NONE 将禁用 ClientAuthentication 和 SessionManager。

另请参阅：Vault 文档：Agent

AppId 身份验证

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

基于 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_ADDRESS、MAC_ADDRESS 或实现自定义 AppIdUserIdMechanism 的类名

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

$ echo -n 192.168.99.1 | sha256sum
包含 echo 的换行符会导致不同的哈希值，因此请确保包含 -n 标志。

基于 Mac 地址的 UserId 从本地主机绑定的设备获取其网络设备。配置还允许指定 network-interface 提示以选择正确的设备。network-interface 的值是可选的，可以是接口名称或接口索引（从 0 开始）。

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 标志。

自定义 UserId

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

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

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;
  }
}

另请参阅：Vault 文档：使用 App ID 身份验证后端

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. 配置

方法

RoleId

SecretId

RoleName

令牌

提供的 RoleId/SecretId

提供

提供

提供 RoleId 而没有 SecretId

提供

提供 RoleId，拉取 SecretId

提供

提供

提供

拉取 RoleId，提供 SecretId

提供

提供

提供

完全拉取模式

提供

提供

包装

提供

包装 RoleId，提供 SecretId

提供

提供

提供 RoleId，包装 SecretId

提供

提供
表 2. 拉取/推送/包装矩阵

RoleId

SecretId

支持

提供

提供

✅

提供

拉取

✅

提供

包装

✅

提供

不存在

✅

拉取

提供

✅

拉取

拉取

✅

拉取

包装

❌

拉取

不存在

❌

包装

提供

✅

包装

拉取

❌

包装

包装

✅

包装

不存在

❌
您仍然可以通过在上下文中提供配置的 AppRoleAuthentication bean 来使用推/拉/包装模式的所有组合。Spring Cloud Vault 无法从配置属性中推导出所有可能的 AppRole 组合。
AppRole 身份验证仅限于使用反应式基础设施的简单拉取模式。尚不支持完全拉取模式。将 Spring Cloud Vault 与 Spring WebFlux 堆栈一起使用将启用 Vault 的反应式自动配置，可以通过将 spring.cloud.vault.reactive.enabled=false 设置为禁用。
包含所有 AppRole 身份验证属性的 application.yml
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。如果 AppRole 配置为不需要 SecretId，则可以省略 SecretId（请参阅 bind_secret_id）。

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

  • app-role-path 设置要使用的 approle 认证挂载路径。

另请参阅：Vault 文档：使用 AppRole 认证后端

AWS-EC2 认证

aws-ec2 认证后端为 AWS EC2 实例提供了一种安全的引入机制，允许自动检索 Vault 令牌。与大多数 Vault 认证后端不同，此后端不需要首先部署或预配安全敏感的凭据（令牌、用户名/密码、客户端证书等）。相反，它将 AWS 视为可信第三方，并使用对唯一表示每个 EC2 实例的加密签名动态元数据信息。

使用 AWS-EC2 认证的 application.yml
spring.cloud.vault:
    authentication: AWS_EC2

AWS-EC2 认证默认启用随机数以遵循“首次信任”（TOFU）原则。任何意外获得 PKCS#7 身份元数据访问权限的方都可以对 Vault 进行身份验证。

在第一次登录期间，Spring Cloud Vault 会生成一个随机数，该随机数与实例 ID 存储在认证后端中。重新认证需要发送相同的随机数。任何其他方都没有随机数，可以在 Vault 中引发警报以进行进一步调查。

随机数保存在内存中，并在应用程序重新启动时丢失。您可以使用 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
包含所有 AWS EC2 认证属性的 application.yml
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 认证。空随机数默认为随机数生成

另请参阅：Vault 文档：使用 aws 认证后端

AWS-IAM 认证

aws 后端为 AWS IAM 角色提供了一种安全的认证机制，允许根据正在运行的应用程序的当前 IAM 角色自动进行 Vault 认证。与大多数 Vault 认证后端不同，此后端不需要首先部署或预配安全敏感的凭据（令牌、用户名/密码、客户端证书等）。相反，它将 AWS 视为可信第三方，并使用调用者使用其 IAM 凭据签名的 4 个信息来验证调用者确实正在使用该 IAM 角色。

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

使用 AWS-IAM 认证时，必须在 Vault 中创建一个角色并将其分配给您的 IAM 角色。空 role 默认使用当前 IAM 角色的友好名称。

包含必需的 AWS-IAM 认证属性的 application.yml
spring.cloud.vault:
    authentication: AWS_IAM
包含所有 AWS-IAM 认证属性的 application.yml
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 用户的友好名称将用作 Vault 角色。

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

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

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

AWS-IAM 需要 AWS Java SDK v2 依赖项（software.amazon.awssdk:auth），因为认证实现使用 AWS SDK 类型进行凭据和请求签名。

另请参阅：Vault 文档：使用 aws 认证后端

Azure MSI 认证

azure 认证后端为 Azure VM 实例提供了一种安全的引入机制，允许自动检索 Vault 令牌。与大多数 Vault 认证后端不同，此后端不需要首先部署或预配安全敏感的凭据（令牌、用户名/密码、客户端证书等）。相反，它将 Azure 视为可信第三方，并使用可以绑定到 VM 实例的托管服务标识和实例元数据信息。

包含必需的 Azure 认证属性的 application.yml
spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
包含所有 Azure 认证属性的 application.yml
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.com。要更改此设置，请相应地设置 spring.cloud.vault.azure-msi.identity-token-service。

另请参阅

TLS 证书认证

cert 认证后端允许使用 SSL/TLS 客户端证书进行认证，这些证书要么由 CA 签名，要么是自签名的。

要启用 cert 认证，您需要

  1. 使用 SSL，请参阅 Vault 客户端 SSL 配置

  2. 配置包含客户端证书和私钥的 Java Keystore

  3. 将 spring.cloud.vault.authentication 设置为 CERT

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

另请参阅：Vault 文档：使用 Cert 认证后端

Cubbyhole 认证

Cubbyhole 认证使用 Vault 原语来提供安全的认证工作流程。Cubbyhole 认证使用令牌作为主要登录方法。使用临时令牌从 Vault 的 Cubbyhole 密钥后端获取第二个登录 Vault 令牌。登录令牌通常具有更长的有效期，用于与 Vault 交互。登录令牌将从存储在 /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

另请参阅

GCP-GCE 认证

gcp 认证后端允许通过使用现有的 GCP（Google Cloud Platform）IAM 和 GCE 凭据登录 Vault。

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

与大多数 Vault 认证后端不同，此后端不需要首先部署或预配安全敏感的凭据（令牌、用户名/密码、客户端证书等）。相反，它将 GCP 视为可信第三方，并使用对唯一表示每个 GCP 服务帐户的加密签名动态元数据信息。

包含必需的 GCP-GCE 认证属性的 application.yml
spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        role: my-dev-role
包含所有 GCP-GCE 认证属性的 application.yml
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 凭据登录 Vault。

GCP IAM 认证为服务帐户创建 JSON Web 令牌 (JWT) 形式的签名。服务帐户的 JWT 是通过调用 GCP IAM 的 projects.serviceAccounts.signJwt API 获取的。调用者对 GCP IAM 进行身份验证，从而证明其身份。此 Vault 后端将 GCP 视为可信第三方。

IAM 凭据可以从运行时环境（特别是 GOOGLE_APPLICATION_CREDENTIALS 环境变量）、Google Compute 元数据服务或作为例如 JSON 或 base64 编码的外部提供。JSON 是首选形式，因为它包含调用 projects.serviceAccounts.signJwt 所需的项目 ID 和服务帐户标识符。

包含必需的 GCP-IAM 认证属性的 application.yml
spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        role: my-dev-role
包含所有 GCP-IAM 认证属性的 application.yml
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-key 以 JSON 格式对 OAuth2 帐户私钥内容进行 base64 编码。

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

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

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

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

GCP IAM 认证需要 Google Cloud Java SDK 依赖项（com.google.apis:google-api-services-iam 和 com.google.auth:google-auth-library-oauth2-http），因为认证实现使用 Google API 进行凭据和 JWT 签名。

Google 凭据需要 OAuth 2 令牌来维护令牌生命周期。所有 API 都是同步的，因此 GcpIamAuthentication 不支持 AuthenticationSteps，而这对于反应式用法是必需的。

另请参阅

Kubernetes 认证

Kubernetes 认证机制（自 Vault 0.8.3 起）允许使用 Kubernetes 服务账户令牌对 Vault 进行身份验证。认证基于角色，并且角色绑定到服务账户名称和命名空间。

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

包含所有 Kubernetes 认证属性的 application.yml 文件
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 认证

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

包含所需 PCF 认证属性的 application.yml 文件
spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
包含所有 PCF 认证属性的 application.yml 文件
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 实例标识证书的路径。默认为 ${CF_INSTANCE_CERT} 环境变量。

  • instance-key 设置 PCF 实例标识密钥的路径。默认为 ${CF_INSTANCE_KEY} 环境变量。

PCF 认证需要在类路径中包含 BouncyCastle (bcpkix-jdk15on) 以进行 RSA PSS 签名。

另请参阅：Vault 文档：使用 pcf 认证后端

ACL 要求

本节说明 Spring Vault 访问哪些路径，以便您可以根据所需的功能推导出策略声明。

功能 关联的 HTTP 方法

创建

POST/PUT

读取

GET

更新

POST/PUT

删除

DELETE

列出

LIST (GET)

另请参阅 www.vaultproject.io/guides/identity/policies。

认证

登录：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