103. 身份验证方法
不同组织对安全性和身份验证有不同的要求。 Vault 通过提供多种身份验证方法来反映这种需求。 Spring Cloud Vault 支持令牌和 AppId 身份验证。
103.1 令牌认证
令牌是 Vault 中验证的核心方法。令牌认证需要使用Bootstrap Application Context提供静态令牌。
令牌认证是默认的认证方法。如果披露了令牌,则非预期的一方可以访问 Vault 并可以访问预期的客户端的秘密。
示例 103.1. bootstrap.yml
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000
-
authentication
将此 value 设置为TOKEN
选择令牌验证方法 -
token
_set 要使用的静态令牌
另见:Vault 文档:令牌
103.2 AppId 身份验证
Vault 支持由两个难以猜测的令牌组成的AppId身份验证。 AppId 默认为静态配置的spring.application.name
。第二个标记是 UserId,它是由 application 确定的部分,通常与运行时环境相关。 IP 地址,Mac 地址或 Docker 容器 name 就是很好的例子。 Spring Cloud Vault Config 支持 IP 地址,Mac 地址和静态 UserId(e.g. 通过 System properties 提供)。 IP 和 Mac 地址表示为 Hex-encoded SHA256 哈希。
IP address-based UserId 使用本地 host 的 IP 地址。
示例 103.2. bootstrap.yml 使用 SHA256 IP-Address UserId 的
spring.cloud.vault:
authentication: APPID
app-id:
user-id: IP_ADDRESS
-
authentication
将此 value 设置为APPID
选择 AppId 身份验证方法 -
app-id-path
_set 要使用的 AppId 挂载的路径 -
user-id
sets UserId 方法。可能的值是IP_ADDRESS
,MAC_ADDRESS
或 class name 实现自定义AppIdUserIdMechanism
从命令 line 生成 IP 地址 UserId 的相应命令是:
$ echo -n 192.168.99.1 | sha256sum
包括
echo
的 line break 会导致不同的 hash value,因此请确保包含-n
flag。
Mac address-based UserId 从 localhost-bound 设备获取其网络设备。 configuration 还允许指定network-interface
提示来选择正确的设备。 network-interface
的 value 是可选的,可以是接口 name 或接口索引(0-based)。
示例 103.3. bootstrap.yml 使用 SHA256 Mac-Address UserId 的
spring.cloud.vault:
authentication: APPID
app-id:
user-id: MAC_ADDRESS
network-interface: eth0
network-interface
sets 网络接口获取物理地址
从命令 line 生成 IP 地址 UserId 的相应命令是:
$ echo -n 0AFEDE1234AC | sha256sum
Mac 地址指定为大写且没有冒号。包括
echo
的 line break 会导致不同的 hash value,因此请确保包含-n
flag。
103.2.1 自定义 UserId
UserId 生成是一种开放机制。您可以将spring.cloud.vault.app-id.user-id
设置为任何 string,配置的 value 将用作静态 UserId。
更高级的方法允许您将spring.cloud.vault.app-id.user-id
设置为类名。此 class 必须位于 classpath 上,并且必须实现org.springframework.cloud.vault.AppIdUserIdMechanism
接口和createUserId
方法。 Spring Cloud Vault 将通过调用createUserId
来获取 UserId,每次使用 AppId 进行身份验证以获取令牌。
示例 103.4. bootstrap.yml
spring.cloud.vault:
authentication: APPID
app-id:
user-id: com.examlple.MyUserIdMechanism
示例 103.5. MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = ...
return userId;
}
}
103.3 AppRole 身份验证
AppRole用于机器身份验证,例如已弃用(自 Vault 0.6.1)第 103.2 节,“AppId 身份验证”。 AppRole 身份验证包含两个难以猜测的(secret)令牌:RoleId 和 SecretId。
Spring Vault 支持各种 AppRole 场景(push/pull 模式和包装)。
RoleId 和可选的 SecretId 必须由 configuration 提供,Spring Vault 不会查找这些或创建自定义的 SecretId。
示例 103.6. bootstrap.yml with AppRole authentication properties
spring.cloud.vault:
authentication: APPROLE
app-role:
role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
所需的 configuration 详细信息支持以下方案:
表格 1_.组态
方法 | ****角色 ID | ****的 SecretID | **** ROLENAME | ****令牌 |
提供 RoleId/SecretId | 提供 | 提供 | ||
提供没有 SecretId 的 RoleId | 提供 | |||
提供了 RoleId,Pull SecretId | 提供 | 提供 | 提供 | 提供 |
提供 RoleId,提供 SecretId | 提供 | 提供 | 提供 | |
全拉模式 | 提供 | 提供 | ||
包裹 | 提供 | |||
包含 RoleId,提供了 SecretId | 提供 | 提供 | ||
提供了 RoleId,包含了 SecretId | 提供 | 提供 |
表格 1_.Pull/Push/Wrapped Matrix
****角色 ID | ****的 SecretID | 支持的 |
提供 | 提供 | ✅ |
提供 | 拉 | ✅ |
提供 | 包裹 | ✅ |
提供 | 缺席 | ✅ |
拉 | 提供 | ✅ |
拉 | 拉 | ✅ |
拉 | 包裹 | ❌ |
拉 | 缺席 | ❌ |
包裹 | 提供 | ✅ |
包裹 | 拉 | ❌ |
包裹 | 包裹 | ✅ |
包裹 | 缺席 | ❌ |
您可以通过在 bootstrap context 中提供已配置的
AppRoleAuthentication
bean 来使用 push/pull/wrapped 模式的所有组合。 Spring Cloud Vault 无法从 configuration properties 派生所有可能的 AppRole 组合。
AppRole 身份验证仅限于使用 reactive Infrastructure 的简单拉模式。尚不支持全拉模式。使用 Spring Cloud Vault 与 Spring WebFlux 堆栈启用 Vault 的 reactive auto-configuration,可以通过设置
spring.cloud.vault.reactive.enabled=false
来禁用它。
示例 103.7. bootstrap.yml 与所有 AppRole 身份验证 properties
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
sets RoleId。 -
secret-id
sets the SecretId。如果配置 AppRole 而不需要 SecretId(参见bind_secret_id
),则可以省略 SecretId。 -
role
:设置拉模式的 AppRole name。 -
app-role-path
_set 要使用的认证认证安装的路径。
103.4 AWS-EC2 认证
aws-ec2 auth 后端为 AWS EC2 实例提供安全的引入机制,允许自动检索 Vault 令牌。与大多数 Vault 身份验证后端不同,此后端不需要 first-deploying 或配置 security-sensitive 凭据(令牌,username/password,客户端证书,etc.)。相反,它将 AWS 视为可信第三方,并使用加密签名的动态元数据信息,该信息唯一代表每个 EC2 实例。
示例 103.8. bootstrap.yml 使用 AWS-EC2 身份验证
spring.cloud.vault:
authentication: AWS_EC2
AWS-EC2 authentication 默认情况下启用 nonce 遵循 Trust On First Use(TOFU)原则。任何能够访问 PKCS#7 身份元数据的非预期方都可以对 Vault 进行身份验证。
在第一次登录期间,Spring Cloud Vault 生成一个存在于 auth 后端的 nonce,除了实例 Id。 Re-authentication 要求发送相同的随机数。任何其他方都没有 nonce 并且可以在 Vault 中发出警报以进行进一步调查。
nonce 保存在 memory 中,并在 application restart 期间丢失。您可以使用spring.cloud.vault.aws-ec2.nonce
配置静态随机数。
AWS-EC2 身份验证角色是可选的,默认为 AMI。您可以通过设置spring.cloud.vault.aws-ec2.role
property 来配置身份验证角色。
示例 103.9. bootstrap.yml 配置角色
spring.cloud.vault:
authentication: AWS_EC2
aws-ec2:
role: application-server
示例 103.10. bootstrap.yml 与所有 AWS EC2 身份验证 properties
spring.cloud.vault:
authentication: AWS_EC2
aws-ec2:
role: application-server
aws-ec2-path: aws-ec2
identity-document: http://...
nonce: my-static-nonce
-
authentication
将此 value 设置为AWS_EC2
选择 AWS EC2 身份验证方法 -
role
sets 设置正在尝试登录的角色的 name。 -
aws-ec2-path
设置要使用的 AWS EC2 装载的路径 -
identity-document
sets PKCS#7 AWS EC2 身份文档的 URL -
nonce
用于 AWS-EC2 身份验证。空 nonce 默认为 nonce 生成
103.5 AWS-IAM 认证
AWS后端为 AWS IAM 角色提供安全的身份验证机制,允许基于 running application 的当前 IAM 角色使用 vault 进行自动身份验证。与大多数 Vault 身份验证后端不同,此后端不需要 first-deploying 或配置 security-sensitive 凭据(令牌,username/password,客户端证书,etc.)。相反,它将 AWS 视为可信第三方,并使用由呼叫者签署的 4 条信息与他们的用于验证调用方确实正在使用该 IAM 角色的 IAM 凭据。
application 正在运行的当前 IAM 角色会自动计算。如果您在 AWS ECS 上运行 application,则 application 将使用分配给 running 容器的 ECS 任务的 IAM 角色。如果您在 EC2 实例上运行 application,那么使用的 IAM 角色将是分配给 EC2 实例的角色。
使用 AWS-IAM 身份验证时,您必须在 Vault 中创建角色并将其分配给您的 IAM 角色。空role
默认为友方 name 当前 IAM 角色。
示例 103.11. bootstrap.yml with required AWS-IAM Authentication properties
spring.cloud.vault:
authentication: AWS_IAM
示例 103.12. bootstrap.yml 所有 AWS-IAM 认证 properties
spring.cloud.vault:
authentication: AWS_IAM
aws-iam:
role: my-dev-role
aws-path: aws
server-id: some.server.name
-
role
sets 设置正在尝试登录的角色的 name。这应该与您的 IAM 角色绑定。如果未提供,则当前 IAM 用户的友好 name 将用作 vault 角色。 -
aws-path
设置要使用的 AWS 挂载的路径 -
server-id
_set value 用于X-Vault-AWS-IAM-Server-ID
标头,防止某些类型的重播攻击。
AWS-IAM 需要 AWS Java SDK 依赖关系(com.amazonaws:aws-java-sdk-core
)作为身份验证 implementation 使用 AWS SDK 类型进行凭据和请求签名。
103.6 TLS 证书身份验证
cert
auth 后端允许使用由 CA 或 self-signed 签名的 SSL/TLS client 证书进行身份验证。
要启用cert
身份验证,您需要:
-
使用 SSL,请参阅第 109 章,Vault Client SSL configuration
-
配置包含 client 证书和私有 key 的 Java
Keystore
-
将
spring.cloud.vault.authentication
设置为CERT
示例 103.13. bootstrap.yml
spring.cloud.vault:
authentication: CERT
ssl:
key-store: classpath:keystore.jks
key-store-password: changeit
cert-auth-path: cert
103.7 Cubbyhole 认证
Cubbyhole 身份验证使用 Vault primitives 来提供安全的身份验证工作流程。 Cubbyhole 身份验证使用令牌作为主要登录方法。一个短暂的令牌用于从 Vault 的 Cubbyhole secret 后端获取第二个登录 VaultToken。登录令牌通常是 longer-lived 并用于与 Vault 交互。登录令牌将从存储在/cubbyhole/response
的包装响应中检索。
创建包装的令牌
响应包装创建令牌需要 Vault 0.6.0 或更高版本。
示例 103.14. 创建和存储令牌
$ 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
示例 103.15. bootstrap.yml
spring.cloud.vault:
authentication: CUBBYHOLE
token: 397ccb93-ff6c-b17b-9389-380b01ca2645
也可以看看:
103.8 Kubernetes 认证
Kubernetes 身份验证机制(自 Vault 0.8.3 以来)允许使用 Kubernetes 服务帐户令牌对 Vault 进行身份验证。身份验证基于角色,角色绑定到服务帐户 name 和命名空间。
包含 pod 的服务帐户的 JWT 令牌的文件将自动安装在/var/run/secrets/kubernetes.io/serviceaccount/token
。
示例 103.16. bootstrap.yml 与所有 Kubernetes 认证 properties
spring.cloud.vault:
authentication: KUBERNETES
kubernetes:
role: my-dev-role
service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token
-
role
sets the Role。 -
service-account-token-file
_set 包含 Kubernetes 服务帐户令牌的文件的位置。默认为/var/run/secrets/kubernetes.io/serviceaccount/token
。
也可以看看: