認証方法
組織が異なれば、セキュリティと認証に対する要件も異なります。Vault は、複数の認証方法を提供することでそのニーズを反映しています。Spring Vault は、複数の認証メカニズムをサポートします。
ログイン資格情報の外部化
安全なシステムへの初回アクセスを取得することは、安全な導入として知られています。Vault にアクセスするには、クライアントは一時的または永続的な資格情報を必要とします。資格情報の外部化は、コードの保守性を高く保つための良いパターンですが、開示が増加するリスクが伴います。
ログイン資格情報を任意の当事者に開示すると、Vault にログインし、基礎となるロールによって許可されているシークレットにアクセスできるようになります。適切なクライアント認証の選択とアプリケーションへの資格情報の挿入は、リスク評価の対象となります。
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 を使用する場合、環境 Bean はまだ構築中であり、オートワイヤーは後の段階で行われるため、@Autowired Environment environment 経由の注入では Environment は提供されません。構成クラスは ApplicationContextAware を実装し、ApplicationContext から Environment を取得する必要があります。 |
コンポーネントおよびその他のプロパティソースのプロパティを参照するサンプルについては、SecurePropertyUsage.java
[GitHub] (英語) を参照してください。
トークン認証
トークンは、Vault 内の認証の中核的な方法です。トークン認証では、静的トークンを提供する必要があります。
トークン認証がデフォルトの認証方法です。トークンが意図しない相手に開示された場合、トークンは Vault へのアクセスを取得し、意図されたクライアントの秘密にアクセスできます。 |
通常、トークン認証は、トークンが外部で作成および更新されるシナリオ ( HashiCorp Vault サービスブローカー [GitHub] (英語) など) で使用されます。実際の設定に応じて、トークンの更新と失効が必要な場合と不要な場合があります。TTL とトークンの取り消しの詳細については、LifecycleAwareSessionManager
を参照してください。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
return new TokenAuthentication("…");
}
// …
}
関連事項:
AppId 認証
AppId 認証は Vault によって非推奨になりました。代わりに AppRole 認証を使用してください。 |
Vault は、推測しにくい 2 つのトークンで構成される AppId (英語) 認証をサポートします。AppId のデフォルトは、静的に構成された spring.application.name
です。2 番目のトークンは UserId で、アプリケーションによって決定される部分であり、通常はランタイム環境に関連します。IP アドレス、Mac アドレス、または Docker コンテナー名が良い例です。Spring Vault は、IP アドレス、Mac アドレス、静的 UserId (システムプロパティ経由で提供されるなど) をサポートします。IP アドレスと Mac アドレスは、16 進数でエンコードされた 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 は、ローカルホストにバインドされたデバイスからネットワークデバイスを取得します。この構成では、適切なデバイスを選択するための 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
を実装できます。このクラスはクラスパス上に存在し、org.springframework.vault.authentication.AppIdUserIdMechanism
インターフェースと createUserId
メソッドを実装する必要があります。Spring Vault は、AppId を使用してトークンを取得する認証を行うたびに、createUserId
を呼び出して UserId を取得します。
public class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = …
return userId;
}
}
AppRole 認証
AppRole (英語) では、非推奨になった (Vault 0.6.1 以降) AppId 認証と同様のマシン認証が可能です。AppRole 認証は、RoleId と SecretId という 2 つの推測困難 (秘密) トークンで構成されます。
Spring Vault は、RoleId のみを提供するか、提供された SecretId とともに提供し、Vault から RoleId/SecretId をフェッチすることにより、AppRole 認証をサポートします (レスポンスアンラップを備えたプッシュモードおよびプルモード)。
@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 (英語) 認証バックエンドは、AWS EC2 インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、AWS を信頼できるサードパーティとして扱い、各 EC2 インスタンスを一意に表す暗号化署名された動的メタデータ情報を使用します。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
return new AwsEc2Authentication(restOperations());
}
// …
}
AWS-EC2 認証により、nonce はデフォルトで Trust On First Use (TOFU) 原則に従うことができます。意図しない当事者が PKCS#7 ID メタデータにアクセスすると、Vault に対して認証を受ける可能性があります。
最初のログイン中に、Spring Vault はインスタンス ID とは別に認証バックエンドに保存される nonce を生成します。再認証には同じ nonce を送信する必要があります。他のパーティは nonce を持たないため、さらなる調査のために Vault でアラートを生成できます。
nonce はメモリ内に保持され、アプリケーションの再起動中に失われます。
AWS-EC2 認証ロールはオプションであり、デフォルトでは AMI になります。認証ロールを構成するには、AwsEc2AuthenticationOptions
で設定します。
AWS-IAM 認証
aws (英語) 認証バックエンドにより、既存の AWS IAM 認証情報を使用した Vault ログインが可能になります。
AWS IAM 認証は、AWS STS GetCallerIdentity
メソッドを使用して署名者の ID を取得するために、Vault によって実行される署名付き HTTP リクエストを作成します。AWSv4 署名には IAM 認証情報が必要です。
IAM 認証情報は、ランタイム環境から取得することも、外部から提供することもできます。IAM プリンシパルが割り当てられた AWS-EC2、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());
}
// …
}
認証実装では認証情報とリクエスト署名に AWS SDK 型を使用するため、AwsIamAuthentication
には AWS Java SDK 依存関係 (com.amazonaws:aws-java-sdk-core
) が必要です。
AwsIamAuthenticationOptions
を介して認証を構成できます。
関連事項:
Azure (MSI) 認証
Azure (英語) 認証バックエンドは、Azure VM インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、Azure を信頼できるサードパーティとして扱い、マネージドサービス ID と 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 は、インスタンス ID の確認に使用できる 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
API を呼び出して取得します。呼び出し元は GCP IAM に対して認証を行い、それによって自身の身元を証明します。この Vault バックエンドは、GCP を信頼できるサードパーティとして扱います。
IAM 認証情報は、ランタイム環境から取得することも、外部から提供することもできます。JSON。JSON は、projects.serviceAccounts.signJwt
の呼び出しに必要なプロジェクト ID とサービスアカウント ID を保持するため、推奨される形式です。
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
GcpIamCredentialsAuthenticationOptions options = GcpIamCredentialsAuthenticationOptions.builder()
.role(…).credential(GoogleCredentials.getApplicationDefault()).build();
GcpIamCredentialsAuthentication authentication = new GcpIamCredentialsAuthentication(options,
restOperations());
}
// …
}
認証実装では資格情報と JWT 署名に Google API を使用するため、GcpIamCredentialsAuthenticationOptions
には Google Cloud Java SDK 依存関係 (com.google.cloud:google-cloud-iamcredentials
) が必要です。
GcpIamCredentialsAuthenticationOptions
を介して認証を構成できます。
Google 資格情報には、トークンのライフサイクルを維持する OAuth 2 トークンが必要です。すべての API は同期であるため、GcpIamCredentialsAuthentication はリアクティブな使用に必要な AuthenticationSteps をサポートしません。 |
GcpIamCredentialsAuthentication は IAM 認証情報 API を使用し、非推奨の IAM API を使用する非推奨の GcpIamAuthentication の代替です。 |
関連事項:
PCF 認証
pcf (英語) 認証バックエンドにより、PCF インスタンスの Vault ログインが可能になります。PCF のアプリとコンテナーの ID 保証 (英語) を利用します。
PCF 認証は、インスタンスキーと証明書を使用して、Vault によって検証される署名を作成します。署名が一致し、バインドされている組織 / スペース / アプリケーション 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
では、RSA-PSS 署名を作成するために BouncyCastle (英語) ライブラリが必要です。
PcfAuthenticationOptions
を介して認証を構成できます。
関連事項:
TLS 証明書認証
cert
認証バックエンドでは、CA によって署名された、または自己署名された SSL/TLS クライアント証明書を使用した認証が可能になります。
cert
認証を有効にするには、次のことを行う必要があります。
SSL を使用します。[vault.client-ssl] を参照してください
クライアント証明書と秘密鍵を含む Java
Keystore
を構成する
@Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
ClientCertificateAuthenticationOptions options = ClientCertificateAuthenticationOptions.builder()
.path(…).build();
return new ClientCertificateAuthentication(options, restOperations());
}
// …
}
カビーホール認証
Cubbyhole 認証は、Vault プリミティブを使用して、安全な認証ワークフローを提供します。Cubbyhole 認証では、主要なログイン方法としてトークンが使用されます。一時トークンは、Vault の Cubbyhole シークレットバックエンドから 2 番目のログイン VaultToken を取得するために使用されます。ログイントークンは通常、有効期間が長く、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 から取得されたトークンは、トークンの作成時に TTL を開始します。この時間は、アプリケーションの起動と必ずしも一致するとは限りません。初期遅延を補うために、Cubbyhole 認証はゼロ以外の TTL に関連付けられたトークンの自己検索を実行して、残りの TTL を取得します。Cubbyhole 認証は、TTL なしではラップされたトークンを自己検索しません。これは、TTL がゼロの場合、TTL が関連付けられていないことを示すためです。
ラップされていないトークンは、トークンを取得するだけでは、更新可能性と TTL に関する詳細を提供しません。セルフルックアップは、更新可能性と残りの TTL をルックアップします。
関連事項:
JWT 認証
JWT 認証を構成するには、トークンまたは JWT サプライヤーが必要です。JwtAuthenticationOptions
を介して認証を構成できます。
Vault 側では、JWT 認証バックエンドを有効にしてロールを作成することで、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 認証バックエンドでサポートされています。
ユーザー名およびパスワード (
userpass
)LDAP (
ldap
)オクタ (
okta
、追加の時間ベースのワンタイムトークンをサポートします)RADIUS (
radius
)
ログイン API はすべてのメカニズムで類似しているため、UserPasswordAuthenticationOptions
は上記のすべての認証バックエンドで使用できます。UserPasswordAuthenticationOptions
を構成するときは、必ず適切な認証マウントパスを使用してください。
UserPasswordAuthentication
の構成 @Configuration
class AppConfig extends AbstractVaultConfiguration {
// …
@Override
public ClientAuthentication clientAuthentication() {
UserPasswordAuthenticationOptions options = UserPasswordAuthenticationOptions.builder()
.username(…).password(…).build();
return new UserPasswordAuthentication(options, restOperations());
}
// …
}
関連事項:
認証手順
ClientAuthentication
オブジェクトは認証フローを記述し、実際の認証手順を実行します。事前に作成された認証は使いやすく、同期実行への緊密なバインドを使用して構成するのも簡単です。
ClientAuthentication
オブジェクトでは、ログインペイロードを Vault に送信したり、HTTP ソースから認証入力を取得したりするなど、認証メソッドの構成や一般的な手順の再利用は意図されていません。
認証ステップにより、一般的な認証アクティビティが再利用可能になります。AuthenticationSteps
によって作成されたステップは、実際の認証の実行を特定の実行者に任せる関数スタイルで認証フローを記述します。
AuthenticationSteps.just(VaultToken.of(…)); (1)
1 | VaultToken のみから AuthenticationSteps を作成します。 |
シングルステップ認証フローは、単一の入力から作成できます。複数の認証ステップを宣言するフローは、ログインのために Vault にマップまたはポストするために使用できる認証状態オブジェクトを提供する Supplier
または HttpRequest
で始まります。
AuthenticationSteps.fromSupplier( (1)
() -> getAppRoleLogin(options.getRoleId(), options.getSecretId())) (2)
.login("auth/{mount}/login", options.getPath()); (3)
1 | Supplier<T> を受け入れる AuthenticationSteps の宣言を開始します。状態オブジェクトの型は、後の手順でマップできる Supplier レスポンスの型によって異なります。 |
2 | 実際の Supplier 実装。この場合は Map を作成します。 |
3 | Vault トークン作成のために状態オブジェクト (Map ) を Vault エンドポイントにポストすることにより、Vault ログインを実行します。テンプレート変数は URL エスケープの対象となることに注意してください。 |
認証フローでは、実際のログインを実行する実行者が必要です。さまざまな実行モデルに対応する 2 つのエグゼキューターが提供されています。
同期
ClientAuthentication
のドロップイン置換としてのAuthenticationStepsExecutor
。AuthenticationStepsOperator
(リアクティブ実行用)。
多くの ClientAuthentication
には、認証固有のオプション用に AuthenticationSteps
を作成するための静的ファクトリメソッドが付属しています。
AuthenticationSteps
実行 CubbyholeAuthenticationOptions options = …
RestOperations restOperations = …
AuthenticationSteps steps = CubbyholeAuthentication.createAuthenticationSteps(options);
AuthenticationStepsExecutor executor = new AuthenticationStepsExecutor(steps, restOperations);
VaultToken token = executor.login();
トークンのライフサイクル
Vault のトークンは存続期間に関連付けることができます。認証方法によって取得されたトークンは、セッションがアクティブである限り使用されることを目的としており、アプリケーションがアクティブである間は期限切れになりません。
Spring Vault は、LifecycleAwareSessionManager
(Javadoc) とともに、ターミナル TTL に達するまでトークンを更新し、その後別のログインを実行してセッションに関連付けられた次のトークンを取得できるセッションマネージャーを提供します。
認証方法に応じて、ログインで 2 種類のトークンを作成できます。
VaultToken
(Javadoc) : 実際のトークンをカプセル化した汎用トークン。LoginToken
(Javadoc) : 再生可能性 /TTL に関連付けられたトークン。
TokenAuthentication
(Javadoc) などの認証方法では、更新可能性や TTL の詳細を持たない VaultToken
が作成されるだけです。LifecycleAwareSessionManager
(Javadoc) はトークンの自己検索を実行し、Vault から更新可能性と TTL を取得します。自己検索が有効になっている場合、VaultToken
は定期的に更新されます。VaultToken
は決して取り消されず、取り消されるのは LoginToken
のみであることに注意してください。
LoginToken
を直接作成する認証方法 (すべてのログインベースの認証方法) では、トークン更新のセットアップに必要なすべての詳細がすでに提供されています。セッションマネージャーがシャットダウンされると、ログインから取得したトークンは LifecycleAwareSessionManager
によって取り消されます。