認証方法

組織が異なれば、セキュリティと認証に対する要件も異なります。Vault は、複数の認証方法を提供することでそのニーズを反映しています。Spring Vault は、複数の認証メカニズムをサポートします。

ログイン資格情報の外部化

安全なシステムへの初回アクセスを取得することは、安全な導入として知られています。Vault にアクセスするには、クライアントは一時的または永続的な資格情報を必要とします。資格情報の外部化は、コードの保守性を高く保つための良いパターンですが、開示が増加するリスクが伴います。

ログイン資格情報を任意の当事者に開示すると、Vault にログインし、基礎となるロールによって許可されているシークレットにアクセスできるようになります。適切なクライアント認証の選択とアプリケーションへの資格情報の挿入は、リスク評価の対象となります。

Spring の PropertySource の抽象化は、構成をアプリケーションコードの外に保持するのに自然に適合します。システムプロパティ、環境変数、プロパティファイルを使用して、ログイン資格情報を保存できます。各アプローチには独自の特性があります。コマンドラインと環境のプロパティは、適切な OS アクセスレベルでイントロスペクトできることに留意してください。

例 1: 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 を取得します。

MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {

    String userId = …
    return userId;
  }
}

関連事項: Vault ドキュメント: App ID 認証バックエンドの使用 (英語)

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());
    }

    // …
}

関連事項: Vault ドキュメント: AppRole 認証バックエンドの使用 (英語)

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 で設定します。

関連事項: Vault ドキュメント: AWS-EC2 認証バックエンドの使用 (英語)

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());
    }

    // …
}
例 2: 認証情報ソースとして AWS-EC2 インスタンスプロファイルを使用する 
@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 認証を有効にするには、次のことを行う必要があります。

  1. SSL を使用します。[vault.client-ssl] を参照してください

  2. クライアント証明書と秘密鍵を含む Java Keystore を構成する 

@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        ClientCertificateAuthenticationOptions options = ClientCertificateAuthenticationOptions.builder()
                .path(…).build();

        return new ClientCertificateAuthentication(options, restOperations());
    }

    // …
}

関連事項: Vault ドキュメント: Cert 認証バックエンドの使用 (英語)

カビーホール認証

Cubbyhole 認証は、Vault プリミティブを使用して、安全な認証ワークフローを提供します。Cubbyhole 認証では、主要なログイン方法としてトークンが使用されます。一時トークンは、Vault の Cubbyhole シークレットバックエンドから 2 番目のログイン VaultToken を取得するために使用されます。ログイントークンは通常、有効期間が長く、Vault との対話に使用されます。ログイントークンは、ラップされたレスポンスまたは data セクションから取得できます。

ラップされたトークンの作成

トークン作成のためのレスポンス折り返しには Vault 0.6.0 以降が必要です。
例 3: トークンのクレートと保管 
$ 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
例 4: ラップされたトークンレスポンスの使用 
@Configuration
class AppConfig extends AbstractVaultConfiguration {

    // …

    @Override
    public ClientAuthentication clientAuthentication() {

        CubbyholeAuthenticationOptions options = CubbyholeAuthenticationOptions
                .builder()
                .initialToken(VaultToken.of("…"))
                .wrapped()
                .build();

        return new CubbyholeAuthentication(options, restOperations());
    }

    // …
}

保存されたトークンの使用

例 5: トークンのクレートと保管 
$ 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
例 6: 保存されたトークンレスポンスの使用 
@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 を構成するときは、必ず適切な認証マウントパスを使用してください。

例 7: 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 によって作成されたステップは、実際の認証の実行を特定の実行者に任せる関数スタイルで認証フローを記述します。

例 8: 保存されたトークンの認証フロー。
AuthenticationSteps.just(VaultToken.of(…));                              (1)
1VaultToken のみから AuthenticationSteps を作成します。

シングルステップ認証フローは、単一の入力から作成できます。複数の認証ステップを宣言するフローは、ログインのために Vault にマップまたはポストするために使用できる認証状態オブジェクトを提供する Supplier または HttpRequest で始まります。

例 9: AppRole 認証フロー 
AuthenticationSteps.fromSupplier(                                       (1)

    () -> getAppRoleLogin(options.getRoleId(), options.getSecretId()))  (2)

    .login("auth/{mount}/login", options.getPath());                    (3)
1Supplier<T> を受け入れる AuthenticationSteps の宣言を開始します。状態オブジェクトの型は、後の手順でマップできる Supplier レスポンスの型によって異なります。
2 実際の Supplier 実装。この場合は Map を作成します。
3Vault トークン作成のために状態オブジェクト (Map) を Vault エンドポイントにポストすることにより、Vault ログインを実行します。テンプレート変数は URL エスケープの対象となることに注意してください。

認証フローでは、実際のログインを実行する実行者が必要です。さまざまな実行モデルに対応する 2 つのエグゼキューターが提供されています。

  • 同期 ClientAuthentication のドロップイン置換としての AuthenticationStepsExecutor。

  • AuthenticationStepsOperator (リアクティブ実行用)。

多くの ClientAuthentication には、認証固有のオプション用に AuthenticationSteps を作成するための静的ファクトリメソッドが付属しています。

例 10: 同期 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 種類のトークンを作成できます。

TokenAuthentication (Javadoc) などの認証方法では、更新可能性や TTL の詳細を持たない VaultToken が作成されるだけです。LifecycleAwareSessionManager (Javadoc) はトークンの自己検索を実行し、Vault から更新可能性と TTL を取得します。自己検索が有効になっている場合、VaultToken は定期的に更新されます。VaultToken は決して取り消されず、取り消されるのは LoginToken のみであることに注意してください。

LoginToken を直接作成する認証方法 (すべてのログインベースの認証方法) では、トークン更新のセットアップに必要なすべての詳細がすでに提供されています。セッションマネージャーがシャットダウンされると、ログインから取得したトークンは LifecycleAwareSessionManager によって取り消されます。