认证方法
不同组织对安全和身份验证有不同的要求。 Vault 通过支持多种认证方式来体现这一需求。 Spring Cloud Vault 支持Tokens和 AppID 认证。
Tokens认证
Tokens是 Vault 内部认证的核心方法。
Tokens认证需要通过配置提供静态Tokens。
作为备选，标记也可以从~/.vault-token这是Vault CLI用来缓存Tokens的默认位置。
| Tokens认证是默认的认证方法。 如果某个Tokens被披露，非预期方将获得Vault的访问权限，并能访问目标客户端的秘密。 |
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000-
认证将该值设为Tokens选择Tokens认证方法 -
Tokens设置静态Tokens使用。如果缺少或空的，则会尝试从 ~/.vault-token 中检索Tokens。
参见：
Vault Agent 认证
Vault 自 0.11.0 版本起就提供带有 Vault Agent 的副车工具。Vault Agent 实现了 Spring Vault 的功能会话管理器并配备了自动认证功能。
应用程序可以通过依赖运行于 的 Vault Agent 来重复利用缓存会话凭证本地主持.
Spring Vault 可以发送请求而无需X-金库-Tokens页眉。
禁用 Spring Vault 的认证基础设施，以关闭客户端认证和会话管理。
spring.cloud.vault:
authentication: NONE-
认证将该值设为没有禁用客户端认证和会话管理器.
另见：金库文档：代理人
AppId认证
Vault 支持由两个难以猜测的Tokens组成的 AppId 认证。
AppId默认为spring.application.name这是静态配置的。
第二个Tokens是 UserId，这是应用程序确定的一个部分，通常与运行环境相关。
IP 地址、Mac 地址或 Docker 容器名称都是很好的例子。
Spring Cloud Vault 配置支持 IP 地址、Mac 地址和静态用户 ID（例如通过系统属性提供）。
IP和Mac地址以十六进制编码的SHA256哈希表示。
基于IP地址的用户ID使用本地主机的IP地址。
spring.cloud.vault:
authentication: APPID
app-id:
user-id: IP_ADDRESS-
认证将该值设为APPID选择AppID认证方法 -
应用-ID-路径设置 AppId 挂载的路径 -
用户ID设置 UserId 方法。 可能的值有IP_ADDRESS,MAC_ADDRESS或者一个实现自定义的类名AppIdUserIdMechanism
从命令行生成 IP 地址 UserID 的对应命令是：
$ echo -n 192.168.99.1 | sha256sum
包括 的换行回波导致不同的哈希值，因此请务必包含-n旗。 |
基于Mac地址的UserID从本地主机绑定的设备获取网络设备。
该配置还允许指定网络接口提示：选择正确的设备。
的价值网络接口是可选的，可以是接口名称或接口索引（基于0）。
spring.cloud.vault:
authentication: APPID
app-id:
user-id: MAC_ADDRESS
network-interface: eth0-
网络接口设置网络接口以获取物理地址
从命令行生成 IP 地址 UserID 的对应命令是：
$ echo -n 0AFEDE1234AC | sha256sum
Mac 地址以大写字母表示，不加冒号。
包括 的换行回波导致不同的哈希值，因此请务必包含-n旗。 |
自定义用户ID
UserId 生成是一个开放机制。
你可以设置spring.cloud.vault.app-id.user-id映射到任意字符串，配置值将作为静态用户ID（UserId）使用。
更高级的方法可以让你设置spring.cloud.vault.app-id.user-id给一个班级名字。
该类必须在你的类路径上，并且必须实现org.springframework.cloud.vault.AppIdUserIdMechanism接口和createUserID方法。
Spring Cloud Vault 将通过呼叫获取用户 IDcreateUserID每次都使用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;
}
}AppRole 认证
Spring Vault 支持多种 AppRole 场景（推拉模式和封装模式）。
配置必须提供RoleId和可选的SecretId，Spring Vault不会查找这些，也不会创建自定义SecretId。
spring.cloud.vault:
authentication: APPROLE
app-role:
role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52以下场景根据所需的配置细节支持：
方法 |
角色识别 |
秘密 |
角色名称 |
Tokens |
提供的 RoleId/SecretId |
提供 |
提供 |
||
提供无SecretID的RoleId。 |
提供 |
|||
提供 roleId，拉取 SecretId |
提供 |
提供 |
提供 |
|
拉取 RoleId，提供的 SecretID |
提供 |
提供 |
提供 |
|
全拉模式 |
提供 |
提供 |
||
包裹 |
提供 |
|||
封装 RoleId，提供 SecretID |
提供 |
提供 |
||
提供 RoleId，包裹 SecretId |
提供 |
提供 |
角色识别 |
秘密 |
支持 |
提供 |
提供 |
✅ |
提供 |
拉 |
✅ |
提供 |
包裹 |
✅ |
提供 |
缺席 |
✅ |
拉 |
提供 |
✅ |
拉 |
拉 |
✅ |
拉 |
包裹 |
❌ |
拉 |
缺席 |
❌ |
包裹 |
提供 |
✅ |
包裹 |
拉 |
❌ |
包裹 |
包裹 |
✅ |
包裹 |
缺席 |
❌ |
你仍然可以通过配置配置使用所有推/拉/包裹模式的组合AppRoleAuthentication在语境中是豆子。
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-
角色标识设置 RoleId。 -
秘密身份设置SecretId。 如果配置AppRole但不要求SecretId，则可以省略SecretId（参见bind_secret_id). -
角色： 将 AppRole 名称设置为拉取模式。 -
应用-角色-路径设置应用认证挂载的路径。
AWS-EC2 认证
aws-ec2 认证后端为 AWS EC2 实例提供了安全的引入机制，允许自动检索 Vault Tokens。 与大多数 Vault 认证后端不同，该后端不需要优先部署或配置安全敏感的凭证（Tokens、用户名/密码、客户端证书等）。 相反，它将 AWS 视为可信第三方，使用经过加密签名的动态元数据，唯一代表每个 EC2 实例。
spring.cloud.vault:
authentication: AWS_EC2AWS-EC2认证默认允许一次性信赖（Trust On First First， First， Tofu）原则。 任何非意图方获得PKCS#7身份元数据的访问权限都可以对Vault进行身份验证。
在第一次登录时，Spring Cloud Vault 会生成一个 nonce 文件，存储在验证后台，除了实例 ID 之外。 重新认证需要发送相同的 nonce。 其他方没有该临时监护人，可以在Vault中发出警报以进一步调查。
nonce 被存储在内存中，并在应用重启时丢失。
你可以配置静态 nonce 用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-
认证将该值设为AWS_EC2选择AWS EC2认证方法 -
角色设置尝试登录的对象角色名称。 -
aws-ec2-path设置AWS EC2挂载的路径以供使用 -
身份证明设置PKCS#7 AWS EC2身份文档的URL。 -
不出现用于 AWS-EC2 认证。 空的一次性默认为一次性生成
AWS-IAM 认证
AWS 后端为 AWS IAM 角色提供安全的认证机制，允许基于当前应用 IAM 角色自动通过 Vault 进行认证。 与大多数 Vault 认证后端不同，该后端不需要优先部署或配置安全敏感的凭证（Tokens、用户名/密码、客户端证书等）。 相反，它将AWS视为可信第三方，利用呼叫者与其IAM凭证签署的4条信息，验证呼叫者确实使用该IAM角色。
应用程序当前运行的IAM角色会自动计算。 如果你在AWS ECS上运行应用，应用会使用分配给运行容器ECS任务的IAM角色。 如果你是在 EC2 实例上裸运行应用，那么所用的 IAM 角色将分配给 EC2 实例。
使用 AWS-IAM 认证时，你必须在 Vault 中创建一个角色并将其分配给你的 IAM 角色。
一个空洞角色默认使用友好名称，即当前的IAM Role。
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-
地区设定 AWS 区域名称。如果未提供，区域将由 AWS 默认设置决定。 -
角色设置尝试登录的对象角色名称。 这应该绑定到你的 IAM 角色。 如果没有提供，则当前 IAM 用户的友好名称将被用作保险库角色。 -
aws-路径设置 AWS 挂载的路径 -
服务器名称设置 要用于X-Vault-AWS-IAM-Server-ID该标题阻止某些类型的回放攻击。 -
端点-URI设置 AWS STS API 的值，用于iam_request_url参数。
AWS-IAM 需要 AWS Java SDK v2 依赖（Software.amazon.AWSSDK：auth）而认证实现则使用 AWS SDK 类型进行凭证和请求签名。
Azure MSI authentication
Azure 认证后端为 Azure VM 实例提供了安全的引入机制，允许自动检索 Vault Tokens。 与大多数 Vault 认证后端不同，该后端不需要优先部署或配置安全敏感的凭证（Tokens、用户名/密码、客户端证书等）。 相反，它将Azure视为可信第三方，使用可绑定到虚拟机实例的托管服务身份和实例元数据信息。
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…-
角色设置尝试登录的对象角色名称。 -
azure-path设定青天骑乘的路径 -
元数据服务设置访问实例元数据服务的URI -
身份-Tokens-服务设置访问身份Tokens服务的URI
Azure MSI 认证通过实例元数据服务获取虚拟机的环境信息（订阅 ID、资源组、虚拟机名称）。
Vault 服务器的资源 ID 默认为vault.hashicorp.com.
要改变这一点，设Spring.cloud.vault.azure-msi.identity-token-service因此。
参见：
TLS证书认证
这证书认证后端允许使用 SSL/TLS 客户端证书进行身份验证，这些证书要么由 CA 签名，要么自签名。
以实现证书你需要进行以下认证：
-
使用SSL，参见Vault Client SSL配置
-
配置一个Java
密钥存储其中包含客户端证书和私钥 -
设置
spring.cloud.vault.authentication自证书
spring.cloud.vault:
authentication: CERT
ssl:
key-store: classpath:keystore.jks
key-store-password: changeit
key-store-type: JKS
cert-auth-path: cert格子认证
Cubbyhole 认证使用 Vault 原语来提供安全的认证流程。
Bootbyhole认证使用Tokens作为主要登录方式。
临时Tokens用于从Vault的Cubbyhole秘密后端获取第二个登录VaultToken。
登录Tokens通常寿命更长，用于与 Vault 交互。
登录Tokens将从存储在/小窝/回应.
创建包裹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 认证
GCP认证后端允许通过现有的GCP（Google Cloud Platform）IAM和GCE凭证进行Vault登录。
GCP GCE（谷歌计算引擎）认证为服务账户创建以 JSON Web Tokens（JWT）为形式签名。 计算引擎实例的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]-
角色设置尝试登录的对象角色名称。 -
GCP路径设置GCP挂载路径的使用顺序 -
服务账户允许将服务账户 ID 覆盖到特定值。 默认使用默认值服务账户。
参见：
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]-
角色设置尝试登录的对象角色名称。 -
credentials.location路径指向包含 JSON 格式 Google 凭证的凭证资源。 -
credentials.encoded-key该 base64 以 JSON 格式编码的 OAuth2 账户私钥内容。 -
GCP路径设置GCP挂载路径的使用顺序 -
JWT-有效性配置JWTTokens效度。 默认为15分钟。 -
项目标识允许将项目 ID 覆盖到特定值。 默认使用获得凭证时的项目ID。 -
服务账户允许将服务账户 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都是同步的，因此，GcpIam认证不支持认证步骤这对于响应式使用是必要的。 |
参见：
GitHub 认证
你可以通过提供个人访问Tokens，使用 GitHub 认证来对 Vault 进行身份验证。 作为备用，如果安装并认证，Tokens也可以通过GitHub CLI获取。
spring.cloud.vault:
authentication: GITHUB
github:
token: gho_…-
认证将该值设为GITHUB选择GitHub认证方法 -
Tokens设置静态Tokens使用。如果缺少或空，则可尝试从中获取TokensGH认证Tokens如果GitHub CLI已安装并认证，且访问权限通过以下途径spring.cloud.vault.github.allow-cli-token=true. -
允许-CLITokens使得备份到GitHub CLI以获取Tokens。默认禁用，以避免意外调用GitHub CLI。
参见：
Kubernetes 认证
Kubernetes 认证机制（自 Vault 0.8.3 起）允许使用 Kubernetes 服务账户Tokens与 Vault 进行认证。 认证基于角色，角色绑定到服务账户名称和命名空间。
包含 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-
角色设定角色。 -
Kubernetes-路径设置Kubernetes挂载的路径以使用。 -
服务-账户-Tokens文件设置包含Kubernetes服务账户Tokens的文件位置。 默认/var/run/secrets/kubernetes.io/serviceaccount/token.
参见：
Pivotal 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-
角色设置尝试登录的对象角色名称。 -
PCF路径设置PCF安装路径的使用。 -
实例证书设置路径到PCF实例身份证书。 默认${CF_INSTANCE_CERT}环境变量。 -
实例密钥设置路径到PCF实例身份密钥。 默认${CF_INSTANCE_KEY}环境变量。
| PCF认证要求BouncyCastle（bcpkix-jdk15on）在RSA PSS签名的类路径上。 |
ACL要求
本节解释了 Spring Vault 访问哪些路径，以便你能根据所需能力推导出策略声明。
| 能力 | 关联HTTP动词 |
|---|---|
创造 |
|
读 |
|
更新 |
|
删除 |
|
列表 |
|
秘密租赁容器
秘密租赁容器根据配置的租约端点，使用不同的路径。
LeaseEndpoints.Legacy
-
撤销：
PUT sys/revoke -
更新：
PUT sys/renew
租赁端点。租赁 (系统租赁)
-
撤销：
PUT 系统/租赁/撤销 -
更新：
PUT 系统/租赁/续约