5. 认证方式
不同的组织对安全性和身份验证有不同的要求。Vault 通过提供多种身份验证方法来反映这一需求。Spring Cloud Vault 支持Tokens和 AppId 身份验证。
5.1. Tokens认证
Tokens是 Vault 中身份验证的核心方法。Tokens身份验证需要使用配置提供静态Tokens。作为后备，也可以从~/.vault-token这是 Vault CLI 用于缓存Tokens的默认位置。
| Tokens身份验证是默认的身份验证方法。如果Tokens被泄露，则意外方将获得对 Vault 的访问权限，并可以访问预期客户端的机密。 |
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000-
authentication将此值设置为TOKEN选择Tokens身份验证方法 -
token设置要使用的静态Tokens。如果丢失或为空，则将尝试从 ~/.vault-token 检索Tokens。
另见：
5.2. Vault 代理身份验证
Vault 从 0.11.0 版开始随 Vault Agent 一起提供了一个 Sidecar 实用程序。Vault Agent 实现了 Spring Vault 的SessionManager具有自动身份验证功能。应用程序可以通过依赖在localhost. Spring Vault 可以在没有X-Vault-Token页眉。 禁用 Spring Vault 的身份验证基础设施以禁用客户端身份验证和会话管理。
spring.cloud.vault:
authentication: NONE-
authentication将此值设置为NONE禁用ClientAuthentication和SessionManager.
另请参阅：Vault 文档：代理
5.3. AppId 身份验证
Vault 支持 AppId 身份验证，该身份验证由两个难以猜测的Tokens组成。AppId 默认为spring.application.name这是静态配置的。第二个Tokens是 UserId，它是由应用程序确定的一部分，通常与运行时环境相关。IP 地址、Mac 地址或 Docker 容器名称就是很好的例子。Spring Cloud Vault Config 支持 IP 地址、Mac 地址和静态 UserId（例如通过系统属性提供）。IP 和 Mac 地址表示为十六进制编码的 SHA256 哈希。
基于 IP 地址的用户 ID 使用本地主机的 IP 地址。
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 从 localhost 绑定的设备获取其网络设备。该配置还允许指定network-interface提示以选择正确的设备。的值network-interface是可选的，可以是接口名称或接口索引（从 0 开始）。
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旗。 |
5.3.1. 自定义用户 ID
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 将通过调用createUserId每次使用 AppId 进行身份验证以获取Tokens。
spring.cloud.vault:
authentication: APPID
app-id:
user-id: com.examlple.MyUserIdMechanismpublic class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = ...
return userId;
}
}5.4. AppRole 身份验证
AppRole 用于计算机身份验证，就像已弃用的（自 Vault 0.6.1 以来）AppId 身份验证一样。 AppRole 身份验证由两个难以猜测的（机密）Tokens组成：RoleId 和 SecretId。
Spring Vault 支持各种 AppRole 场景（推/拉模式和包装）。
RoleId 和可选的 SecretId 必须由配置提供，Spring Vault 将不会查找这些或创建自定义 SecretId。
spring.cloud.vault:
authentication: APPROLE
app-role:
role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52在所需的配置详细信息中，支持以下方案：
方法 |
角色 ID |
秘密 ID |
角色名称 |
Tokens |
提供的 RoleId/SecretId |
提供 |
提供 |
||
提供不带 SecretId 的 RoleId |
提供 |
|||
提供 RoleId，拉取 SecretId |
提供 |
提供 |
提供 |
提供 |
拉取 RoleId，提供 SecretId |
提供 |
提供 |
提供 |
|
全拉模式 |
提供 |
提供 |
||
包裹 |
提供 |
|||
包装的 RoleId，提供 SecretId |
提供 |
提供 |
||
提供 RoleId，包装 SecretId |
提供 |
提供 |
角色 ID |
秘密 ID |
支持 |
提供 |
提供 |
✅ |
提供 |
拉 |
✅ |
提供 |
包裹 |
✅ |
提供 |
缺席 |
✅ |
拉 |
提供 |
✅ |
拉 |
拉 |
✅ |
拉 |
包裹 |
❌ |
拉 |
缺席 |
❌ |
包裹 |
提供 |
✅ |
包裹 |
拉 |
❌ |
包裹 |
包裹 |
✅ |
包裹 |
缺席 |
❌ |
您可以通过提供配置的AppRoleAuthenticationbean 的 bean 中。
Spring Cloud Vault 无法从配置属性中派生所有可能的 AppRole 组合。 |
AppRole 身份验证仅限于使用响应式基础结构的简单拉取模式。
尚不支持完全拉取模式。
将 Spring Cloud Vault 与 Spring WebFlux 堆栈一起使用可启用 Vault 的响应式自动配置，可以通过将spring.cloud.vault.reactive.enabled=false. |
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 身份验证挂载的路径。
5.5. AWS-EC2 身份验证
aws-ec2 身份验证后端为 AWS EC2 实例提供了安全的引入机制，允许自动检索 Vault Tokens。 与大多数 Vault 身份验证后端不同，此后端不需要首次部署或配置安全敏感凭据（Tokens、用户名/密码、客户端证书等）。 相反，它将 AWS 视为受信任的第三方，并使用唯一代表每个 EC2 实例的加密签名动态元数据信息。
spring.cloud.vault:
authentication: AWS_EC2AWS-EC2 身份验证默认情况下使 nonce 遵循首次使用时信任 （TOFU） 原则。 任何获得 PKCS#7 身份元数据访问权限的意外方都可以针对 Vault 进行身份验证。
在第一次登录期间，Spring Cloud Vault 会生成一个随机数，该随机数存储在实例 ID 之外的身份验证后端中。 重新身份验证需要发送相同的随机数。 任何其他方都没有随机数，可以在 Vault 中发出警报以进行进一步调查。
随机数保存在内存中，并在应用程序重新启动期间丢失。
您可以使用spring.cloud.vault.aws-ec2.nonce.
AWS-EC2 身份验证角色是可选的，默认为 AMI。
您可以通过设置spring.cloud.vault.aws-ec2.role财产。
spring.cloud.vault:
authentication: AWS_EC2
aws-ec2:
role: application-serverspring.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 身份验证。 空随机数默认生成随机数
5.6. AWS-IAM 身份验证
aws 后端为 AWS IAM 角色提供安全的身份验证机制，允许根据正在运行的应用程序的当前 IAM 角色使用保管库进行自动身份验证。 与大多数 Vault 身份验证后端不同，此后端不需要首次部署或配置安全敏感凭据（Tokens、用户名/密码、客户端证书等）。 相反，它将 AWS 视为受信任的第三方，并使用调用方及其 IAM 凭证签名的 4 条信息来验证调用方是否确实在使用该 IAM 角色。
系统会自动计算应用程序运行的当前 IAM 角色。 如果您在 AWS ECS 上运行应用程序，则应用程序将使用分配给正在运行的容器的 ECS 任务的 IAM 角色。 如果您在 EC2 实例之上裸运行应用程序，则使用的 IAM 角色将是分配给 EC2 实例的 IAM 角色。
使用 AWS-IAM 身份验证时，您必须在 Vault 中创建一个角色并将其分配给您的 IAM 角色。
一个空的role默认为当前 IAM 角色的友好名称。
spring.cloud.vault:
authentication: AWS_IAMspring.cloud.vault:
authentication: AWS_IAM
aws-iam:
role: my-dev-role
aws-path: aws
server-name: some.server.name
endpoint-uri: https://sts.eu-central-1.amazonaws.com-
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 SDK 依赖项 （com.amazonaws:aws-java-sdk-core）作为身份验证实施使用 AWS SDK 类型进行凭证和请求签名。
5.7. Azure MSI 身份验证
Azure 身份验证后端为 Azure VM 实例提供安全的引入机制，允许自动检索保管库Tokens。 与大多数 Vault 身份验证后端不同，此后端不需要首次部署或配置安全敏感凭据（Tokens、用户名/密码、客户端证书等）。 相反，它将 Azure 视为受信任的第三方，并使用可绑定到 VM 实例的托管服务标识和实例元数据信息。
spring.cloud.vault:
authentication: AZURE_MSI
azure-msi:
role: my-dev-rolespring.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设置用于访问标识Tokens服务的 URI
Azure MSI 身份验证从实例元数据服务获取有关虚拟机的环境详细信息（订阅 ID、资源组、VM 名称）。
Vault 服务器的资源 ID 默认为vault.hashicorp.com.
要更改此设置，请将spring.cloud.vault.azure-msi.identity-token-service因此。
另见：
5.8. TLS 证书身份验证
这cert身份验证后端允许使用由 CA 签名或自签名的 SSL/TLS 客户端证书进行身份验证。
启用cert身份验证，您需要：
-
使用 SSL，请参见 Vault 客户端 SSL 配置
-
配置 Java
Keystore包含客户端证书和私钥 -
将
spring.cloud.vault.authentication自CERT
spring.cloud.vault:
authentication: CERT
ssl:
key-store: classpath:keystore.jks
key-store-password: changeit
key-store-type: JKS
cert-auth-path: cert另请参阅：Vault 文档：使用证书身份验证后端
5.9. Cubbyhole 身份验证
Cubbyhole 身份验证使用 Vault 基元来提供安全的身份验证工作流程。
Cubbyhole 身份验证使用Tokens作为主要登录方法。
临时Tokens用于从 Vault 的 Cubbyhole 秘密后端获取第二个登录 VaultToken。
登录Tokens的寿命通常更长，用于与 Vault 交互。
登录Tokens将从存储在/cubbyhole/response.
创建包装Tokens
| 用于创建Tokens的响应包装需要 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-4f3d86a68319spring.cloud.vault:
authentication: CUBBYHOLE
token: 397ccb93-ff6c-b17b-9389-380b01ca2645另见：
5.10. GCP-GCE 身份验证
gcp 身份验证后端允许使用现有的 GCP （Google Cloud Platform） IAM 和 GCE 凭据登录 Vault。
GCP GCE（Google Compute Engine）身份验证以 JSON Web Tokens （JWT） 的形式为服务帐号创建签名。 Compute Engine 实例的 JWT 是使用实例标识从 GCE 元数据服务获取的。 此 API 创建一个 JSON Web Tokens，可用于确认实例身份。
与大多数 Vault 身份验证后端不同，此后端不需要首次部署或配置安全敏感凭据（Tokens、用户名/密码、客户端证书等）。 相反，它将 GCP 视为受信任的第三方，并使用唯一代表每个 GCP 服务帐号的加密签名动态元数据信息。
spring.cloud.vault:
authentication: GCP_GCE
gcp-gce:
role: my-dev-rolespring.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服务帐户。
另见：
5.11. GCP-IAM 身份验证
gcp 身份验证后端允许使用现有的 GCP （Google Cloud Platform） IAM 和 GCE 凭据登录 Vault。
GCP IAM 身份验证以 JSON Web Tokens （JWT） 的形式为服务帐号创建签名。服务帐号的 JWT 是通过调用 GCP IAM 的projects.serviceAccounts.signJwt应用程序接口。 调用方针对 GCP IAM 进行身份验证，从而证明其身份。此 Vault 后端将 GCP 视为受信任的第三方。
IAM 凭证可以从运行时环境获取，特别是GOOGLE_APPLICATION_CREDENTIALS环境变量、Google Compute 元数据服务，或以 e.g. JSON 或 base64 编码的形式向外部提供。
JSON 是首选形式，因为它携带调用所需的项目 ID 和服务帐户标识符projects.serviceAccounts.signJwt.
spring.cloud.vault:
authentication: GCP_IAM
gcp-iam:
role: my-dev-rolespring.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-keyJSON 格式的 OAuth2 帐户私钥的 base64 编码内容。 -
gcp-path设置要使用的 GCP 挂载路径 -
jwt-validity配置 JWT Tokens有效性。 默认为 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 Tokens来维护Tokens生命周期。
因此，所有 API 都是同步的，GcpIamAuthentication不支持AuthenticationSteps这是被动使用所必需的。 |
另见：
5.12. Kubernetes 身份验证
Kubernetes 身份验证机制（从 Vault 0.8.3 开始）允许使用 Kubernetes 服务帐户Tokens向 Vault 进行身份验证。 身份验证基于角色，角色绑定到服务帐户名称和命名空间。
包含 Pod 服务帐户的 JWT Tokens的文件会自动挂载在/var/run/secrets/kubernetes.io/serviceaccount/token.
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 服务帐户Tokens的文件的位置。默认为/var/run/secrets/kubernetes.io/serviceaccount/token.
另见：
5.13. 关键的CloudFoundry身份验证
pcf 身份验证后端为在 Pivotal 的 CloudFoundry 实例中运行的应用程序提供了一种安全的引入机制，允许自动检索 Vault Tokens。与大多数 Vault 身份验证后端不同，此后端不需要首次部署或配置安全敏感凭据（Tokens、用户名/密码、客户端证书等），因为身份配置由 PCF 本身处理。相反，它将 PCF 视为受信任的第三方并使用托管实例身份。
spring.cloud.vault:
authentication: PCF
pcf:
role: my-dev-rolespring.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}env 变量。 -
instance-key设置 PCF 实例身份密钥的路径。默认为${CF_INSTANCE_KEY}env 变量。
| PCF 身份验证要求 BouncyCastle （bcpkix-jdk15on） 位于 RSA PSS 签名的类路径上。 |