© 2016-2021 the original authors.

このドキュメントのコピーは、印刷物または電子的に配布されるかどうかにかかわらず、そのようなコピーに料金を請求せず、さらに各コピーにこの著作権表示が含まれている場合に限り、自分で使用したり他の人に配布したりするために作成できます。

Spring Cloud Vault Config は、分散システムにおける外部化された設定のクライアント側サポートを提供します。HashiCorp の Vault (英語) を使用すると、すべての環境にわたるアプリケーションの外部シークレットプロパティを一元的に管理できます。Vault は、リモートアプリケーション / リソースのユーザー名 / パスワードなどの静的および動的シークレットを管理し、MySQL、PostgreSQL、Apache Cassandra、Couchbase、MongoDB、Consul、AWS などの外部サービスに資格情報を提供できます。

1. 注目の新機能

このセクションでは、最新リリースで新しく注目に値する項目について簡単に説明します。

1.1. Spring Cloud の新機能 Vault 3.0

  • PropertySource 初期化を Spring Cloud のブートストラップコンテキストから Spring Boot の ConfigData API に移行します。

  • Couchbase データベースバックエンドのサポート。

  • PEM サポートを含む spring.cloud.vault.ssl.key-store-type= … /spring.cloud.vault.ssl.trust-store-type= …  を介したキーストア / トラストストア型の構成。

  • ReactiveVaultEndpointProvider を構成することにより ReactiveDiscoveryClient をサポートします。

  • 複数のデータベースの設定をサポートします。

2. クイックスタート

前提条件

Vault とこのガイドの使用を開始するには、以下を提供する *NIX のようなオペレーティングシステムが必要です。

  • wget、openssl、unzip

  • 少なくとも Java 8 と適切に構成された JAVA_HOME 環境変数

このガイドでは、統合テストのための Spring Cloud Vault の観点から Vault のセットアップについて説明します。スタートガイドは、Vault プロジェクトサイト (learn.hashicorp.com/vault (英語) ) で直接見つけることができます。

Vault をインストールする 

$ wget https://releases.hashicorp.com/vault/${vault_version}/vault_${vault_version}_${platform}.zip
$ unzip vault_${vault_version}_${platform}.zip
これらの手順は、install_vault.sh [GitHub] (英語) をダウンロードして実行することで実行できます。

Vault の SSL 証明書を作成する

次に、証明書のセットを生成する必要があります。

  • ルート CA

  • Vault 証明書 (復号化されたキー work/ca/private/localhost.decrypted.key.pem と証明書 work/ca/certs/localhost.cert.pem)

ルート証明書を Java 準拠のトラストストアにインポートしてください。

これを実現する最も簡単な方法は、OpenSSL を使用することです。

create_certificates.sh [GitHub] (英語) は、work/ca および JKS トラストストア work/keystore.jks に証明書を作成します。このクイックスタートガイドを使用して Spring Cloud Vault を実行する場合は、トラストストアの spring.cloud.vault.ssl.trust-store プロパティを file:work/keystore.jks に構成する必要があります。

Vault サーバーを起動する

次に、次の行に沿って構成ファイルを作成します。

backend "inmem" {
}

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_cert_file = "work/ca/certs/localhost.cert.pem"
  tls_key_file = "work/ca/private/localhost.decrypted.key.pem"
}

disable_mlock = true
設定ファイルの例は vault.conf [GitHub] (英語) にあります。
$ vault server -config=vault.conf

Vault は、inmem ストレージと https を使用して 0.0.0.0:8200 での listen を開始します。Vault は封印されており、起動時に初期化されません。

テストを実行する場合は、Vault を初期化しないままにしておきます。テストでは Vault を初期化し、ルートトークン 00000000-0000-0000-0000-000000000000 を作成します。

Vault をアプリケーションに使用したい場合、または試してみたい場合は、まず初期化する必要があります。

$ export VAULT_ADDR="https://localhost:8200"
$ export VAULT_SKIP_VERIFY=true # Don't do this for production
$ vault operator init

次のようなものが表示されるはずです。

Key 1: 7149c6a2e16b8833f6eb1e76df03e47f6113a3288b3093faf5033d44f0e70fe701
Key 2: 901c534c7988c18c20435a85213c683bdcf0efcd82e38e2893779f152978c18c02
Key 3: 03ff3948575b1165a20c20ee7c3e6edf04f4cdbe0e82dbff5be49c63f98bc03a03
Key 4: 216ae5cc3ddaf93ceb8e1d15bb9fc3176653f5b738f5f3d1ee00cd7dccbe926e04
Key 5: b2898fc8130929d569c1677ee69dc5f3be57d7c4b494a6062693ce0b1c4d93d805
Initial Root Token: 19aefa97-cccc-bbbb-aaaa-225940e63d76

Vault initialized with 5 keys and a key threshold of 3. Please
securely distribute the above keys. When the Vault is re-sealed,
restarted, or stopped, you must provide at least 3 of these keys
to unseal it again.

Vault does not store the master key. Without at least 3 keys,
your Vault will remain permanently sealed.

Vault は初期化して、一連の開封キーとルートトークンを返します。3 つのキーを選択し、Vault の封印を解除します。Vault トークンを VAULT_TOKEN 環境変数に保存します。

$ vault operator unseal (Key 1)
$ vault operator unseal (Key 2)
$ vault operator unseal (Key 3)
$ export VAULT_TOKEN=(Root token)
# Required to run Spring Cloud Vault tests after manual initialization
$ vault token create -id="00000000-0000-0000-0000-000000000000" -policy="root"

Spring Cloud Vault はさまざまなリソースにアクセスします。デフォルトでは、JSON エンドポイント経由でシークレット構成設定にアクセスするシークレットバックエンドが有効になっています。

HTTP サービスには次の形式のリソースがあります。

/secret/{application}/{profile}
/secret/{application}
/secret/{defaultContext}/{profile}
/secret/{defaultContext}

ここで、「アプリケーション」は SpringApplication に spring.application.name として挿入されます (つまり、通常の Spring Boot アプリでは通常「アプリケーション」となります)。「プロファイル」はアクティブなプロファイル (またはプロパティのカンマ区切りリスト) です。Vault から取得したプロパティは、プロパティ名の接頭辞を追加せずに「そのまま」使用されます。

3. クライアント側の使用箇所

これらの機能をアプリケーションで使用するには、spring-cloud-vault-config に依存する Spring Boot アプリケーションとしてビルドするだけです (たとえば、テストケースを参照)。Maven 構成の例:

例 1: pom.xml
<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>2.4.0.RELEASE</version>
    <relativePath /> <!-- lookup parent from repository -->
</parent>

<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-vault-config</artifactId>
        <version>3.1.1</version>
    </dependency>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-test</artifactId>
        <scope>test</scope>
    </dependency>
</dependencies>

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

<!-- repositories also needed for snapshots and milestones -->

次に、次の単純な HTTP サーバーのような標準の Spring Boot アプリケーションを作成できます。

@SpringBootApplication
@RestController
public class Application {

    @RequestMapping("/")
    public String home() {
        return "Hello World!";
    }

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

実行すると、ポート 8200 上のデフォルトのローカル Vault サーバーから外部構成が取得されます (実行中の場合)。起動動作を変更するには、たとえば application.properties を使用して Vault サーバーの場所を変更します。

例 2: application.yml
spring.cloud.vault:
    host: localhost
    port: 8200
    scheme: https
    uri: https://localhost:8200
    connection-timeout: 5000
    read-timeout: 15000
    config:
spring.config.import: vault://

  • host は、Vault ホストのホスト名を設定します。ホスト名は SSL 証明書の検証に使用されます

  • port は Vault ポートを設定します

  • scheme がスキームを http に設定すると、プレーン HTTP が使用されます。サポートされているスキームは http および https です。

  • uri は、URI を使用して Vault エンドポイントを構成します。ホスト / ポート / スキーム構成よりも優先されます。

  • connection-timeout は接続タイムアウトをミリ秒単位で設定します

  • read-timeout は読み取りタイムアウトをミリ秒単位で設定します

  • spring.config.import は、有効なすべてのシークレットバックエンドを使用して Vault を PropertySource としてマウントします (デフォルトで有効になっている Key-Value)

さらなる統合を有効にするには、追加の依存関係と構成が必要です。Vault の設定方法によっては、SSL (英語) や認証 (英語) などの追加の構成が必要になる場合があります。

アプリケーションが spring-boot-starter-actuator プロジェクトをインポートする場合、Vault サーバーのステータスは /health エンドポイント経由で利用可能になります。

ボールトの健全性インジケーターは、プロパティ management.health.vault.enabled (デフォルトは true) によって有効または無効にできます。

Spring Cloud Vault 3.0 および Spring Boot 2.4 では、プロパティソースのブートストラップコンテキスト初期化 (bootstrap.yml、bootstrap.properties) は非推奨になりました。代わりに、Spring Cloud Vault は、Vault から設定をインポートできる Spring Boot の Config Data API を優先します。Spring Boot Config Data アプローチでは、Vault にバインドするために spring.config.import プロパティを設定する必要があります。詳細については、「構成データの場所」セクションを参照してください。ブートストラップコンテキストを有効にするには、構成プロパティ spring.cloud.bootstrap.enabled=true を設定するか、依存関係 org.springframework.cloud:spring-cloud-starter-bootstrap を含めます。

3.1. 認証

Vault には、クライアントリクエストを承認する (英語) ための認証メカニズム (英語) が必要です。

Spring Cloud、Vault は、Vault を使用してアプリケーションを認証するための複数の認証メカニズム (英語) をサポートしています。

クイックスタートとして、Vault の初期化によって出力されたルートトークンを使用します。

例 3: application.yml
spring.cloud.vault:
    token: 19aefa97-cccc-bbbb-aaaa-225940e63d76
spring.config.import: vault://
セキュリティ要件を慎重に検討してください。Vault をすぐに使い始めたい場合は、静的トークン認証でも問題ありませんが、静的トークンはそれ以上保護されません。意図しない当事者への開示により、関連するトークンロールでの Vault の使用が許可されます。

4. ConfigData API

Spring Boot は、バージョン 2.4 以降、構成ソースの宣言とプロパティソースとしてのインポートを可能にする ConfigData API を提供します。

Spring Cloud Vault は、バージョン 3.0 以降、ConfigData API を使用して、Vault のシークレットバックエンドをプロパティソースとしてマウントします。以前のバージョンでは、ブートストラップコンテキストが使用されていました。ConfigData API は、どの構成システムをどの順序でインポートするかを指定できるため、はるかに柔軟です。

構成プロパティ spring.cloud.bootstrap.enabled=true を設定するか、依存関係 org.springframework.cloud:spring-cloud-starter-bootstrap を含めることによって、非推奨のブートストラップコンテキストを有効にすることができます。

4.1. ConfigData の場所

Vault から実現される 1 つ以上の PropertySource を介して Vault 構成をマウントできます。Spring Cloud Vault は、次の 2 つの構成場所をサポートします。

