|
对于最新稳定版本，请使用 Spring Cloud Vault 5.0.1! |
认证方法
不同的组织对安全性和认证有不同的要求。 Vault 通过提供多种认证方法来满足这一需求。 Spring Cloud Vault 支持 token 和 AppId 认证。
Tokens认证
Tokens是Vault中进行身份验证的核心方法。
Tokens身份验证需要在配置中提供一个静态Tokens。
作为回退，Tokens也可以从~/.vault-token获取，这是Vault CLI默认用于缓存Tokens的位置。
| Tokens认证是默认的认证方法。 如果Tokens被泄露，未授权方将能够访问Vault，并可访问为指定客户端准备的秘密。 |
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000-
authentication将此值设置为TOKEN会选择 Token 认证方法 -
token设置要使用的静态Tokens。如果缺失或为空，则会尝试从 ~/.vault-token 获取Tokens。
见亦：
Vault Agent 认证
Vault 从 0.11.0 版本开始随 Vault Agent 附带一个 sidecar 工具。Vault Agent 通过其 Auto-Auth 功能实现了 Spring Vault 的 SessionManager
功能。
应用程序可以通过依赖于在 localhost 上运行的 Vault Agent 来重用缓存的会话凭据。
Spring Vault 可以在没有 X-Vault-Token 头部的情况下发送请求。
禁用 Spring Vault 的认证基础设施以禁用客户端认证和会话管理。
spring.cloud.vault:
authentication: NONE-
authentication将此值设置为NONE会禁用ClientAuthentication和SessionManager。
参见: Vault 文档: Agent
AppId 认证
Vault 支持 AppId
认证，该认证由两个难以猜测的Tokens组成。
AppId 默认值为 spring.application.name，该值是静态配置的。
第二个Tokens是 UserId，由应用程序确定，通常与运行时环境相关。
IP 地址、MAC 地址或 Docker 容器名称都是很好的例子。
Spring Cloud Vault Config 支持 IP 地址、MAC 地址和静态 UserId（例如通过系统属性提供）。
IP 和 MAC 地址表示为 SHA256 哈希的十六进制编码。
基于IP地址的UserId使用本地主机的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会从与本地主机绑定的网络设备获取其网络设备。
The configuration also allows specifying a network-interface hint to pick the right device.
The value of
network-interface is optional and can be either an interface name or interface index (0-based).
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 标志。 |
自定义 User Id
用户ID生成是一个开放机制。
您可以设置
spring.cloud.vault.app-id.user-id 为任何字符串，配置的值将作为静态用户ID使用。
一种更高级的方法是将spring.cloud.vault.app-id.user-id设置为一个类名。
该类必须在你的类路径上，并且必须实现org.springframework.cloud.vault.AppIdUserIdMechanism接口和createUserId方法。
Spring Cloud Vault 通过每次使用 AppId 进行身份验证时调用createUserId来获取 UserId，以获取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;
}
}应用角色认证
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 |
提供 |
提供 |
||
提供RoleId但未提供SecretId |
提供 |
|||
提供 RoleId，拉取 SecretId |
提供 |
提供 |
提供 |
|
拉取 RoleId，使用提供的 SecretId |
提供 |
提供 |
提供 |
|
完整拉取模式 |
提供 |
提供 |
||
包装 |
提供 |
|||
包装 RoleId，提供 SecretId |
提供 |
提供 |
||
提供RoleId，包装SecretId |
提供 |
提供 |
角色ID |
密钥ID |
支持 |
提供 |
提供 |
✅ |
提供 |
拉动 |
✅ |
提供 |
包装 |
✅ |
提供 |
缺席 |
✅ |
拉动 |
提供 |
✅ |
拉动 |
拉动 |
✅ |
拉动 |
包装 |
❌ |
拉动 |
缺席 |
❌ |
包装 |
提供 |
✅ |
包装 |
拉动 |
❌ |
包装 |
包装 |
✅ |
包装 |
缺席 |
❌ |
您可以使用推送/拉取/包装的所有组合模式，通过在上下文中提供一个已配置的AppRoleAuthentication 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。 如果配置了不需 SecretId 的 AppRole，则可省略 SecretId（参见bind_secret_id）。 -
role: 为拉取模式设置 AppRole 名称。 -
app-role-path设置要使用的 approle 认证挂载点的路径。
AWS-EC2 认证
The 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 会生成一个 nonce，并将其存储在与实例 ID 相同的认证后端中。 重新认证需要发送相同的 nonce。 任何其他方如果没有该 nonce，将在 Vault 中引发警报以供进一步调查。
Tokens在内存中保存，应用程序重启后会丢失。
您可以使用 spring.cloud.vault.aws-ec2.nonce 配置静态Tokens。
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-
authenticationsetting this value toAWS_EC2selects the AWS EC2 authentication method -
role设置登录尝试所针对的角色名称。 -
aws-ec2-path设置要使用的 AWS EC2 挂载路径 -
identity-document设置 PKCS#7 AWS EC2 身份文档的 URL -
nonce用于 AWS-EC2 认证。 空的 nonce 默认会生成 nonce
见 also: Vault 文档：使用 aws 认证后端
AWS-IAM 认证
The aws 后端提供了一种基于 AWS IAM 角色的 secure 认证机制，允许应用程序根据其正在运行的当前 IAM 角色自动认证到 vault。 Unlike most Vault 认证后端，此后端不需要首先部署或提供安全敏感的凭据（如 tokens、用户名/密码、客户端证书等）。 Instead，它将 AWS 视为受信任的第三方，并使用由调用方使用其 IAM 凭证签名的4个信息片段来验证调用方确实正在使用该 IAM 角色。
应用程序正在运行的当前IAM角色会自动计算。 如果您在AWS ECS上运行应用程序，那么应用程序将使用正在运行容器的ECS任务分配的IAM角色。 如果您直接在EC2实例上运行应用程序，则将使用分配给该EC2实例的IAM角色。
当使用 AWS-IAM 认证时，您必须在 Vault 中创建一个角色并将其分配到您的 IAM 角色。
一个空的 role 默认为当前 IAM 角色的友好名称。
spring.cloud.vault:
authentication: AWS_IAMspring.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设置用于iam_request_url参数的 AWS STS API 使用的值。
AWS-IAM 需要 AWS Java SDK v2 依赖（software.amazon.awssdk:auth）作为认证实现，其使用 AWS SDK 类型的凭证和请求签名。
见 also: Vault 文档：使用 aws 认证后端
Azure 托管服务身份认证
The azure 认证后端为 Azure VM 实例提供安全的引入机制，允许自动获取一个 Vault 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 服务器的 Resource Id 默认值为 vault.hashicorp.com。
要更改此设置，请将其设置为 spring.cloud.vault.azure-msi.identity-token-service。
见亦：
TLS证书认证
The cert 认证后端允许使用通过CA签名或自签名的SSL/TLS客户端证书进行认证。
To enable 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见 also: Vault 文档: 使用 Cert 认证后端
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见亦：
GCP-GCE 身份验证
The gcp auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.
GCP GCE (Google Compute Engine) 认证会为服务账户生成一种 JSON Web Token (JWT) 签ature。 通过使用 实例标识 从 GCE 元数据服务获取 Compute Engine 实例的 JWT。 此 API 会创建可用于确认实例身份的 JSON Web Token。
不同于大多数 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的服务账户。
见亦：
GCP-IAM 认证
The gcp auth backend allows Vault login by using existing GCP (Google Cloud Platform) IAM and GCE credentials.
GCP IAM 身份验证会为服务帐户创建一个 JSON Web Tokens（JWT）签名。通过调用 GCP IAM 的 projects.serviceAccounts.signJwt API 获取服务帐户的 JWT。调用方对 GCP IAM 进行身份验证，并证明其身份。此 Vault 后端将 GCP 视为可信第三方。
身份验证凭据可从运行时环境获取，具体为GOOGLE_APPLICATION_CREDENTIALS环境变量、Google 计算元数据服务或作为外部提供（例如JSON或base64编码）。
推荐使用JSON格式，因为它包含了调用projects.serviceAccounts.signJwt所需的项目ID和服务帐户标识符。
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-keyOAuth2账户私钥的内容以Base64编码，格式为JSON。 -
gcp-path设置要使用的 GCP 挂载路径 -
jwt-validity配置JWTTokens的有效性。默认为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凭据需要维护Tokens生命周期的OAuth 2Tokens。 所有API都是同步的，因此 |
见亦：
Kubernetes 认证
Kubernetes 认证机制（自 Vault 0.8.3 版本起）允许使用 Kubernetes 服务账户Tokens对 Vault 进行认证。该认证是基于角色的，角色与服务账户名称和命名空间相关联。
包含Pod服务账户的JWTTokens的文件会自动挂载到/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。
见亦：
云平台认证
该pcf认证后端为运行在Pivotal CloudFoundry实例内的应用程序提供了一种安全的引入机制，允许自动获取VaultTokens。
与大多数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}环境变量。 -
instance-key设置 PCF 实例身份密钥的路径。 默认为${CF_INSTANCE_KEY}环境变量。
| PCF身份验证需要将BouncyCastle（bcpkix-jdk15on）放在类路径中，以便进行RSA PSS签名。 |
另请参阅：Vault 文档：使用 pcf 认证后端
ACL需求
本部分说明了Spring Vault访问的路径，因此您可以根据所需能力推导出相应的策略声明。
| 能力 | 关联的 HTTP 动词 |
|---|---|
创建 |
|
阅读 |
|
更新 |
|
删除 |
|
列表 |
|
秘钥租约容器
SecretLeaseContainer 使用取决于配置的租约端点的不同路径。
LeaseEndpoints.Legacy
-
撤销:
PUT sys/revoke -
续订:
零
LeaseEndpoints.Leases (SysLeases)
-
撤销:
PUT sys/leases/revoke -
续订:
零