101. Authentication methods
不同的组织对安全性和身份验证有不同的要求。Vault通过提供多种身份验证方法来反映这种需求。 Spring Cloud Vault 支持令牌和 AppId 身份验证。
101.1 令牌认证
令牌是Vault中身份验证的核心方法。令牌认证要求使用Bootstrap 应用程序上下文提供静态令牌。
Note
令牌认证是默认的认证方法。如果公开了令牌,则意外的一方将获得对Vault的访问权,并可以访问目标 Client 的机密。
实施例 101.1. bootstrap.yml
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000
-
authentication
将此值设置为TOKEN
选择令牌认证方法 -
token
设置要使用的静态令牌
另请参阅:Vault文档:令牌
101.2 AppId 身份验证
Vault支持AppId身份验证,该身份验证由两个难以猜测的令牌组成。 AppId 默认为静态配置的spring.application.name
。第二个令牌是 UserId,它是应用程序确定的一部分,通常与运行时环境有关。 IP 地址,Mac 地址或 Docker 容器名称就是很好的例子。 Spring Cloud Vault Config 支持 IP 地址,Mac 地址和静态用户 ID(例如通过系统属性提供)。 IP 和 Mac 地址表示为十六进制编码的 SHA256 哈希。
基于 IP 地址的 UserId 使用 localhost 的 IP 地址。
实施例 101.2. bootstrap.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
Note
包含echo
的换行符会导致不同的哈希值,因此请确保包含-n
标志。
基于 Mac 地址的 UserId 从 localhost 绑定的设备获取其网络设备。该配置还允许指定network-interface
提示以选择正确的设备。 network-interface
的值是可选的,可以是接口名称或接口索引(从 0 开始)。
实施例 101.3. bootstrap.yml 使用 SHA256 Mac-Address 用户 ID
spring.cloud.vault:
authentication: APPID
app-id:
user-id: MAC_ADDRESS
network-interface: eth0
network-interface
设置网络接口以获取物理地址
从命令行生成 IP 地址 UserId 的相应命令是:
$ echo -n 0AFEDE1234AC | sha256sum
Note
Mac 地址指定为大写且没有冒号。包含echo
的换行符会导致不同的哈希值,因此请确保包含-n
标志。
101.2.1 自定义用户 ID
UserId 生成是一种开放机制。您可以将spring.cloud.vault.app-id.user-id
设置为任何字符串,并且配置的值将用作静态 UserId。
使用更高级的方法,可以将spring.cloud.vault.app-id.user-id
设置为类名。此类必须在您的 Classpath 上,并且必须实现org.springframework.cloud.vault.AppIdUserIdMechanism
接口和createUserId
方法。 Spring Cloud Vault 每次使用 AppId 进行身份验证以获取令牌时,都会通过调用createUserId
来获取 UserId。
实施例 101.4. bootstrap.yml
spring.cloud.vault:
authentication: APPID
app-id:
user-id: com.examlple.MyUserIdMechanism
实施例 101.5. MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = ...
return userId;
}
}
101.3 AppRole 身份验证
AppRole用于机器身份验证,例如已弃用(自 Vault 0.6.1 起)第 101.2 节“ AppId 身份验证”。 AppRole 身份验证包含两个很难猜测(Secret)的令牌:RoleId 和 SecretId。
Spring Vault 支持各种 AppRole 方案(推/拉模式和包装)。
RoleId 和可选的 SecretId 必须由配置提供,Spring Vault 不会查找它们或创建自定义 SecretId。
实施例 101.6. 具有 AppRole 身份验证属性的 bootstrap.yml
spring.cloud.vault:
authentication: APPROLE
app-role:
role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
支持以下方案以及必需的配置详细信息:
表 101.1. Configuration
Method | RoleId | SecretId | RoleName | Token |
Provided RoleId/SecretId | Provided | Provided | ||
提供的 RoleId 不含 SecretId | Provided | |||
提供的 RoleId,Pull SecretId | Provided | Provided | Provided | Provided |
拉出 RoleId,提供 SecretId | Provided | Provided | Provided | |
全拉模式 | Provided | Provided | ||
Wrapped | Provided | |||
包装好的 RoleId,提供 SecretId | Provided | Provided | ||
提供的 RoleId,包装的 SecretId | Provided | Provided |
表 101.2. 拉/推/包裹矩阵
RoleId | SecretId | Supported |
Provided | Provided | ✅ |
Provided | Pull | ✅ |
Provided | Wrapped | ✅ |
Provided | Absent | ✅ |
Pull | Provided | ✅ |
Pull | Pull | ✅ |
Pull | Wrapped | ❌ |
Pull | Absent | ❌ |
Wrapped | Provided | ✅ |
Wrapped | Pull | ❌ |
Wrapped | Wrapped | ✅ |
Wrapped | Absent | ❌ |
Note
通过在引导上下文中提供已配置的AppRoleAuthentication
bean,您仍然可以使用推/拉/包装模式的所有组合。 Spring Cloud Vault 无法从配置属性中导出所有可能的 AppRole 组合。
Tip
AppRole 身份验证仅限于使用反应式基础结构的简单拉模式。尚不支持全拉模式。通过将 Spring Cloud Vault 与 Spring WebFlux 堆栈一起使用,可以启用 Vault 的反应式自动配置,可以通过设置spring.cloud.vault.reactive.enabled=false
禁用它。
实施例 101.7. 具有所有 AppRole 身份验证属性的 bootstrap.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(请参见bind_secret_id
),则可以省略 SecretId。 -
role
:设置拉模式的 AppRole 名称。 -
app-role-path
设置要使用的方法认证安装的路径。
另请参阅:Vault文件:使用 AppRole 身份验证后端
101.4 AWS-EC2 身份验证
aws-ec2 auth 后端为 AWS EC2 实例提供了一种安全的引入机制,允许自动检索Vault令牌。与大多数 Vault 身份验证后端不同,此后端不需要先部署或配置安全敏感的凭据(令牌,用户名/密码,Client 端证书等)。相反,它将 AWS 视为受信任的第三方,并使用经过加密签名的动态元数据信息来唯一表示每个 EC2 实例。
实施例 101.8. 使用 AWS-EC2 身份验证的 bootstrap.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
属性来配置身份验证角色。
实施例 101.9. 具有配置角色的 bootstrap.yml
spring.cloud.vault:
authentication: AWS_EC2
aws-ec2:
role: application-server
实施例 101.10. 具有所有 AWS EC2 身份验证属性的 bootstrap.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 身份验证。空随机数默认为随机数生成
101.5 AWS-IAM 身份验证
aws后端为 AWS IAM 角色提供了一种安全的身份验证机制,从而可以基于正在运行的应用程序的当前 IAM 角色使用保管库进行自动身份验证。与大多数 Vault 身份验证后端不同,此后端不需要先部署或配置安全敏感的凭据(令牌,用户名/密码,Client 端证书等)。相反,它将 AWS 视为受信任的第三方,并使用调用者使用其 IAM 凭证签名的 4 条信息来验证调用者确实在使用该 IAM 角色。
应用程序正在其中运行的当前 IAM 角色是自动计算的。如果您在 AWS ECS 上运行应用程序,则该应用程序将使用分配给正在运行的容器的 ECS 任务的 IAM 角色。如果您在 EC2 实例之上裸身运行应用程序,则使用的 IAM 角色将是分配给 EC2 实例的角色。
使用 AWS-IAM 身份验证时,您必须在 Vault 中创建一个角色并将其分配给您的 IAM 角色。空的role
默认为当前 IAM 角色的友好名称。
实施例 101.11. 具有必需的 AWS-IAM 身份验证属性的 bootstrap.yml
spring.cloud.vault:
authentication: AWS_IAM
实施例 101.12. 具有所有 AWS-IAM 身份验证属性的 bootstrap.yml
spring.cloud.vault:
authentication: AWS_IAM
aws-iam:
role: my-dev-role
aws-path: aws
server-id: some.server.name
-
role
设置尝试进行登录的角色的名称。这应该与您的 IAM 角色绑定。如果未提供,则将使用当前 IAM 用户的友好名称作为保管库角色。 -
aws-path
设置要使用的 AWS 装载的路径 -
server-id
设置用于X-Vault-AWS-IAM-Server-ID
Headers 的值,以防止某些类型的重放攻击。
AWS-IAM 需要 AWS Java SDK 依赖项(com.amazonaws:aws-java-sdk-core
),因为身份验证实现将 AWS 开发工具包类型用于凭证和请求签名。
101.6 Azure MSI 身份验证
azure auth 后端为 Azure VM 实例提供了一种安全的引入机制,允许自动检索 Vault 令牌。与大多数 Vault 身份验证后端不同,此后端不需要先部署或配置安全敏感的凭据(令牌,用户名/密码,Client 端证书等)。而是将 Azure 视为受信任的第三方,并使用可以绑定到 VM 实例的托管服务身份和实例元数据信息。
实施例 101.13. bootstrap.yml 具有必需的 Azure 身份验证属性
spring.cloud.vault:
authentication: AZURE_MSI
azure-msi:
role: my-dev-role
实施例 101.14. 具有所有 Azure 身份验证属性的 bootstrap.yml
spring.cloud.vault:
authentication: AZURE_MSI
azure-msi:
role: my-dev-role
azure-path: aws
-
role
设置尝试进行登录的角色的名称。 -
azure-path
设置要使用的 Azure 装载的路径
Azure MSI 身份验证从实例元数据服务中获取有关虚拟机的环境详细信息(订阅 ID,资源组,VM 名称)。
101.7 TLS 证书认证
cert
auth 后端允许使用由 CA 签名或自签名的 SSL/TLSClient 端证书进行身份验证。
要启用cert
身份验证,您需要:
-
使用 SSL,请参阅第 109 章,Vault Client SSL 配置
-
配置包含 Client 端证书和私钥的 Java
Keystore
-
将
spring.cloud.vault.authentication
设置为CERT
实施例 101.15. bootstrap.yml
spring.cloud.vault:
authentication: CERT
ssl:
key-store: classpath:keystore.jks
key-store-password: changeit
cert-auth-path: cert
101.8 Cubbyhole 身份验证
Cubbyhole 身份验证使用保管库 Primitives 提供安全的身份验证工作流。 Cubbyhole 身份验证使用令牌作为主要登录方法。临时令牌用于从 Vault 的 CubbyholeSecret 后端获取第二个登录 VaultToken。登录令牌通常使用寿命更长,并用于与Vault进行交互。将从存储在/cubbyhole/response
的包装响应中检索登录令牌。
创建包装的令牌
Note
用于创建令牌的响应包装需要 Vault 0.6.0 或更高版本。
实施例 101.16. 创建和存储令牌
$ 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
实施例 101.17. bootstrap.yml
spring.cloud.vault:
authentication: CUBBYHOLE
token: 397ccb93-ff6c-b17b-9389-380b01ca2645
See also: