|
此版本仍在开发中，尚未被视为稳定版本。对于最新的稳定版本，请使用 Spring Vault 3.1.2！ |
身份验证方法
不同的组织对安全性有不同的要求 和身份验证。Vault 通过提供多重身份验证来反映这一需求 方法。Spring Vault 支持多种身份验证机制。
外部化登录凭证
首次访问安全系统称为安全引入。 任何客户端都需要临时或永久凭证才能访问 Vault。外部化凭证 是保持代码可维护性的良好模式，但存在增加泄露的风险。
向任何一方泄露登录凭证允许登录 Vault 并访问以下 Secret 由基础角色允许。选择适当的客户端身份验证，然后 将凭证注入应用程序需要接受风险评估。
Spring 的 PropertySource 抽象是天作之合 将配置保留在应用程序代码之外。您可以使用系统属性、环境 变量或属性文件来存储登录凭据。每种方法都有自己的属性。 请记住，命令行和环境属性可以通过适当的 OS 访问级别。
vault.token添加到属性文件@PropertySource("configuration.properties")
@Configuration
public class Config extends AbstractVaultConfiguration {
@Override
public ClientAuthentication clientAuthentication() {
return new TokenAuthentication(getEnvironment().getProperty("vault.token"));
}
}Spring 允许通过多种方式获取Environment.使用VaultPropertySource、 注射通孔@Autowired Environment environment不会提供Environment由于 Environment bean 仍在构建中，autowire 将在稍后阶段进行。您的 configuration 类应该实现ApplicationContextAware并获取Environment从ApplicationContext. |
看SecurePropertyUsage.java有关在组件和其他属性源中引用属性的示例。
Token 鉴权
令牌是 Vault 中身份验证的核心方法。 Token 身份验证需要提供静态 Token。
| Token authentication 是默认的身份验证方法。 如果令牌被披露为非预期方，则它将获得对 Vault 的访问权限，并且 可以访问预期客户端的密钥。 |
通常，令牌身份验证用于创建和更新令牌的方案
外部（例如 HashiCorp Vault 服务代理）。
根据实际设置，您可能希望也可能不希望令牌续订和撤销。
看LifecycleAwareSessionManager了解有关 TTL 和 Token 吊销的详细信息。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
return new TokenAuthentication("…");
}
// …
}另请参阅：
AppId 鉴权
| Vault 已弃用 AppId 身份验证。请改用 AppRole 身份验证。 |
Vault 支持由两个难以猜测的令牌组成的 AppId 身份验证。The AppId
默认为spring.application.name这是静态配置的。
第二个 Token 是 UserId，它是应用程序确定的一部分，
通常与运行时环境相关。IP 地址、Mac 地址或
Docker 容器名称就是很好的示例。Spring Vault 支持
IP 地址、Mac 地址和静态 UserId（例如，通过系统属性提供）。
IP 和 Mac 地址表示为十六进制编码的 SHA256 哈希。
基于 IP 地址的 UserId 使用本地主机的 IP 地址。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AppIdAuthenticationOptions options = AppIdAuthenticationOptions.builder()
.appId("myapp")
.userIdMechanism(new IpAddressUserId())
.build();
return new AppIdAuthentication(options, restOperations());
}
// …
}从命令行生成 IP 地址 UserId 的相应命令是：
$ echo -n 192.168.99.1 | sha256sum
包括echo导致不同的哈希值
因此，请确保包含-n旗。 |
基于 Mac 地址的 UserId 从
localhost 绑定的设备。该配置还允许指定
一个network-interface提示选择正确的设备。的值network-interface是可选的，可以是接口
名称或接口索引（从 0 开始）。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AppIdAuthenticationOptions options = AppIdAuthenticationOptions.builder()
.appId("myapp")
.userIdMechanism(new MacAddressUserId())
.build();
return new AppIdAuthentication(options, restOperations());
}
// …
}从命令行生成 Mac 地址 UserId 的相应命令是：
$ echo -n 0AFEDE1234AC | sha256sum
Mac 地址指定为大写，不带冒号。
包括echo导致不同的哈希值
因此，请确保包含-n旗。 |
自定义 UserId
更高级的方法允许您实现自己的AppIdUserIdMechanism.
此类必须位于您的 Classpath 上，并且必须实现
这org.springframework.vault.authentication.AppIdUserIdMechanism接口
和createUserId方法。Spring Vault 将获取 UserId
通过调用createUserId每次使用 AppId 进行身份验证时，都会将 AppId 迁移到
获取 Token。
public class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = …
return userId;
}
}AppRole 身份验证
AppRole 允许计算机 身份验证，就像已弃用的（自 Vault 0.6.1 起）AppId 身份验证一样。 AppRole 身份验证由两个难以猜测的（秘密）令牌组成：RoleId 和 SecretId。
Spring Vault 通过仅提供 RoleId 来支持 AppRole 身份验证 或者与提供的 SecretId 一起从 Vault 获取 RoleId/SecretId （带有响应展开的推拉模式）。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AppRoleAuthenticationOptions options = AppRoleAuthenticationOptions.builder()
.roleId(RoleId.provided("…"))
.secretId(SecretId.wrapped(VaultToken.of("…")))
.build();
return new AppRoleAuthentication(options, restOperations());
}
// …
}Spring Vault 也支持全量拉取模式：如果未提供 RoleId 和 SecretId， Spring Vault 将使用角色名称和初始令牌来检索它们。这 初始令牌可能与 TTL 和使用限制相关联。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
VaultToken initialToken = VaultToken.of("…");
AppRoleAuthenticationOptions options = AppRoleAuthenticationOptions.builder()
.appRole("…")
.roleId(RoleId.pull(initialToken))
.secretId(SecretId.pull(initialToken))
.build();
return new AppRoleAuthentication(options, restOperations());
}
// …
}AWS-EC2 身份验证
aws-ec2 auth 后端提供了一种安全的引入机制 对于 AWS EC2 实例，允许自动检索文件库 令 牌。与大多数 Vault 身份验证后端不同，此后端 不需要首先部署或预置安全敏感型 凭据（令牌、用户名/密码、客户端证书等）。 相反，它将 AWS 视为受信任的第三方，并使用 加密签名的动态元数据信息，该信息具有唯一性 表示每个 EC2 实例。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
return new AwsEc2Authentication(restOperations());
}
// …
}AWS-EC2 身份验证默认启用 nonce 跟随 首次使用时信任 （TOFU） 原则。任何意外的一方 获得对 PKCS#7 身份元数据的访问权限可以进行身份验证 对抗 Vault。
在第一次登录期间， Spring Vault 会生成一个 nonce ，该实例 ID 存储在 auth 后端中。 重新身份验证需要发送相同的 nonce。任何其他 参与方没有 nonce，并且可以在 Vault 中引发警报 进一步调查。
nonce 保存在内存中，并在应用程序重启期间丢失。
从 Spring Vault 3.2 开始，AWS-EC2 身份验证支持请求/响应 （IMDSv1） 元数据检索和基于会话的变体 （IMDSv2）。
AWS-EC2 身份验证角色是可选的，默认为 AMI。
您可以通过设置
它在AwsEc2AuthenticationOptions.
AWS-IAM 身份验证
aws auth 后端允许使用现有 AWS IAM 凭证登录 Vault。
AWS IAM 身份验证会创建一个签名的 HTTP 请求，该请求是
由 Vault 执行，以使用 AWS STS 获取签名者的身份GetCallerIdentity方法。AWSv4 签名需要 IAM 凭证。
IAM 凭证可以从运行时环境中获取 或外部供应。运行时环境，例如 AWS-EC2、 具有分配的 IAM 委托人的 Lambda 和 ECS 不需要特定于客户端的 配置凭证，但可以从其元数据源获取这些凭证。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AwsIamAuthenticationOptions options = AwsIamAuthenticationOptions.builder()
.credentials(new BasicAWSCredentials(…)).build();
return new AwsIamAuthentication(options, restOperations());
}
// …
}@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AwsIamAuthenticationOptions options = AwsIamAuthenticationOptions.builder()
.credentialsProvider(InstanceProfileCredentialsProvider.getInstance()).build();
return new AwsIamAuthentication(options, restOperations());
}
// …
}AwsIamAuthentication需要 AWS Java 开发工具包依赖项 （com.amazonaws:aws-java-sdk-core)
因为身份验证实施使用 AWS 开发工具包类型进行凭证和请求签名。
您可以通过以下方式配置身份验证AwsIamAuthenticationOptions.
另请参阅：
Azure （MSI） 身份验证
azure auth 后端提供了一种安全的引入机制 对于 Azure VM 实例，允许自动检索 Vault 令 牌。与大多数 Vault 身份验证后端不同，此后端 不需要首先部署或预置安全敏感型 凭据（令牌、用户名/密码、客户端证书等）。 相反，它将 Azure 视为受信任的第三方，并使用 托管服务身份和实例元数据信息，可以是 绑定到 VM 实例。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
AzureMsiAuthenticationOptions options = AzureMsiAuthenticationOptions.builder()
.role(…).build();
return new AzureMsiAuthentication(options, restOperations());
}
// …
}Azure 身份验证需要有关 VM 环境的详细信息（订阅 ID、
资源组名称、VM 名称）。这些详细信息可以通过AzureMsiAuthenticationOptionsBuilder.
如果未配置，则AzureMsiAuthentication查询 Azure 的实例元数据服务以
获取这些详细信息。
另请参阅：
GCP-GCE 身份验证
gcp auth 后端允许使用现有的 GCP （Google Cloud Platform） IAM 和 GCE 凭证登录 Vault。
GCP GCE （Google Compute Engine） 身份验证以 服务账户的 JSON Web 令牌 （JWT）。Compute Engine 实例的 JWT 使用实例标识从 GCE 元数据服务获取。 此 API 创建可用于确认实例身份的 JSON Web 令牌。
与大多数 Vault 身份验证后端不同，此后端 不需要首先部署或预置安全敏感型 凭据（令牌、用户名/密码、客户端证书等）。 相反，它将 GCP 视为受信任的第三方，并使用 加密签名的动态元数据信息，该信息具有唯一性 表示每个 GCP 服务帐户。
您可以通过以下方式配置身份验证GcpComputeAuthenticationOptions.
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
GcpComputeAuthenticationOptions options = GcpComputeAuthenticationOptions.builder()
.role(…).build();
GcpComputeAuthentication authentication = new GcpComputeAuthentication(options,
restOperations());
}
// …
}另请参阅：
GCP-IAM 身份验证
gcp auth 后端允许使用现有的 GCP （Google Cloud Platform） IAM 和 GCE 凭证登录 Vault。
GCP IAM 身份验证以 JSON Web 令牌 （JWT） 的形式创建签名
对于服务帐户。服务帐户的 JWT 由
调用 GCP IAM 的projects.serviceAccounts.signJwt应用程序接口。调用方根据 GCP IAM 进行身份验证
并由此证明了它的身份。此保险柜后端将 GCP 视为受信任的第三方。
IAM 凭证可以从运行时环境中获取
或作为 e.g. JSON 从外部供应。JSON 是首选形式，因为它
携带调用projects.serviceAccounts.signJwt.
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
GcpIamCredentialsAuthenticationOptions options = GcpIamCredentialsAuthenticationOptions.builder()
.role(…).credential(GoogleCredentials.getApplicationDefault()).build();
GcpIamCredentialsAuthentication authentication = new GcpIamCredentialsAuthentication(options,
restOperations());
}
// …
}GcpIamCredentialsAuthenticationOptions需要 Google Cloud Java SDK 依赖项
(com.google.cloud:google-cloud-iamcredentials)
因为身份验证实施使用 Google API 进行凭据和 JWT 签名。
您可以通过以下方式配置身份验证GcpIamCredentialsAuthenticationOptions.
Google 凭据需要 OAuth 2 令牌来维护令牌生命周期。所有 API
是同步的，因此，GcpIamCredentialsAuthentication不支持AuthenticationSteps哪个是
对于反应式使用是必需的。 |
GcpIamCredentialsAuthentication使用 IAM 凭证 API，并使用已弃用的GcpIamAuthentication使用已弃用的 IAM API。 |
另请参阅：
GitHub 身份验证
github auth 后端提供了基于 GitHub 令牌的鉴权机制。 Vault 不支持使用 OAuth 工作流程生成 GitHub 令牌， 因此它不充当 GitHub 应用程序。
身份验证机制需要 GitHub 令牌（或供应商） 将令牌传递给 Vault，然后 Vault 根据你的 GitHub 进行身份验证 帐户。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
GitHubAuthentication options = GitHubAuthentication.builder()
.token(…).build();
return new GitHubAuthentication(options, restOperations());
}
// …
}另请参阅：
PCF 身份验证
pcf auth 后端允许 PCF 实例的 Vault 登录。 它利用 PCF 的应用程序和容器身份保证。
PCF 身份验证使用实例密钥和证书创建由 Vault 验证的签名。 如果签名匹配，并且可能绑定的 organization/space/application ID 匹配，则 Vault 会颁发适当范围的令牌。
实例凭证可从以下文件中获取CF_INSTANCE_CERT和CF_INSTANCE_KEY变量。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
PcfAuthenticationOptions options = PcfAuthenticationOptions.builder()
.role(…).build();
PcfAuthentication authentication = new PcfAuthentication(options,
restOperations());
}
// …
}PcfAuthenticationOptions需要 BouncyCastle 库来创建 RSA-PSS 签名。
您可以通过以下方式配置身份验证PcfAuthenticationOptions.
另请参阅：
TLS 证书认证
这certauth backend 允许使用 SSL/TLS 客户端进行身份验证
由 CA 签名或自签名的证书。
要启用cert身份验证您需要：
-
使用 SSL，请参阅 [vault.client-ssl]
-
配置 Java
Keystore，其中包含客户端 certificate 和私有密钥
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
ClientCertificateAuthenticationOptions options = ClientCertificateAuthenticationOptions.builder()
.path(…).build();
return new ClientCertificateAuthentication(options, restOperations());
}
// …
}Cubbyhole 身份验证
Cubbyhole 身份验证使用 Vault 原语来提供安全的身份验证
工作流。Cubbyhole 身份验证使用令牌作为主要登录方法。
临时令牌用于从 Vault 的
Cubbyhole 秘密后端。登录令牌的生命周期通常更长，并且用于
与 Vault 交互。登录令牌可以从包装的
响应或从data部分。
创建包装令牌
| 用于创建令牌的响应包装需要 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-4f3d86a68319@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
CubbyholeAuthenticationOptions options = CubbyholeAuthenticationOptions
.builder()
.initialToken(VaultToken.of("…"))
.wrapped()
.build();
return new CubbyholeAuthentication(options, restOperations());
}
// …
}使用存储的令牌
$ vault token create
Key Value
--- -----
token f9e30681-d46a-cdaf-aaa0-2ae0a9ad0819
token_accessor 4eee9bd9-81bb-06d6-af01-723c54a72148
token_duration 0s
token_renewable false
token_policies [root]
$ vault token create -use-limit=2 -orphan -no-default-policy -policy=none
Key Value
--- -----
token 895cb88b-aef4-0e33-ba65-d50007290780
token_accessor e84b661c-8aa8-2286-b788-f258f30c8325
token_duration 0s
token_renewable false
token_policies [none]
$ export VAULT_TOKEN=895cb88b-aef4-0e33-ba65-d50007290780
$ vault write cubbyhole/token token=f9e30681-d46a-cdaf-aaa0-2ae0a9ad0819@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
CubbyholeAuthenticationOptions options = CubbyholeAuthenticationOptions
.builder()
.initialToken(VaultToken.of("…"))
.path("cubbyhole/token")
.build();
return new CubbyholeAuthentication(options, restOperations());
}
// …
}剩余 TTL/可续订性
从与非零 TTL 关联的 Cubbyhole 中检索的令牌从 令牌创建时间。该时间不一定与申请相同 启动。为了补偿初始延迟，Cubbyhole 身份验证会执行 self lookup 查找与非零 TTL 关联的令牌以检索剩余的 TTL。 Cubbyhole 身份验证不会在没有 TTL 的情况下自查找包装的令牌，因为 零 TTL 表示没有关联的 TTL。
未包装的令牌不会仅提供有关可续订性和 TTL 的详细信息 检索令牌。自查找将查找可续订性和剩余的 TTL。
另请参阅：
JWT 身份验证
配置 JWT 身份验证需要令牌或 JWT 供应商。
您可以通过以下方式配置身份验证JwtAuthenticationOptions.
在 Vault 端，您可以通过启用 JWT auth 后端并创建角色来配置 JWT 后端。
您可以使用oidc_discovery_url,jwks_url或jwt_validation_pubkeys配置 JWT 后端。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
JwtAuthenticationOptions options = JwtAuthenticationOptions.builder()
.role(…).jwt(…).path(…).build();
return new JwtAuthentication(options, restOperations());
}
// …
}另请参阅：
Kubernetes 身份验证
Vault 从 0.8.3 开始支持使用 Kubernetes 令牌进行基于 kubernetes 的身份验证。
使用 Kubernetes 身份验证需要 Kubernetes 服务帐户令牌，
通常安装在/var/run/secrets/kubernetes.io/serviceaccount/token.
该文件包含读取并发送到 Vault 的令牌。
Vault 在登录期间使用 Kubernetes 的 API 验证其有效性。
配置 Kubernetes 身份验证至少需要提供角色名称：
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
KubernetesAuthenticationOptions options = KubernetesAuthenticationOptions.builder()
.role(…).jwtSupplier(…).build();
return new KubernetesAuthentication(options, restOperations());
}
// …
}您可以通过以下方式配置身份验证KubernetesAuthenticationOptions.
另请参阅：
用户名/密码身份验证
用户名/密码通常是最终用户身份验证方案。 多个 Vault 身份验证后端支持使用 username 和 password：
-
用户名和密码 （
userpass) -
LDAP （
ldap) -
Okta （
okta，支持额外的基于时间的一次性令牌） -
半径 （
radius)
UserPasswordAuthenticationOptions可以与上述所有身份验证后端一起使用，因为 Login API 在所有机制中都是相似的。
请确保在配置时使用适当的 auth 挂载路径UserPasswordAuthenticationOptions.
UserPasswordAuthentication@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
UserPasswordAuthenticationOptions options = UserPasswordAuthenticationOptions.builder()
.username(…).password(…).build();
return new UserPasswordAuthentication(options, restOperations());
}
// …
}另请参阅：
身份验证步骤
ClientAuthentication对象描述身份验证流程并执行实际的
身份验证步骤。预先组合的身份验证易于使用和配置
与同步执行的紧密绑定。
身份验证方法的组合和重用常见步骤，例如发布登录
payload 添加到 Vault 或从 HTTP 源检索身份验证输入
跟ClientAuthentication对象。
身份验证步骤提供常见身份验证活动的可重用性。
步骤创建方式AuthenticationSteps在函数式
样式将实际的身份验证执行留给特定的执行程序。
AuthenticationSteps.just(VaultToken.of(…)); (1)| 1 | 创建AuthenticationSteps从VaultToken. |
可以从单个输入创建单步身份验证流程。声明
多个身份验证步骤以Supplier或HttpRequest提供
authentication state 对象，该对象可用于 Map 或 post 到 Vault 进行登录。
AuthenticationSteps.fromSupplier( (1)
() -> getAppRoleLogin(options.getRoleId(), options.getSecretId())) (2)
.login("auth/{mount}/login", options.getPath()); (3)| 1 | 开始声明AuthenticationSteps接受Supplier<T>.
状态对象类型取决于Supplier响应类型，该类型可在后续步骤中映射。 |
| 2 | 实际的Supplier实现。
创建Map在这种情况下。 |
| 3 | 通过提交状态对象 （Map） 添加到 Vault 终端节点以创建 Vault 令牌。
请注意，模板变量受 URL 转义的约束。 |
身份验证流需要执行程序来执行实际登录。我们提供两个 executor 对于不同的执行模型：
-
AuthenticationStepsExecutor作为 SYNCHRONOUS 的直接替代品ClientAuthentication. -
AuthenticationStepsOperator进行响应式执行。
多ClientAuthentication自带的静态工厂方法来创建AuthenticationSteps对于其特定于身份验证的选项：
AuthenticationSteps执行CubbyholeAuthenticationOptions options = …
RestOperations restOperations = …
AuthenticationSteps steps = CubbyholeAuthentication.createAuthenticationSteps(options);
AuthenticationStepsExecutor executor = new AuthenticationStepsExecutor(steps, restOperations);
VaultToken token = executor.login();Token 生命周期
Vault 的令牌可以与生存时间相关联。通过身份验证方法获取的令牌 只要会话处于活动状态，就可以使用，并且在应用程序处于活动状态时不应过期。
Spring Vault 提供了LifecycleAwareSessionManager一个会话管理器，可以更新令牌，直到它到达其终端 TTL，然后执行另一次登录以获取与会话关联的下一个令牌。
根据身份验证方法，登录可以创建两种类型的令牌：
-
VaultToken：封装实际令牌的通用令牌。 -
LoginToken：与 renewability/TTL 关联的令牌。
身份验证方法（如TokenAuthentication只需创建一个VaultToken它不包含任何可续订性/TTL 详细信息。LifecycleAwareSessionManager将对令牌运行自查找，以从 Vault 中检索可续订性和 TTL。VaultToken如果启用了自查找，则会定期续订。请注意，VaultToken永远不会被撤销，只有LoginToken被撤销。
身份验证方法创建LoginToken直接（所有基于登录的身份验证方法）已经提供了设置 Token 续订所需的所有详细信息。从登录中获取的令牌由LifecycleAwareSessionManager如果会话管理器已关闭。