  • vault:// (デフォルトロケーション)

  • vault:///<context-path> (コンテキスト上の位置)

デフォルトの場所を使用すると、すべての有効なシークレットのバックエンドのプロパティソースがマウントされます。さらに構成を行わなくても、Spring Cloud Vault はキーと値のバックエンドを /secret/${spring.application.name} にマウントします。アクティブ化されたプロファイルごとに、/secret/${spring.application.name}/${profile} の形式に従って別のコンテキストパスが追加されます。spring-cloud-config-databases などのモジュールをクラスパスに追加すると、追加のシークレットバックエンド構成オプションが提供され、有効になっている場合はプロパティソースとしてマウントされます。

Vault から PropertySource としてマウントされるコンテキストパスを制御する場合は、コンテキストロケーション (vault:///my/context/path) を使用するか、VaultConfigurer を設定することができます。

コンテキスト上の場所が指定され、個別にマウントされます。Spring Cloud Vault は、各場所を一意の PropertySource としてマウントします。デフォルトの場所とコンテキスト上の場所 (または他の構成システム) を組み合わせて、プロパティソースの順序を制御できます。このアプローチは、デフォルトのキーと値のパス計算を無効にして、代わりに各キーと値のバックエンドを自分でマウントする場合に特に便利です。

例 4: application.yml
spring.config.import: vault://first/context/path, vault://other/path, vault://

Spring Environment 内のプロパティ名は、シャドウイングを避けるために一意である必要があります。異なるコンテキストパスで同じシークレット名を使用し、これらを個別のプロパティとして公開したい場合は、場所に prefix クエリパラメーターを追加することで区別できます。

例 5: application.yml
spring.config.import: vault://my/path?prefix=foo., vault://my/other/path?prefix=bar.
secret: ${foo.secret}
other.secret: ${bar.secret}
プレフィックスは、Vault によって返されるすべてのプロパティ名にそのまま追加されます。キー名をプレフィックスとキー名の間にドットで区切る場合は、必ずプレフィックスの末尾にドットを追加してください。

4.2. 条件付きで Vault 構成を有効 / 無効にする

場合によっては、Vault なしでアプリケーションを起動する必要がある場合があります。Vault 構成の場所をオプションにするか必須 (デフォルト) にするかを、場所文字列を使用して表現できます。

  • optional:vault:// (デフォルトロケーション)

  • optional:vault:///<context-path> (コンテキスト上の位置)

Vault サポートが spring.cloud.vault.enabled=false によって無効になっている場合、オプションの場所はアプリケーションの起動中にスキップされます。

見つからない Vault コンテキストパス (HTTP ステータス 404) は、構成の場所がオプションとしてマークされているかどうかに関係なくスキップされます。Vault クライアントのフェイルファストでは、HTTP ステータス 404 が原因で Vault コンテキストパスが見つからない場合、起動に失敗することが許可されます。

4.3. インフラストラクチャのカスタマイズ

Spring Cloud Vault には、Vault と対話するためのインフラストラクチャクラスが必要です。ConfigData API を使用しない場合 (つまり、spring.config.import=vault:// またはコンテキスト Vault パスを指定していない場合)、Spring Cloud Vault は VaultAutoConfiguration および VaultReactiveAutoConfiguration を通じて Bean を定義します。Spring Boot は、Spring コンテキストが使用可能になる前にアプリケーションをブートストラップします。VaultConfigDataLoader は Bean 自体を登録して、後でアプリケーションコンテキストに伝播します。

Bootstrapper API を使用してカスタムインスタンスを登録することで、Spring Cloud Vault で使用されるインフラストラクチャをカスタマイズできます。

InstanceSupplier<RestTemplateBuilder> builderSupplier = ctx -> RestTemplateBuilder
      .builder()
      .requestFactory(ctx.get(ClientFactoryWrapper.class).getClientHttpRequestFactory())
      .defaultHeader("X-Vault-Namespace", "my-namespace");

SpringApplication application = new SpringApplication(MyApplication.class);
application.addBootstrapper(registry -> registry.register(RestTemplateBuilder.class, builderSupplier));

カスタマイズフックについては、PropertySource として公開するシークレットバックエンドをカスタマイズするおよび VaultConfigDataLoader のソースも参照してください。

5. 認証方法

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

5.1. トークン認証

トークンは、Vault 内の認証の中核的な方法です。トークン認証では、構成を使用して静的トークンを提供する必要があります。フォールバックとして、Vault CLI がトークンをキャッシュするために使用するデフォルトの場所である ~/.vault-token からトークンを取得することもできます。

トークン認証がデフォルトの認証方法です。トークンが公開されると、意図しない当事者が Vault にアクセスし、意図したクライアントのシークレットにアクセスできるようになります。
例 6: application.yml
spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

  • authentication がこの値を TOKEN に設定すると、トークン認証方法が選択されます

  • token は、使用する静的トークンを設定します。欠落しているか空の場合は、~/.vault-token からトークンを取得しようとします。

関連事項:

5.2. Vault エージェント認証

Vault には、バージョン 0.11.0 以降、Vault Agent とともにサイドカーユーティリティが同梱されています。Vault エージェントは、自動認証機能を備えた Spring Vault の SessionManager の機能を実装します。アプリケーションは、localhost 上で実行される Vault エージェントに依存することで、キャッシュされたセッション資格情報を再利用できます。Spring Vault は、X-Vault-Token ヘッダーなしでリクエストを送信できます。Spring Vault の認証インフラストラクチャを無効にして、クライアント認証とセッション管理を無効にします。

例 7: application.yml
spring.cloud.vault:
    authentication: NONE

  • authentication がこの値を NONE に設定すると、ClientAuthentication と SessionManager が無効になります。

関連事項: Vault ドキュメント: エージェント (英語)

5.3. AppId 認証

Vault は、推測しにくい 2 つのトークンで構成される AppId (英語) 認証をサポートします。AppId のデフォルトは、静的に構成された spring.application.name です。2 番目のトークンは UserId で、アプリケーションによって決定される部分であり、通常はランタイム環境に関連します。IP アドレス、Mac アドレス、または Docker コンテナー名が良い例です。Spring Cloud Vault Config は、IP アドレス、Mac アドレス、静的 UserId (システムプロパティ経由で提供されるなど) をサポートします。IP アドレスと Mac アドレスは、16 進数でエンコードされた SHA256 ハッシュとして表されます。

IP アドレスベースの UserId は、ローカルホストの IP アドレスを使用します。

例 8: SHA256 IP アドレス UserId を使用した application.yml
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
echo の改行を含めるとハッシュ値が異なるため、必ず -n フラグを含めてください。

Mac アドレスベースの UserId は、ローカルホストにバインドされたデバイスからネットワークデバイスを取得します。この構成では、適切なデバイスを選択するための network-interface ヒントを指定することもできます。network-interface の値はオプションで、インターフェース名またはインターフェースインデックス (0 から始まる) のいずれかを指定できます。

例 9: SHA256 Mac-Address UserId を使用した application.yml
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: MAC_ADDRESS
        network-interface: eth0

  • network-interface は物理アドレスを取得するためにネットワークインターフェースを設定します

コマンドラインから IP アドレス UserId を生成するための対応するコマンドは次のとおりです。

$ echo -n 0AFEDE1234AC | sha256sum
Mac アドレスは大文字でコロンなしで指定します。echo の改行を含めるとハッシュ値が異なるため、必ず -n フラグを含めてください。

5.3.1. カスタム UserId

UserId 世代はオープンメカニズムです。spring.cloud.vault.app-id.user-id を任意の文字列に設定でき、設定された値が静的 UserId として使用されます。

より高度な方法では、spring.cloud.vault.app-id.user-id をクラス名に設定できます。このクラスはクラスパス上に存在し、org.springframework.cloud.vault.AppIdUserIdMechanism インターフェースと createUserId メソッドを実装する必要があります。Spring Cloud Vault は、AppId を使用してトークンを取得する認証を行うたびに、createUserId を呼び出して UserId を取得します。

例 10: application.yml
spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: com.examlple.MyUserIdMechanism
例 11: MyUserIdMechanism.java
public class MyUserIdMechanism implements AppIdUserIdMechanism {

  @Override
  public String createUserId() {
    String userId = ...
    return userId;
  }
}

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

5.4. AppRole 認証

AppRole (英語) は、(Vault 0.6.1 以降) 非推奨となった AppId 認証と同様、マシン認証を目的としています。AppRole 認証は、RoleId と SecretId という 2 つの推測困難 (シークレット) トークンで構成されます。

Spring Vault は、さまざまな AppRole シナリオ (プッシュ / プルモードおよびラップ) をサポートします。

RoleId およびオプションの SecretId は構成によって提供される必要があります。Spring Vault はこれらを検索したり、カスタム SecretId を作成したりしません。

例 12: AppRole 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: APPROLE
    app-role:
        role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52

必要な構成の詳細に従って、次のシナリオがサポートされています。

表 1: 構成

メソッド

RoleId

SecretId

RoleName

トークン

提供された RoleId/SecretId

提供済み

提供済み

SecretId なしの RoleId を提供

提供済み

提供 RoleId、プル SecretId

提供済み

提供済み

提供済み

提供済み

RoleId をプル (SecretId を提供)

提供済み

提供済み

提供済み

フルプルモード

提供済み

提供済み

ラップ済み

提供済み

ラップされた RoleId、提供された SecretId

提供済み

提供済み

提供された RoleId、ラップされた SecretId

提供済み

提供済み

表 2: プル / プッシュ / ラップされたマトリックス

RoleId

SecretId

サポートされています

提供済み

提供済み

✅

提供済み

プル

✅

提供済み

ラップ済み

✅

提供済み

不在

✅

プル

提供済み

✅

プル

プル

✅

プル

ラップ済み

❌

プル

不在

❌

ラップ済み

提供済み

✅

ラップ済み

プル

❌

ラップ済み

ラップ済み

✅

ラップ済み

不在

❌

コンテキスト内で設定済みの AppRoleAuthentication Bean を提供することで、プッシュ / プル / ラップモードのすべての組み合わせを使用できます。Spring Cloud Vault は、構成プロパティからすべての可能な AppRole の組み合わせを導き出すことはできません。
AppRole 認証は、リアクティブインフラストラクチャを使用する単純なプルモードに限定されます。完全なプルモードはまだサポートされていません。Spring Cloud Vault を Spring WebFlux スタックとともに使用すると、spring.cloud.vault.reactive.enabled=false を設定することで無効にできる Vault のリアクティブ自動構成が有効になります。
例 13: すべての AppRole 認証プロパティを含む application.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 を設定します。SecretId を必要とせずに AppRole が構成されている場合は、SecretId を省略できます ( bind_secret_id を参照)。

  • role: プルモードの AppRole 名を設定します。

  • app-role-path は、使用するアプリケーション認証マウントのパスを設定します。

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

5.5. AWS-EC2 認証

aws-ec2 (英語) 認証バックエンドは、AWS EC2 インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、AWS を信頼できるサードパーティとして扱い、各 EC2 インスタンスを一意に表す暗号化署名された動的メタデータ情報を使用します。

例 14: AWS-EC2 認証を使用した application.yml
spring.cloud.vault:
    authentication: AWS_EC2

AWS-EC2 認証により、nonce はデフォルトで Trust On First Use (TOFU) 原則に従うことができます。意図しない当事者が PKCS#7 ID メタデータにアクセスすると、Vault に対して認証を受ける可能性があります。

最初のログイン中に、Spring Cloud Vault はインスタンス ID とは別に認証バックエンドに保存される nonce を生成します。再認証には同じ nonce を送信する必要があります。他のパーティは nonce を持たないため、さらなる調査のために Vault でアラートを生成できます。

nonce はメモリ内に保持され、アプリケーションの再起動中に失われます。spring.cloud.vault.aws-ec2.nonce を使用して静的 nonce を構成できます。

AWS-EC2 認証ロールはオプションであり、デフォルトでは AMI になります。spring.cloud.vault.aws-ec2.role プロパティを設定することで、認証ロールを構成できます。

例 15: 構成されたロールを含む application.yml
spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server
例 16: すべての AWS EC2 認証プロパティを含む application.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 ID ドキュメントの URL を設定します

  • nonce は AWS-EC2 認証に使用されます。空のノンスはデフォルトでノンスが生成されます

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

5.6. AWS-IAM 認証

aws (英語) バックエンドは、AWS IAM ロールに安全な認証メカニズムを提供し、実行中のアプリケーションの現在の IAM ロールに基づいてボールトによる自動認証を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、AWS を信頼できるサードパーティとして扱い、呼び出し元が IAM 認証情報で署名した 4 つの情報を使用して、呼び出し元が実際にその IAM ロールを使用していることを確認します。

アプリケーションが実行されている現在の IAM ロールは自動的に計算されます。AWS ECS でアプリケーションを実行している場合、アプリケーションは実行中のコンテナーの ECS タスクに割り当てられた IAM ロールを使用します。EC2 インスタンス上でアプリケーションをネイキッドで実行している場合、使用される IAM ロールは EC2 インスタンスに割り当てられたロールになります。

AWS-IAM 認証を使用する場合は、Vault でロールを作成し、それを IAM ロールに割り当てる必要があります。空の role は、デフォルトで現在の IAM ロールのフレンドリ名になります。

例 17: 必要な AWS-IAM 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: AWS_IAM
例 18: すべての AWS-IAM 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: AWS_IAM
    aws-iam:
        role: my-dev-role
        aws-path: aws
        server-name: some.server.name
        endpoint-uri: https://sts.eu-central-1.amazonaws.com

  • role は、ログインが試行されるロールの名前を設定します。これは IAM ロールにバインドする必要があります。指定されていない場合は、現在の IAM ユーザーのフレンドリ名がボールトロールとして使用されます。

  • aws-path は、使用する AWS マウントのパスを設定します

  • server-name は、特定の型のリプレイ攻撃を防止する X-Vault-AWS-IAM-Server-ID ヘッダーに使用する値を設定します。

  • endpoint-uri は、iam_request_url パラメーターに使用される AWS STS API に使用する値を設定します。

認証実装では認証情報とリクエストの署名に AWS SDK 型が使用されるため、AWS-IAM には AWS Java SDK 依存関係 (com.amazonaws:aws-java-sdk-core) が必要です。

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

5.7. Azure MSI 認証

Azure (英語) 認証バックエンドは、Azure VM インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、Azure を信頼できるサードパーティとして扱い、マネージドサービス ID と VM インスタンスにバインドできるインスタンスメタデータ情報を使用します。

例 19: 必要な Azure 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
例 20: すべての Azure 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role
        azure-path: azure
        metadata-service: http://169.254.169.254/metadata/instance…
        identity-token-service: http://169.254.169.254/metadata/identity…

  • role は、ログインが試行されるロールの名前を設定します。

  • azure-path は、使用する Azure マウントのパスを設定します

  • metadata-service は、インスタンスメタデータサービスにアクセスするための URI を設定します

  • identity-token-service は、アイデンティティトークンサービスにアクセスするための URI を設定します

Azure MSI 認証は、インスタンスメタデータサービスから仮想マシンに関する環境の詳細 (サブスクリプション ID、リソースグループ、VM 名) を取得します。Vault サーバーのリソース ID のデフォルトは vault.hashicorp.com (英語) です。これを変更するには、それに応じて spring.cloud.vault.azure-msi.identity-token-service を設定します。

関連事項:

5.8. TLS 証明書認証

cert 認証バックエンドでは、CA によって署名された、または自己署名された SSL/TLS クライアント証明書を使用した認証が可能になります。

cert 認証を有効にするには、次のことを行う必要があります。

  1. SSL を使用します。Vault クライアント SSL 構成を参照してください

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

  3. spring.cloud.vault.authentication を CERT に設定します

例 21: application.yml
spring.cloud.vault:
    authentication: CERT
    ssl:
        key-store: classpath:keystore.jks
        key-store-password: changeit
        key-store-type: JKS
        cert-auth-path: cert

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

5.9. カビーホール認証

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

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

トークン作成のためのレスポンス 折り返しには Vault 0.6.0 以降が必要です。
例 22: トークンの作成と保存 
$ 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
例 23: application.yml
spring.cloud.vault:
    authentication: CUBBYHOLE
    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

関連事項:

5.10. 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 サービスアカウントを一意に表す暗号化署名された動的メタデータ情報を使用します。

例 24: 必要な GCP-GCE 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        role: my-dev-role
例 25: すべての GCP-GCE 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        gcp-path: gcp
        role: my-dev-role
        service-account: [email protected] (英語)

  • role は、ログインが試行されるロールの名前を設定します。

  • gcp-path は、使用する GCP マウントのパスを設定します

  • service-account を使用すると、サービスアカウント ID を特定の値に上書きできます。デフォルトは default サービスアカウントです。

関連事項:

5.11. 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 認証情報は、ランタイム環境、具体的には GOOGLE_APPLICATION_CREDENTIALS 環境変数、Google コンピューティングメタデータサービスから取得するか、JSON や base64 エンコードなどの外部から提供することができます。JSON は、projects.serviceAccounts.signJwt の呼び出しに必要なプロジェクト ID とサービスアカウント ID を含んでいるため、推奨される形式です。

例 26: 必要な GCP-IAM 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        role: my-dev-role
例 27: すべての GCP-IAM 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        credentials:
            location: classpath:credentials.json
            encoded-key: e+KApn0=
        gcp-path: gcp
        jwt-validity: 15m
        project-id: my-project-id
        role: my-dev-role
        service-account-id: [email protected] (英語)

  • role は、ログインが試行されるロールの名前を設定します。

  • JSON 形式の Google 資格情報を含む資格情報リソースへの credentials.location パス。

  • credentials.encoded-key JSON 形式の OAuth2 アカウント秘密キーの Base64 エンコードされたコンテンツ。

  • gcp-path は、使用する GCP マウントのパスを設定します

  • jwt-validity は JWT トークンの有効性を構成します。デフォルトは 15 分です。

  • project-id を使用すると、プロジェクト ID を特定の値にオーバーライドできます。デフォルトは、取得した認証情報のプロジェクト ID です。

  • service-account を使用すると、サービスアカウント ID を特定の値に上書きできます。デフォルトは、取得した資格情報のサービスアカウントです。

GCP IAM 認証では、認証実装で資格情報と JWT 署名に Google API が使用されるため、Google Cloud Java SDK 依存関係 (com.google.apis:google-api-services-iam および com.google.auth:google-auth-library-oauth2-http) が必要です。

Google 資格情報には、トークンのライフサイクルを維持する OAuth 2 トークンが必要です。すべての API は同期であるため、GcpIamAuthentication はリアクティブな使用に必要な AuthenticationSteps をサポートしません。

関連事項:

5.12. Kubernetes 認証

Kubernetes 認証メカニズム (Vault 0.8.3 以降) により、Kubernetes サービスアカウントトークンを使用して Vault で認証できるようになります。認証はロールベースであり、ロールはサービスアカウント名と名前空間にバインドされます。

pod のサービスアカウントの JWT トークンを含むファイルは、/var/run/secrets/kubernetes.io/serviceaccount/token に自動的にマウントされます。

例 28: すべての Kubernetes 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: KUBERNETES
    kubernetes:
        role: my-dev-role
        kubernetes-path: kubernetes
        service-account-token-file: /var/run/secrets/kubernetes.io/serviceaccount/token

  • role はロールを設定します。

  • kubernetes-path は、使用する Kubernetes マウントのパスを設定します。

  • service-account-token-file は、Kubernetes サービスアカウントトークンを含むファイルの場所を設定します。デフォルトは /var/run/secrets/kubernetes.io/serviceaccount/token です。

関連事項:

5.13. 重要な CloudFoundry 認証

pcf (英語) 認証バックエンドは、Pivotal の CloudFoundry インスタンス内で実行されるアプリケーションに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、ID プロビジョニングが PCF 自体によって処理されるため、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、PCF を信頼できるサードパーティとして扱い、マネージドインスタンス ID を使用します。

例 29: 必要な PCF 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
例 30: すべての PCF 認証プロパティを含む application.yml
spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role
        pcf-path: path
        instance-certificate: /etc/cf-instance-credentials/instance.crt
        instance-key: /etc/cf-instance-credentials/instance.key

  • role は、ログインが試行されるロールの名前を設定します。

  • pcf-path は、使用する PCF マウントのパスを設定します。

  • instance-certificate は、PCF インスタンス ID 証明書へのパスを設定します。デフォルトは ${CF_INSTANCE_CERT} 環境変数です。

  • instance-key は、PCF インスタンス ID キーへのパスを設定します。デフォルトは ${CF_INSTANCE_KEY} 環境変数です。

PCF 認証では、BouncyCastle (bcpkix-jdk15on) が RSA PSS 署名のクラスパス上に存在する必要があります。

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

6. ACL の要件

このセクションでは、必要な機能からポリシー宣言を導き出すことができるように、Spring Vault によってアクセスされるパスについて説明します。

機能 関連する HTTP 動詞

create

POST/PUT

read

GET

update

POST/PUT

delete

DELETE

list

LIST (GET)

See also www.vaultproject.io/guides/identity/policies (英語) .

6.1. Authentication

Login: POST auth/$authMethod/login

6.2. KeyValue マウントディスカバリ

GET sys/internal/ui/mounts/$mountPath

6.3. SecretLeaseContainer

SecretLeaseContainer は、構成されたリースエンドポイントに応じて異なるパスを使用します。

LeaseEndpoints.Legacy

  • 失効: PUT sys/revoke

  • リニューアル: PUT sys/renew

LeaseEndpoints.Leases (SysLeases)

  • 失効: PUT sys/leases/revoke

  • リニューアル: PUT sys/leases/renew

6.4. セッション管理

  • トークンの検索: GET auth/token/lookup-self

  • リニューアル: POST auth/token/renew-self

  • 取り消す: POST auth/token/revoke-self

7. シークレットのバックエンド

7.1. Key-Value バックエンド

Spring Cloud Vault は、バージョン付き (v2) とバージョンなし (v1) の両方の Key-Value シークレットバックエンドをサポートします。Key-Value バックエンドでは、任意の値を Key-Value ストアとして保存できます。1 つのコンテキストに 1 つまたは複数のキーと値のタプルを保存できます。コンテキストは階層的に編成できます。Spring Cloud Vault は、シークレットがバージョン管理を使用しているかどうかを自ら判断し、パスを適切な URL にマップします。Spring Cloud Vault では、アプリケーション名とデフォルトのコンテキスト名 (application) をアクティブなプロファイルと組み合わせて使用できます。

/secret/{application}/{profile}
/secret/{application}
/secret/{default-context}/{profile}
/secret/{default-context}

アプリケーション名はプロパティによって決まります。

  • spring.cloud.vault.kv.application-name

  • spring.cloud.vault.application-name

  • spring.application.name

プロファイルは次のプロパティによって決定されます。

  • spring.cloud.vault.kv.profiles

  • spring.profiles.active

シークレットは、コンマで区切ってアプリケーション名にパスを追加することで、キー / 値バックエンド内の他のコンテキストから取得できます。例: アプリケーション名 usefulapp,mysql1,projectx/aws の場合、次の各フォルダーが使用されます。

  • /secret/usefulapp

  • /secret/mysql1

  • /secret/projectx/aws

Spring Cloud Vault は、すべてのアクティブなプロファイルを可能なコンテキストパスのリストに追加します。アクティブなプロファイルは、プロファイル名を持つコンテキストへのアクセスをスキップしません。

プロパティは、保存されているときと同じように (つまり、追加のプレフィックスなしで) 公開されます。

Spring Cloud Vault は、マウントがバージョン管理されたキーと値のバックエンドを使用するかどうかに応じて、マウントパスと実際のコンテキストパスの間に data/ コンテキストを追加します。
spring.cloud.vault:
    kv:
        enabled: true
        backend: secret
        profile-separator: '/'
        default-context: application
        application-name: my-app
        profiles: local, cloud

  • enabled がこの値を false に設定すると、シークレットバックエンド構成の使用が無効になります。

  • backend は、使用するシークレットマウントのパスを設定します

  • default-context は、すべてのアプリケーションで使用されるコンテキスト名を設定します。

  • application-name は、キーと値のバックエンドで使用するアプリケーション名をオーバーライドします。

  • profiles は、キーと値のバックエンドで使用するアクティブなプロファイルをオーバーライドします。

  • profile-separator は、プロファイルを含むプロパティソース内のコンテキストからプロファイル名を分離します。

キーと値のシークレットバックエンドは、バージョン管理 (v2) モードと非バージョン管理 (v1) モードで動作できます。

関連事項:

7.2. Consul

Spring Cloud Vault は、HashiCorp Consul の資格情報を取得できます。Consul 統合には spring-cloud-vault-config-consul 依存関係が必要です。

例 31: pom.xml
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-vault-config-consul</artifactId>
        <version>3.1.1</version>
    </dependency>
</dependencies>

統合を有効にするには、spring.cloud.vault.consul.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.consul.role= …を指定します。

取得したトークンは spring.cloud.consul.token に保存されるため、Spring Cloud を使用すると、Consul は追加の構成を行わずに生成された資格情報を取得できます。spring.cloud.vault.consul.token-property を設定することでプロパティ名を構成できます。

spring.cloud.vault:
    consul:
        enabled: true
        role: readonly
        backend: consul
        token-property: spring.cloud.consul.token

  • enabled がこの値を true に設定すると、Consul バックエンド構成の使用が有効になります。

  • role は、Consul ロール定義のロール名を設定します。

  • backend は、使用する Consul マウントのパスを設定します

  • token-property は、Consul ACL トークンが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Consul と Vault のセットアップ (英語)

7.3. RabbitMQ

Spring Cloud Vault は RabbitMQ の資格情報を取得できます。

RabbitMQ 統合には spring-cloud-vault-config-rabbitmq 依存関係が必要です。

例 32: pom.xml
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
        <version>3.1.1</version>
    </dependency>
</dependencies>

統合を有効にするには、spring.cloud.vault.rabbitmq.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.rabbitmq.role= …を指定します。

ユーザー名とパスワードは spring.rabbitmq.username および spring.rabbitmq.password に保存されるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.rabbitmq.username-property および spring.cloud.vault.rabbitmq.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    rabbitmq:
        enabled: true
        role: readonly
        backend: rabbitmq
        username-property: spring.rabbitmq.username
        password-property: spring.rabbitmq.password

  • enabled がこの値を true に設定すると、RabbitMQ バックエンド構成の使用が有効になります。

  • role は、RabbitMQ ロール定義のロール名を設定します。

  • backend は、使用する RabbitMQ マウントのパスを設定します

  • username-property は、RabbitMQ ユーザー名が保存されるプロパティ名を設定します

  • password-property は、RabbitMQ パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Vault を使用した RabbitMQ のセットアップ (英語)

7.4. AWS

Spring Cloud Vault は AWS の認証情報を取得できます。

AWS 統合には spring-cloud-vault-config-aws 依存関係が必要です。

例 33: pom.xml
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-vault-config-aws</artifactId>
        <version>3.1.1</version>
    </dependency>
</dependencies>

統合を有効にするには、spring.cloud.vault.aws=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.aws.role= …を指定します。

サポートされている AWS 認証情報の型:

  • iam_user (デフォルト)

  • assumed_role (STS)

  • federation_token (STS)

アクセスキーと秘密キーは cloud.aws.credentials.accessKey と cloud.aws.credentials.secretKey に保存されます。Spring Cloud AWS を使用すると、それ以上の構成を行わなくても、生成された資格情報が取得されます。

spring.cloud.vault.aws.access-key-property および spring.cloud.vault.aws.secret-key-property を設定することで、プロパティ名を構成できます。

STS セキュリティトークンの場合、spring.cloud.vault.aws.session-token-key-property を設定することでプロパティ名を構成できます。セキュリティトークンは cloud.aws.credentials.sessionToken (デフォルト) に保存されます。

サンプル: iam_user

spring.cloud.vault:
    aws:
        enabled: true
        role: readonly
        backend: aws
        access-key-property: cloud.aws.credentials.accessKey
        secret-key-property: cloud.aws.credentials.secretKey

サンプル: assumed_role (STS)

spring.cloud.vault:
    aws:
        enabled: true
        role: sts-vault-role
        backend: aws
        credential-type: assumed_role
        access-key-property: cloud.aws.credentials.accessKey
        secret-key-property: cloud.aws.credentials.secretKey
        session-token-key-property: cloud.aws.credentials.sessionToken
        ttl: 3600s
        role-arn: arn:aws:iam::${AWS_ACCOUNT}:role/sts-app-role

  • enabled がこの値を true に設定すると、AWS バックエンド構成の使用が有効になります。

  • role は、AWS ロール定義のロール名を設定します

  • backend は、使用する AWS マウントのパスを設定します

  • access-key-property は、AWS アクセスキーが保存されるプロパティ名を設定します

  • secret-key-property は、AWS 秘密キーが保存されるプロパティ名を設定します

  • session-token-key-property は、AWS STS セキュリティトークンが保存されるプロパティ名を設定します。

  • credential-type は、このバックエンドに使用する aws 認証情報の型を設定します。デフォルトは iam_user

  • ttl は、assumed_role または federation_token を使用するときに STS トークンの ttl を設定します。デフォルトは、vault ロールで指定された ttl です。最小 / 最大値も、AWS が STS に対してサポートする値に制限されます。

  • role-arn は、assumed_role の使用時にボールトロールに複数のロールが構成されている場合に引き受ける IAM ロールを設定します。

関連事項: Vault ドキュメント: Vault を使用した AWS のセットアップ (英語)

8. データベースバックエンド

Vault は、構成されたロールに基づいてデータベース資格情報を動的に生成するために、いくつかのデータベースシークレットバックエンドをサポートしています。これは、データベースにアクセスする必要があるサービスが資格情報を構成する必要がなくなったことを意味します。Vault から資格情報をリクエストし、Vault のリースメカニズムを使用してキーをより簡単にロールできます。

Spring Cloud Vault は、次のバックエンドと統合します。

データベースシークレットバックエンドを使用するには、構成でバックエンドと spring-cloud-vault-config-databases 依存関係を有効にする必要があります。

Vault は、プラグインによるデータベース統合を可能にする専用の database シークレットバックエンドを備えた 0.7.1 以降提供されています。汎用データベースバックエンドを使用することで、その特定のバックエンドを使用できます。必ず適切なバックエンドパスを指定してください。spring.cloud.vault.mysql.role.backend=database。

例 34: pom.xml
<dependencies>
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-vault-config-databases</artifactId>
        <version>3.1.1</version>
    </dependency>
</dependencies>
複数の JDBC 準拠データベースを有効にすると、資格情報が生成され、デフォルトで同じプロパティキーに保存されるため、JDBC シークレットのプロパティ名を個別に構成する必要があります。

8.1. データベース

Spring Cloud Vault は、www.vaultproject.io/api/secret/databases/index.html (英語) にリストされているデータベースの資格情報を取得できます。統合を有効にするには、spring.cloud.vault.database.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.database.role= …を指定します。

データベースバックエンドは汎用のものですが、spring.cloud.vault.database は特に JDBC データベースをターゲットとしています。ユーザー名とパスワードは spring.datasource.username および spring.datasource.password プロパティから入手できるため、Spring Boot を使用すると、それ以上の構成を行わなくても、DataSource 用に生成された資格情報が取得されます。spring.cloud.vault.database.username-property および spring.cloud.vault.database.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    database:
        enabled: true
        role: readonly
        backend: database
        username-property: spring.datasource.username
        password-property: spring.datasource.password

8.2. 複数のデータベース

アプリケーションが同じ種類の 2 つ以上のデータベースに接続する可能性があるため、単一のデータベースの資格情報では不十分な場合があります。バージョン 3.0.5 以降、Spring Vault は、spring.cloud.vault.databases.* 名前空間での複数のデータベースシークレットバックエンドの構成をサポートします。

この構成では、複数のデータベースバックエンドを受け入れて、資格情報を指定されたプロパティに具体化します。username-property と password-property を適切に構成してください。

spring.cloud.vault:
    databases:
        primary:
            enabled: true
            role: readwrite
            backend: database
            username-property: spring.primary-datasource.username
            password-property: spring.primary-datasource.password
        other-database:
            enabled: true
            role: readonly
            backend: database
            username-property: spring.secondary-datasource.username
            password-property: spring.secondary-datasource.password

  • <name> データベース構成のわかりやすい名前。

  • <name>.enabled がこの値を true に設定すると、データベースバックエンド構成の使用が有効になります。

  • <name>.role は、データベースロール定義のロール名を設定します。

  • <name>.backend は、使用するデータベースマウントのパスを設定します。

  • <name>.username-property は、データベースユーザー名が保存されるプロパティ名を設定します。プロパティのシャドウイングを避けるために、必ず一意のプロパティ名を使用してください。

  • <name>.password-property は、データベースパスワードが保存されるプロパティ名を設定します。プロパティのシャドウイングを避けるために、必ず一意のプロパティ名を使用してください。

関連事項: Vault ドキュメント: データベースシークレットバックエンド (英語)

Spring Cloud Vault は、最大リース時間に達した場合の新しい資格情報の取得と、それを使用した DataSource の構成をサポートしていません。つまり、Vault のデータベースロールの max_ttl が 24h に設定されている場合、アプリケーションが開始されてから 24 時間後にデータベースで認証できなくなることを意味します。

8.3. Apache Cassandra

cassandra バックエンドは Vault 0.7.1 では非推奨になっており、database バックエンドを使用して cassandra としてマウントすることをお勧めします。

Spring Cloud Vault は Apache Cassandra の資格情報を取得できます。統合を有効にするには、spring.cloud.vault.cassandra.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.cassandra.role= …を指定します。

ユーザー名とパスワードは spring.data.cassandra.username および spring.data.cassandra.password プロパティから入手できるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.cassandra.username-property および spring.cloud.vault.cassandra.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    cassandra:
        enabled: true
        role: readonly
        backend: cassandra
        username-property: spring.data.cassandra.username
        password-property: spring.data.cassandra.password

  • enabled がこの値を true に設定すると、Cassandra バックエンド構成の使用が有効になります。

  • role は、Cassandra ロール定義のロール名を設定します。

  • backend は、使用する Cassandra マウントのパスを設定します

  • username-property は、Cassandra ユーザー名が保存されるプロパティ名を設定します

  • password-property は、Cassandra パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Apache Cassandra と Vault のセットアップ (英語)

8.4. Couchbase データベース

Spring Cloud Vault は Couchbase の資格情報を取得できます。統合を有効にするには、spring.cloud.vault.couchbase.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.couchbase.role= …を指定します。

ユーザー名とパスワードは spring.couchbase.username および spring.couchbase.password プロパティから入手できるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.couchbase.username-property および spring.cloud.vault.couchbase.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    couchbase:
        enabled: true
        role: readonly
        backend: database
        username-property: spring.couchbase.username
        password-property: spring.couchbase.password

  • enabled がこの値を true に設定すると、Couchbase バックエンド構成の使用が有効になります。

  • role は、Couchbase ロール定義のロール名を設定します。

  • backend は、使用する Couchbase マウントのパスを設定します

  • username-property は、Couchbase ユーザー名が保存されるプロパティ名を設定します

  • password-property は、Couchbase パスワードが保存されるプロパティ名を設定します

関連事項: Couchbase データベースプラグインのドキュメント [GitHub] (英語)

8.5. Elasticsearch

Spring Cloud Vault は、バージョン 3.0 以降の Elasticsearch 認証情報を取得できます。統合を有効にするには、spring.cloud.vault.elasticsearch.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.elasticsearch.role= …を指定します。

ユーザー名とパスワードは spring.elasticsearch.rest.username および spring.elasticsearch.rest.password プロパティから入手できるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.elasticsearch.username-property および spring.cloud.vault.elasticsearch.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    elasticsearch:
        enabled: true
        role: readonly
        backend: mongodb
        username-property: spring.elasticsearch.rest.username
        password-property: spring.elasticsearch.rest.password

  • enabled がこの値を true に設定すると、Elasticsearch データベースのバックエンド構成の使用が有効になります。

  • role は Elasticsearch ロール定義のロール名を設定します

  • backend は、使用する Elasticsearch マウントのパスを設定します

  • username-property は、Elasticsearch ユーザー名が保存されるプロパティ名を設定します

  • password-property は、Elasticsearch パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Vault を使用した Elasticsearch のセットアップ (英語)

8.6. MongoDB

mongodb バックエンドは Vault 0.7.1 では非推奨になっており、database バックエンドを使用して mongodb としてマウントすることをお勧めします。

Spring Cloud Vault は MongoDB の資格情報を取得できます。統合を有効にするには、spring.cloud.vault.mongodb.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.mongodb.role= …を指定します。

ユーザー名とパスワードは spring.data.mongodb.username および spring.data.mongodb.password に保存されるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.mongodb.username-property および spring.cloud.vault.mongodb.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    mongodb:
        enabled: true
        role: readonly
        backend: mongodb
        username-property: spring.data.mongodb.username
        password-property: spring.data.mongodb.password

  • enabled がこの値を true に設定すると、MongodB バックエンド構成の使用が有効になります。

  • role は、MongoDB ロール定義のロール名を設定します。

  • backend は、使用する MongoDB マウントのパスを設定します

  • username-property は、MongoDB ユーザー名が保存されるプロパティ名を設定します

  • password-property は、MongoDB パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Vault を使用した MongoDB のセットアップ (英語)

8.7. MySQL

mysql バックエンドは Vault 0.7.1 では非推奨になっており、database バックエンドを使用して mysql としてマウントすることをお勧めします。spring.cloud.vault.mysql の構成は将来のバージョンで削除される予定です。

Spring Cloud Vault は MySQL の資格情報を取得できます。統合を有効にするには、spring.cloud.vault.mysql.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.mysql.role= …を指定します。

ユーザー名とパスワードは spring.datasource.username および spring.datasource.password プロパティから入手できるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.mysql.username-property および spring.cloud.vault.mysql.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    mysql:
        enabled: true
        role: readonly
        backend: mysql
        username-property: spring.datasource.username
        password-property: spring.datasource.password

  • enabled がこの値を true に設定すると、MySQL バックエンド構成の使用が有効になります。

  • role は MySQL ロール定義のロール名を設定します

  • backend は、使用する MySQL マウントのパスを設定します

  • username-property は、MySQL ユーザー名が保存されるプロパティ名を設定します

  • password-property は、MySQL パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Vault を使用した MySQL のセットアップ (英語)

8.8. PostgreSQL

postgresql バックエンドは Vault 0.7.1 では非推奨になっており、database バックエンドを使用して postgresql としてマウントすることをお勧めします。spring.cloud.vault.postgresql の構成は将来のバージョンで削除される予定です。

Spring Cloud Vault は PostgreSQL の認証情報を取得できます。統合を有効にするには、spring.cloud.vault.postgresql.enabled=true (デフォルトは false) を設定し、ロール名に spring.cloud.vault.postgresql.role= …を指定します。

ユーザー名とパスワードは spring.datasource.username および spring.datasource.password プロパティから入手できるため、Spring Boot を使用すると、追加の構成を行わなくても、生成された資格情報が取得されます。spring.cloud.vault.postgresql.username-property および spring.cloud.vault.postgresql.password-property を設定することで、プロパティ名を構成できます。

spring.cloud.vault:
    postgresql:
        enabled: true
        role: readonly
        backend: postgresql
        username-property: spring.datasource.username
        password-property: spring.datasource.password

  • enabled がこの値を true に設定すると、PostgreSQL バックエンド構成の使用が有効になります。

  • role は、PostgreSQL ロール定義のロール名を設定します。

  • backend は、使用する PostgreSQL マウントのパスを設定します

  • username-property は、PostgreSQL ユーザー名が保存されるプロパティ名を設定します

  • password-property は、PostgreSQL パスワードが保存されるプロパティ名を設定します

関連事項: Vault ドキュメント: Vault を使用した PostgreSQL のセットアップ (英語)

9. PropertySource として公開するシークレットバックエンドをカスタマイズする

Spring Cloud Vault は、プロパティベースの構成を使用して、キー / 値および検出されたシークレットバックエンド用の PropertySource を作成します。

検出されたバックエンドは、シークレットバックエンドを PropertySource として使用するための構成状態を記述する VaultSecretBackendDescriptor Bean を提供します。SecretBackendMetadataFactory は、パス、名前、プロパティ変換構成を含む SecretBackendMetadata オブジェクトを作成するために必要です。

SecretBackendMetadata は、特定の PropertySource をサポートするために使用されます。

VaultConfigurer を登録してカスタマイズできます。VaultConfigurer を指定すると、デフォルトの Key-Value および検出されたバックエンド登録は無効になります。ただし、SecretBackendConfigurer.registerDefaultKeyValueSecretBackends() および SecretBackendConfigurer.registerDefaultDiscoveredSecretBackends() によるデフォルトの登録を有効にすることができます。

public class CustomizationBean implements VaultConfigurer {

    @Override
    public void addSecretBackends(SecretBackendConfigurer configurer) {

        configurer.add("secret/my-application");

        configurer.registerDefaultKeyValueSecretBackends(false);
        configurer.registerDefaultDiscoveredSecretBackends(true);
    }
}
SpringApplication application = new SpringApplication(MyApplication.class);
application.addBootstrapper(VaultBootstrapper.fromConfigurer(new CustomizationBean()));

10. カスタムシークレットバックエンドの実装

Spring Cloud Vault には、最も一般的なバックエンド統合のためのシークレットのバックエンドサポートが付属しています。使用するバックエンドからデータを取得する方法と、PropertyTransformer を提供してそのバックエンドによって提供されるデータを表示する方法を記述した実装を提供することで、あらゆる種類のバックエンドと統合できます。

バックエンドのカスタム実装を追加するには、次の 2 つのインターフェースの実装が必要です。

  • org.springframework.cloud.vault.config.VaultSecretBackendDescriptor

  • org.springframework.cloud.vault.config.SecretBackendMetadataFactory

VaultSecretBackendDescriptor は通常、VaultDatabaseProperties などの構成データを保持するオブジェクトです。Spring Cloud Vault では、構成からクラスを実体化するために、型に @ConfigurationProperties アノテーションが付けられている必要があります。

SecretBackendMetadataFactory は VaultSecretBackendDescriptor を受け入れて、Vault サーバー内のコンテキストパス、パラメーター化されたコンテキストパスと PropertyTransformer を解決するために必要なパス変数を保持する実際の SecretBackendMetadata オブジェクトを作成します。

VaultSecretBackendDescriptor 型と SecretBackendMetadataFactory 型の両方を、Java の ServiceLoader と同様に、Spring によって提供される拡張メカニズムである spring.factories に登録する必要があります。

11. サービスレジストリの設定

DiscoveryClient (Spring Cloud や Consul など) を使用して spring.cloud.vault.discovery.enabled=true (デフォルトは false) を設定することで Vault サーバーを見つけることができます。その結果、アプリには適切な検出構成を含む application.yml (または環境変数) が必要になります。利点は、検出サービスが固定ポイントである限り、Vault が座標を変更できることです。デフォルトのサービス ID は vault ですが、クライアントで spring.cloud.vault.discovery.serviceId を使用してこれを変更できます。

検出クライアントの実装はすべて、ある種のメタデータマップをサポートしています (たとえば、Eureka の場合は eureka.instance.metadataMap があります)。クライアントが正しく接続できるように、サービスのいくつかの追加プロパティをサービス登録メタデータで構成する必要がある場合があります。トランスポート層セキュリティの詳細を提供しないサービスレジストリは、https または http に設定される scheme メタデータエントリを提供する必要があります。スキームが設定されておらず、サービスが安全なサービスとして公開されていない場合、設定はデフォルトで spring.cloud.vault.scheme になりますが、設定されていない場合は https になります。

spring.cloud.vault.discovery:
    enabled: true
    service-id: my-vault-service

12. Vault クライアントのフェイルファスト

場合によっては、Vault サーバーに接続できない場合、サービスの起動に失敗することが望ましい場合があります。これが望ましい動作である場合は、ブートストラップ構成プロパティ spring.cloud.vault.fail-fast=true を設定すると、クライアントは例外で停止します。

spring.cloud.vault:
    fail-fast: true

13. Vault エンタープライズ名前空間のサポート

Vault Enterprise では、ネームスペースを使用して、単一の Vault サーバー上で複数の Vault を分離できます。spring.cloud.vault.namespace= …  を設定して名前空間を構成すると、Vault RestTemplate または WebClient を使用する場合、すべての送信 HTTP リクエストで名前空間ヘッダー X-Vault-Namespace が有効になります。

この機能は Vault Community エディションではサポートされておらず、Vault の動作には影響しないことに注意してください。

spring.cloud.vault:
    namespace: my-namespace

関連事項: Vault エンタープライズ: 名前空間 (英語)

14. Vault クライアント SSL 構成

SSL は、さまざまなプロパティを設定することで宣言的に構成できます。javax.net.ssl.trustStore を設定して JVM 全体の SSL 設定を構成するか、spring.cloud.vault.ssl.trust-store を設定して Spring Cloud Vault Config のみの SSL 設定を設定できます。

spring.cloud.vault:
    ssl:
        trust-store: classpath:keystore.jks
        trust-store-password: changeit
        trust-store-type: JKS
        enabled-protocols: TLSv1.2,TLSv1.3
        enabled-cipher-suites: TLS_AES_128_GCM_SHA256

  • trust-store はトラストストアのリソースを設定します。SSL で保護された Vault 通信は、指定されたトラストストアを使用して Vault SSL 証明書を検証します。

  • trust-store-password はトラストストアのパスワードを設定します

  • trust-store-type はトラストストアの型を設定します。サポートされる値は、PEM を含む、サポートされているすべての KeyStore 型です。

  • enabled-protocols は、有効な SSL/TLS プロトコルのリストを設定します (3.0.2 以降)。

  • enabled-cipher-suites は、有効な SSL/TLS 暗号スイートのリストを設定します (3.0.2 以降)。

spring.cloud.vault.ssl.* の構成は、Apache Http コンポーネントまたは OkHttp クライアントのいずれかがクラスパス上にある場合にのみ適用できることに注意してください。

15. リースのライフサイクル管理 (更新と取り消し)

すべてのシークレットを使用して、Vault はリース (期間、更新可能性などの情報を含むメタデータ) を作成します。

Vault は、データが指定された期間、つまり Time To Live (TTL) の間有効であることを約束します。リースの有効期限が切れると、Vault はデータを取り消すことができ、シークレットの利用者はそれが有効であるかどうかを確信できなくなります。

Spring Cloud Vault は、ログイントークンとシークレットの作成を超えてリースのライフサイクルを維持します。ただし、リースに関連付けられたログイントークンとシークレットは、リースが期限切れになる直前に、ターミナルの期限が切れるまで更新されるようにスケジュールされています。アプリケーションをシャットダウンすると、取得したログイントークンと更新可能なリースが無効になります。

シークレットサービスとデータベースバックエンド (MongoDB や MySQL など) は通常、更新可能なリースを生成するため、生成された資格情報はアプリケーションのシャットダウン時に無効になります。

静的トークンは更新も取り消しもされません。

リースの更新と取り消しはデフォルトで有効になっていますが、spring.cloud.vault.config.lifecycle.enabled を false に設定することで無効にできます。リースが期限切れになり、Spring Cloud Vault が Vault にアクセスできなくなったり、生成された資格情報を使用するサービスにアクセスできなくなり、アプリケーションのシャットダウン後も有効な資格情報がアクティブのままになるため、これは推奨されません。

spring.cloud.vault:
    config.lifecycle:
        enabled: true
        min-renewal: 10s
        expiry-threshold: 1m
        lease-endpoints: Legacy

  • enabled は、シークレットに関連付けられたリースを更新するかどうか、および期限切れのシークレットをローテーションするかどうかを制御します。デフォルトで有効になっています。

  • min-renewal は、リースを更新する前に少なくとも必要な期間を設定します。この設定により、更新が頻繁に行われるのを防ぎます。

  • expiry-threshold は有効期限のしきい値を設定します。リースは、有効期限が切れる前に、設定された期間が経過すると更新されます。

  • lease-endpoints は、更新および取り消し用のエンドポイントを設定します。0.8 より前の Vault バージョンのレガシー、およびそれ以降の SysLeases バージョン。

関連事項: Vault ドキュメント: リース、更新、取り消し (英語)

16. セッショントークンのライフサイクル管理 (更新、再ログイン、取り消し)

Vault セッショントークン ( LoginToken とも呼ばれる) は、TTL と最大 TTL があり、期限切れになる可能性があるという点で、リースに非常によく似ています。ログイントークンの有効期限が切れると、それを使用して Vault と対話することはできなくなります。Spring Vault には、命令型およびリアクティブ型の使用のために SessionManager API が付属しています。

Spring Cloud Vault は、デフォルトでセッショントークンのライフサイクルを維持します。セッショントークンは遅延して取得されるため、実際のログインは Vault の最初のセッションバインド使用まで延期されます。Spring Cloud Vault はセッショントークンを取得すると、有効期限が切れるまで保持します。次回セッションにバインドされたアクティビティが使用されるとき、Spring Cloud Vault は Vault に再ログインし、新しいセッショントークンを取得します。アプリケーションのシャットダウン時に、Spring Cloud Vault はトークンがまだアクティブである場合はそれを取り消し、セッションを終了します。

セッションライフサイクルはデフォルトで有効になっており、spring.cloud.vault.session.lifecycle.enabled を false に設定することで無効にできます。セッショントークンが期限切れになり、Spring Cloud Vault が Vault にアクセスできなくなる可能性があるため、無効にすることはお勧めできません。

spring.cloud.vault:
    session.lifecycle:
        enabled: true
        refresh-before-expiry: 10s
        expiry-threshold: 20s

  • enabled は、セッショントークンを更新するためにセッションライフサイクル管理を有効にするかどうかを制御します。デフォルトで有効になっています。

  • refresh-before-expiry は、セッショントークンがリフレッシュされる時点を制御します。リフレッシュ時間は、トークンの有効期限から refresh-before-expiry を減算して計算されます。デフォルトは 5 seconds です。

  • expiry-threshold は有効期限のしきい値を設定します。しきい値は、セッショントークンが有効であると見なされる最小 TTL 期間を表します。TTL が短いトークンは期限切れとみなされ、使用されなくなります。トークンの有効期限が切れないようにするために、refresh-before-expiry より大きくする必要があります。デフォルトは 7 seconds です。

関連事項: Vault ドキュメント: トークンの更新 (英語)

付録 A: 共通のアプリケーションプロパティ

さまざまなプロパティは、application.properties ファイル内、application.yml ファイル内、またはコマンドラインスイッチとして指定できます。この付録では、一般的な Spring Cloud Vault プロパティのリストと、使用する基礎となるクラスへの参照を提供します。

プロパティのコントリビュートは、クラスパス上の追加の jar ファイルから得られる可能性があるため、これを完全な一覧と見なすべきではありません。また、独自のプロパティを定義できます。
名前 デフォルト 説明

spring.cloud.vault.app-id.app-id-path

app-id

AppId 認証バックエンドのマウントパス。

spring.cloud.vault.app-id.network-interface

"MAC_ADDRESS" UserId メカニズムのネットワークインターフェースヒント。

spring.cloud.vault.app-id.user-id

MAC_ADDRESS

UserId 機構。"MAC_ADDRESS"、"IP_ADDRESS"、文字列、クラス名のいずれかを指定できます。

spring.cloud.vault.app-role.app-role-path

approle

AppRole 認証バックエンドのマウントパス。

spring.cloud.vault.app-role.role

プルモードに使用されるロールの名前（オプション）。

spring.cloud.vault.app-role.role-id

RoleId。

spring.cloud.vault.app-role.secret-id

SecretId。

spring.cloud.vault.application-name

application

AppId 認証のアプリケーション名。

spring.cloud.vault.authentication

spring.cloud.vault.aws-ec2.aws-ec2-path

aws-ec2

AWS-EC2 認証バックエンドのマウントパス。

spring.cloud.vault.aws-ec2.identity-document

169.254.169.254/latest/dynamic/instance-identity/pkcs7 (英語)

AWS-EC2 PKCS7ID ドキュメントの URL。

spring.cloud.vault.aws-ec2.nonce

AWS-EC2 認証には使用されません。空の nonce は、デフォルトで nonce 生成になります。

spring.cloud.vault.aws-ec2.role

ロールの名前、オプション。

spring.cloud.vault.aws-iam.aws-path

aws

AWS 認証バックエンドのマウントパス。

spring.cloud.vault.aws-iam.endpoint-uri

STS サーバー URI。@since 2.2

spring.cloud.vault.aws-iam.role

ロールの名前、オプション。設定されていない場合、デフォルトでフレンドリ IAM 名になります。

spring.cloud.vault.aws-iam.server-name

ログインリクエストのヘッダーに {@ codeX-Vault-AWS-IAM-Server-ID} ヘッダーを設定するために使用されるサーバーの名前。

spring.cloud.vault.aws.access-key-property

cloud.aws.credentials.accessKey

取得したアクセスキーのターゲットプロパティ。

spring.cloud.vault.aws.backend

aws

aws バックエンドパス。

spring.cloud.vault.aws.credential-type

aws クレデンシャル型

spring.cloud.vault.aws.enabled

false

AWS バックエンドの使用を有効にします。

spring.cloud.vault.aws.role

クレデンシャルのロール名。

spring.cloud.vault.aws.role-arn

ボールトロールに複数のロールが関連付けられている場合の assumed_role のロール arn。@since 3.0.2

spring.cloud.vault.aws.secret-key-property

cloud.aws.credentials.secretKey

取得した秘密鍵のターゲットプロパティ。

spring.cloud.vault.aws.session-token-key-property

cloud.aws.credentials.sessionToken

取得した秘密鍵のターゲットプロパティ。

spring.cloud.vault.aws.ttl

0

sts トークンの TTL。デフォルトでは、ボールトロールが最大に対して持つ可能性のあるものは何でもです。また、AWS が STS の最大値としてサポートしているものに限定されます。@since 3.0.2

spring.cloud.vault.azure-msi.azure-path

azure

Azure MSI 認証バックエンドのマウントパス。

spring.cloud.vault.azure-msi.identity-token-service

ID トークンサービス URI。@since 3.0

spring.cloud.vault.azure-msi.metadata-service

インスタンスメタデータサービス URI。@since 3.0

spring.cloud.vault.azure-msi.role

ロールの名前。

spring.cloud.vault.cassandra.backend

cassandra

Cassandra バックエンドパス。

spring.cloud.vault.cassandra.enabled

false

cassandra バックエンドの使用を有効にします。

spring.cloud.vault.cassandra.password-property

spring.data.cassandra.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.cassandra.role

クレデンシャルのロール名。

spring.cloud.vault.cassandra.static-role

false

静的なロールの使用を有効にします。@since 2.2

spring.cloud.vault.cassandra.username-property

spring.data.cassandra.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.config.lifecycle.enabled

true

ライフサイクル管理を有効にします。

spring.cloud.vault.config.lifecycle.expiry-threshold

有効期限のしきい値。{@link Lease} は、有効期限が切れる前に、指定された {@linkDuration} で更新されます。@since 2.2

spring.cloud.vault.config.lifecycle.lease-endpoints

更新 / 失効の呼び出しを委譲する {@linkLeaseEndpoints} を設定します。{@link LeaseEndpoints} は、更新 / 失効エンドポイントの場所に影響を与える Vault バージョン間の違いをカプセル化します。バージョン 0.8 以降の Vault の場合は {@ linkLeaseEndpoints#SysLeases}、古いバージョンの場合は {@link LeaseEndpoints#Legacy}（デフォルト）にすることができます。@since 2.2

spring.cloud.vault.config.lifecycle.min-renewal

リースを更新する前に少なくとも必要な期間。@since 2.2

spring.cloud.vault.config.order

0

{@link org.springframework.core.env.PropertySource} の優先度を設定するために使用されます。これは、Vault を他のプロパティソースのオーバーライドとして使用する場合に便利です。@see org.springframework.core.PriorityOrdered

spring.cloud.vault.connection-timeout

5000

接続タイムアウト。

spring.cloud.vault.consul.backend

consul

Consul バックエンドパス。

spring.cloud.vault.consul.enabled

false

領事のバックエンドの使用を有効にします。

spring.cloud.vault.consul.role

クレデンシャルのロール名。

spring.cloud.vault.consul.token-property

spring.cloud.consul.token

取得したトークンのターゲットプロパティ。

spring.cloud.vault.couchbase.backend

database

Couchbase バックエンドパス。

spring.cloud.vault.couchbase.enabled

false

カウチベースバックエンドの使用を有効にします。

spring.cloud.vault.couchbase.password-property

spring.couchbase.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.couchbase.role

クレデンシャルのロール名。

spring.cloud.vault.couchbase.static-role

false

静的なロールの使用を有効にします。

spring.cloud.vault.couchbase.username-property

spring.couchbase.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.database.backend

database

データベースのバックエンドパス。

spring.cloud.vault.database.enabled

false

データベースバックエンドの使用を有効にします。

spring.cloud.vault.database.password-property

spring.datasource.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.database.role

クレデンシャルのロール名。

spring.cloud.vault.database.static-role

false

静的なロールの使用を有効にします。

spring.cloud.vault.database.username-property

spring.datasource.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.databases

spring.cloud.vault.discovery.enabled

false

Vault サーバー検出が有効になっていることを示すフラグ（ボールトサーバーの URL は検出を介して検索されます）。

spring.cloud.vault.discovery.service-id

vault

Vault を見つけるためのサービス ID。

spring.cloud.vault.elasticsearch.backend

database

データベースのバックエンドパス。

spring.cloud.vault.elasticsearch.enabled

false

Elasticsearch バックエンドの使用を有効にします。

spring.cloud.vault.elasticsearch.password-property

spring.elasticsearch.rest.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.elasticsearch.role

クレデンシャルのロール名。

spring.cloud.vault.elasticsearch.static-role

false

静的なロールの使用を有効にします。

spring.cloud.vault.elasticsearch.username-property

spring.elasticsearch.rest.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.enabled

true

Vault 構成サーバーを有効にします。

spring.cloud.vault.fail-fast

false

Vault からデータを取得できない場合は、すぐに失敗します。

spring.cloud.vault.gcp-gce.gcp-path

gcp

Kubernetes 認証バックエンドのマウントパス。

spring.cloud.vault.gcp-gce.role

ログインが試行されているロールの名前。

spring.cloud.vault.gcp-gce.service-account

オプションのサービスアカウント ID。未構成のままにした場合は、デフォルトの ID を使用します。

spring.cloud.vault.gcp-iam.credentials.encoded-key

JSON 形式の OAuth2 アカウント秘密鍵の base64 エンコードされたコンテンツ。

spring.cloud.vault.gcp-iam.credentials.location

OAuth2 資格情報の秘密鍵の場所。<p> これはリソースであるため、秘密鍵は、ローカルファイルシステム、クラスパス、URL などの複数の場所に配置できます。

spring.cloud.vault.gcp-iam.gcp-path

gcp

Kubernetes 認証バックエンドのマウントパス。

spring.cloud.vault.gcp-iam.jwt-validity

15m

JWT トークンの有効性。

spring.cloud.vault.gcp-iam.project-id

GCP プロジェクト ID を上書きします。

spring.cloud.vault.gcp-iam.role

ログインが試行されているロールの名前。

spring.cloud.vault.gcp-iam.service-account-id

GCP サービスアカウント ID を上書きします。

spring.cloud.vault.host

localhost

Vault サーバーホスト。

spring.cloud.vault.kubernetes.kubernetes-path

kubernetes

Kubernetes 認証バックエンドのマウントパス。

spring.cloud.vault.kubernetes.role

ログインが試行されているロールの名前。

spring.cloud.vault.kubernetes.service-account-token-file

/var/run/secrets/kubernetes.io/serviceaccount/token

サービスアカウントトークンファイルへのパス。

spring.cloud.vault.kv.application-name

application

コンテキストに使用されるアプリケーション名。

spring.cloud.vault.kv.backend

secret

デフォルトのバックエンドの名前。

spring.cloud.vault.kv.backend-version

2

Key-Value バックエンドバージョン。現在サポートされているバージョンは次のとおりです。<ul><li> バージョン 1（バージョン管理されていない Key-Value バックエンド）。</li> <li> バージョン 2（バージョン管理された Key-Value バックエンド）。</li> </ul>

spring.cloud.vault.kv.default-context

application

デフォルトコンテキストの名前。

spring.cloud.vault.kv.enabled

true

kev-value バックエンドを有効にします。

spring.cloud.vault.kv.profile-separator

/

プロファイル - アプリケーション名とプロファイルを組み合わせるための区切り文字。

spring.cloud.vault.kv.profiles

アクティブなプロファイルのリスト。@since 3.0

spring.cloud.vault.mongodb.backend

mongodb

MongoDB バックエンドパス。

spring.cloud.vault.mongodb.enabled

false

mongodb バックエンドの使用を有効にします。

spring.cloud.vault.mongodb.password-property

spring.data.mongodb.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.mongodb.role

クレデンシャルのロール名。

spring.cloud.vault.mongodb.static-role

false

静的なロールの使用を有効にします。@since 2.2

spring.cloud.vault.mongodb.username-property

spring.data.mongodb.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.mysql.backend

mysql

mysql バックエンドパス。

spring.cloud.vault.mysql.enabled

false

mysql バックエンドの使用を有効にします。

spring.cloud.vault.mysql.password-property

spring.datasource.password

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.mysql.role

クレデンシャルのロール名。

spring.cloud.vault.mysql.username-property

spring.datasource.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.namespace

Vault 名前空間（Vault エンタープライズが必要）。

spring.cloud.vault.pcf.instance-certificate

インスタンス証明書（PEM）へのパス。デフォルトは {@codeCF_INSTANCE_CERT} 環境変数です。

spring.cloud.vault.pcf.instance-key

インスタンスキー（PEM）へのパス。デフォルトは {@codeCF_INSTANCE_KEY} 環境変数です。

spring.cloud.vault.pcf.pcf-path

pcf

Kubernetes 認証バックエンドのマウントパス。

spring.cloud.vault.pcf.role

ログインが試行されているロールの名前。

spring.cloud.vault.port

8200

Vault サーバーポート。

spring.cloud.vault.postgresql.backend

postgresql

postgresql バックエンドパス。

spring.cloud.vault.postgresql.enabled

false

postgresql バックエンドの使用を有効にします。

spring.cloud.vault.postgresql.password-property

spring.datasource.password

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.postgresql.role

クレデンシャルのロール名。

spring.cloud.vault.postgresql.username-property

spring.datasource.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.rabbitmq.backend

rabbitmq

rabbitmq バックエンドパス。

spring.cloud.vault.rabbitmq.enabled

false

rabbitmq バックエンドの使用を有効にします。

spring.cloud.vault.rabbitmq.password-property

spring.rabbitmq.password

取得したパスワードのターゲットプロパティ。

spring.cloud.vault.rabbitmq.role

クレデンシャルのロール名。

spring.cloud.vault.rabbitmq.username-property

spring.rabbitmq.username

取得したユーザー名のターゲットプロパティ。

spring.cloud.vault.reactive.enabled

true

リアクティブディスカバリが有効になっていることを示すフラグ

spring.cloud.vault.read-timeout

15000

読み取りタイムアウト。

spring.cloud.vault.scheme

https

プロトコルスキーム。"http" または "https" のいずれかです。

spring.cloud.vault.session.lifecycle.enabled

true

セッションライフサイクル管理を有効にします。

spring.cloud.vault.session.lifecycle.expiry-threshold

7s

{@linkLoginToken} の有効期限のしきい値。しきい値は、ログイントークンを有効と見なすための最小 TTL 期間を表します。TTL が短いトークンは期限切れと見なされ、使用されなくなります。トークンの有効期限を防ぐには、{@ coderefreshBeforeExpiry} より大きくする必要があります。

spring.cloud.vault.session.lifecycle.refresh-before-expiry

5s

{@linkLoginToken} を更新する前に少なくとも必要な期間。

spring.cloud.vault.ssl.cert-auth-path

cert

TLS 証明書認証バックエンドのマウントパス。

spring.cloud.vault.ssl.enabled-cipher-suites

有効な SSL/TLS 暗号スイートのリスト。@since 3.0.2

spring.cloud.vault.ssl.enabled-protocols

有効な SSL/TLS プロトコルのリスト。@since 3.0.2

spring.cloud.vault.ssl.key-store

証明書と秘密鍵を保持するトラストストア。

spring.cloud.vault.ssl.key-store-password

キーストアへのアクセスに使用されるパスワード。

spring.cloud.vault.ssl.key-store-type

キーストアの型。@since 3.0

spring.cloud.vault.ssl.trust-store

SSL 証明書を保持するトラストストア。

spring.cloud.vault.ssl.trust-store-password

トラストストアへのアクセスに使用されるパスワード。

spring.cloud.vault.ssl.trust-store-type

トラストストアの型。@since 3.0

spring.cloud.vault.token

静的ボールトトークン。{@ link#authentication} が {@codeTOKEN} の場合に必要です。

spring.cloud.vault.uri

Vault URI。スキーム、ホスト、ポートで設定できます。