© 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 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 unseal (Key 1)
$ vault unseal (Key 2)
$ vault 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 構成の例:
<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.0.4</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 サーバーの場所を変更します。
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)
アプリケーションが 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 の初期化によって出力されたルートトークンを使用します。
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
としてマウントします。デフォルトの場所とコンテキスト上の場所 (または他の構成システム) を組み合わせて、プロパティソースの順序を制御できます。このアプローチは、デフォルトのキーと値のパス計算を無効にして、代わりに各キーと値のバックエンドを自分でマウントする場合に特に便利です。
spring.config.import: vault://first/context/path, vault://other/path, vault://
Spring Environment
内のプロパティ名は、シャドウイングを避けるために一意である必要があります。異なるコンテキストパスで同じシークレット名を使用し、これらを個別のプロパティとして公開したい場合は、場所に prefix
クエリパラメーターを追加することで区別できます。
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 内の認証の中心的な方法です。トークン認証では、ブートストラップアプリケーションコンテキスト [GitHub] (英語) を使用して静的トークンを提供する必要があります。
トークン認証がデフォルトの認証方法です。トークンが公開されると、意図しない当事者が Vault にアクセスし、意図したクライアントのシークレットにアクセスできるようになります。 |
spring.cloud.vault:
authentication: TOKEN
token: 00000000-0000-0000-0000-000000000000
authentication
がこの値をTOKEN
に設定すると、トークン認証方法が選択されますtoken
は使用する静的トークンを設定します
関連事項: Vault ドキュメント: トークン (英語)
5.2. Vault エージェント認証
Vault には、バージョン 0.11.0 以降、Vault Agent とともにサイドカーユーティリティが同梱されています。Vault エージェントは、自動認証機能を備えた Spring Vault の SessionManager
の機能を実装します。アプリケーションは、localhost
上で実行される Vault エージェントに依存することで、キャッシュされたセッション資格情報を再利用できます。Spring Vault は、X-Vault-Token
ヘッダーなしでリクエストを送信できます。Spring Vault の認証インフラストラクチャを無効にして、クライアント認証とセッション管理を無効にします。
spring.cloud.vault:
authentication: NONE
authentication
がこの値をNONE
に設定すると、ClientAuthentication
とSessionManager
が無効になります。
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 アドレスを使用します。
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 から始まる) のいずれかを指定できます。
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 を取得します。
spring.cloud.vault:
authentication: APPID
app-id:
user-id: com.examlple.MyUserIdMechanism
public class MyUserIdMechanism implements AppIdUserIdMechanism {
@Override
public String createUserId() {
String userId = ...
return userId;
}
}
5.4. AppRole 認証
AppRole (英語) は、(Vault 0.6.1 以降) 非推奨となった AppId 認証と同様、マシン認証を目的としています。AppRole 認証は、RoleId と SecretId という 2 つの推測困難 (シークレット) トークンで構成されます。
Spring Vault は、さまざまな AppRole シナリオ (プッシュ / プルモードおよびラップ) をサポートします。
RoleId およびオプションの SecretId は構成によって提供される必要があります。Spring Vault はこれらを検索したり、カスタム SecretId を作成したりしません。
spring.cloud.vault:
authentication: APPROLE
app-role:
role-id: bde2076b-cccb-3cf0-d57e-bca7b1e83a52
必要な構成の詳細に従って、次のシナリオがサポートされています。
メソッド | RoleId | SecretId | RoleName | トークン |
提供された RoleId/SecretId | 提供済み | 提供済み | ||
SecretId なしの RoleId を提供 | 提供済み | |||
提供 RoleId、プル SecretId | 提供済み | 提供済み | 提供済み | 提供済み |
RoleId をプル (SecretId を提供) | 提供済み | 提供済み | 提供済み | |
フルプルモード | 提供済み | 提供済み | ||
ラップ済み | 提供済み | |||
ラップされた RoleId、提供された SecretId | 提供済み | 提供済み | ||
提供された RoleId、ラップされた SecretId | 提供済み | 提供済み |
RoleId | SecretId | サポートされています |
提供済み | 提供済み | ✅ |
提供済み | プル | ✅ |
提供済み | ラップ済み | ✅ |
提供済み | 不在 | ✅ |
プル | 提供済み | ✅ |
プル | プル | ✅ |
プル | ラップ済み | ❌ |
プル | 不在 | ❌ |
ラップ済み | 提供済み | ✅ |
ラップ済み | プル | ❌ |
ラップ済み | ラップ済み | ✅ |
ラップ済み | 不在 | ❌ |
コンテキスト内で設定済みの AppRoleAuthentication Bean を提供することで、プッシュ / プル / ラップモードのすべての組み合わせを使用できます。Spring Cloud Vault は、構成プロパティからすべての可能な AppRole の組み合わせを導き出すことはできません。 |
AppRole 認証は、リアクティブインフラストラクチャを使用する単純なプルモードに限定されます。完全なプルモードはまだサポートされていません。Spring Cloud Vault を Spring WebFlux スタックとともに使用すると、spring.cloud.vault.reactive.enabled=false を設定することで無効にできる Vault のリアクティブ自動構成が有効になります。 |
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
は、使用するアプリケーション認証マウントのパスを設定します。
5.5. AWS-EC2 認証
aws-ec2 (英語) 認証バックエンドは、AWS EC2 インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、AWS を信頼できるサードパーティとして扱い、各 EC2 インスタンスを一意に表す暗号化署名された動的メタデータ情報を使用します。
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
プロパティを設定することで、認証ロールを構成できます。
spring.cloud.vault:
authentication: AWS_EC2
aws-ec2:
role: application-server
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 認証に使用されます。空のノンスはデフォルトでノンスが生成されます
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 ロールのフレンドリ名になります。
spring.cloud.vault:
authentication: AWS_IAM
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
) が必要です。
5.7. Azure MSI 認証
Azure (英語) 認証バックエンドは、Azure VM インスタンスに安全な導入メカニズムを提供し、Vault トークンの自動取得を可能にします。ほとんどの Vault 認証バックエンドとは異なり、このバックエンドでは、セキュリティに敏感な資格情報 (トークン、ユーザー名 / パスワード、クライアント証明書など) を最初にデプロイしたり、プロビジョニングしたりする必要はありません。代わりに、Azure を信頼できるサードパーティとして扱い、マネージドサービス ID と VM インスタンスにバインドできるインスタンスメタデータ情報を使用します。
spring.cloud.vault:
authentication: AZURE_MSI
azure-msi:
role: my-dev-role
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
認証を有効にするには、次のことを行う必要があります。
SSL を使用します。Vault クライアント SSL 構成を参照してください
クライアント証明書と秘密キーを含む Java
Keystore
を構成するspring.cloud.vault.authentication
をCERT
に設定します
spring.cloud.vault:
authentication: CERT
ssl:
key-store: classpath:keystore.jks
key-store-password: changeit
key-store-type: JKS
cert-auth-path: cert
5.9. カビーホール認証
Cubbyhole 認証は、Vault プリミティブを使用して、安全な認証ワークフローを提供します。Cubbyhole 認証では、主要なログイン方法としてトークンが使用されます。一時トークンは、Vault の Cubbyhole シークレットバックエンドから 2 番目のログイン VaultToken を取得するために使用されます。ログイントークンは通常、有効期間が長く、Vault との対話に使用されます。ログイントークンは、/cubbyhole/response
に保存されているラップされたレスポンスから取得されます。
ラップされたトークンの作成
トークン作成のためのレスポンス 折り返しには 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
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 サービスアカウントを一意に表す暗号化署名された動的メタデータ情報を使用します。
spring.cloud.vault:
authentication: GCP_GCE
gcp-gce:
role: my-dev-role
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 を含んでいるため、推奨される形式です。
spring.cloud.vault:
authentication: GCP_IAM
gcp-iam:
role: my-dev-role
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
に自動的にマウントされます。
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 を使用します。
spring.cloud.vault:
authentication: PCF
pcf:
role: my-dev-role
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 署名のクラスパス上に存在する必要があります。 |
6. ACL の要件
このセクションでは、必要な機能からポリシー宣言を導き出すことができるように、Spring Vault によってアクセスされるパスについて説明します。
機能 | 関連する HTTP 動詞 |
---|---|
create |
|
read |
|
update |
|
delete |
|
list |
|
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
依存関係が必要です。
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-consul</artifactId>
<version>3.0.4</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 トークンが保存されるプロパティ名を設定します
7.3. RabbitMQ
Spring Cloud Vault は RabbitMQ の資格情報を取得できます。
RabbitMQ 統合には spring-cloud-vault-config-rabbitmq
依存関係が必要です。
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-rabbitmq</artifactId>
<version>3.0.4</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 パスワードが保存されるプロパティ名を設定します
7.4. AWS
Spring Cloud Vault は AWS の認証情報を取得できます。
AWS 統合には spring-cloud-vault-config-aws
依存関係が必要です。
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-aws</artifactId>
<version>3.0.4</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 ロールを設定します。
8. データベースバックエンド
Vault は、構成されたロールに基づいてデータベース資格情報を動的に生成するために、いくつかのデータベースシークレットバックエンドをサポートしています。これは、データベースにアクセスする必要があるサービスが資格情報を構成する必要がなくなったことを意味します。Vault から資格情報をリクエストし、Vault のリースメカニズムを使用してキーをより簡単にロールできます。
Spring Cloud Vault は、次のバックエンドと統合します。
データベースシークレットバックエンドを使用するには、構成でバックエンドと spring-cloud-vault-config-databases
依存関係を有効にする必要があります。
Vault は、プラグインによるデータベース統合を可能にする専用の database
シークレットバックエンドを備えた 0.7.1 以降提供されています。汎用データベースバックエンドを使用することで、その特定のバックエンドを使用できます。必ず適切なバックエンドパスを指定してください。spring.cloud.vault.mysql.role.backend=database
。
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-vault-config-databases</artifactId>
<version>3.0.4</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
enabled
がこの値をtrue
に設定すると、データベースバックエンド構成の使用が有効になります。role
は、データベースロール定義のロール名を設定します。backend
は、使用するデータベースマウントのパスを設定します。username-property
はデータベースユーザー名が保存されるプロパティ名を設定しますpassword-property
はデータベースパスワードが保存されるプロパティ名を設定します
Spring Cloud Vault は、最大リース時間に達した場合の新しい資格情報の取得と、それを使用した DataSource の構成をサポートしていません。つまり、Vault のデータベースロールの max_ttl が 24h に設定されている場合、アプリケーションが開始されてから 24 時間後にデータベースで認証できなくなることを意味します。 |
8.2. 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 パスワードが保存されるプロパティ名を設定します
8.3. 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 パスワードが保存されるプロパティ名を設定します
8.4. 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 パスワードが保存されるプロパティ名を設定します
8.5. 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 パスワードが保存されるプロパティ名を設定します
8.6. 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 パスワードが保存されるプロパティ名を設定します
8.7. 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 パスワードが保存されるプロパティ名を設定します
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
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 バージョン。
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
です。
付録 A: 共通のアプリケーションプロパティ
さまざまなプロパティは、application.properties
ファイル内、application.yml
ファイル内、またはコマンドラインスイッチとして指定できます。この付録では、一般的な Spring Cloud Vault プロパティのリストと、使用する基礎となるクラスへの参照を提供します。
プロパティのコントリビュートは、クラスパス上の追加の jar ファイルから得られる可能性があるため、これを完全な一覧と見なすべきではありません。また、独自のプロパティを定義できます。 |
名前 | デフォルト | 説明 |
---|---|---|
spring.cloud.vault.app-id.app-id-path |
| AppId 認証バックエンドのマウントパス。 |
spring.cloud.vault.app-id.network-interface | "MAC_ADDRESS" UserId メカニズムのネットワークインターフェースヒント。 | |
spring.cloud.vault.app-id.user-id |
| UserId 機構。"MAC_ADDRESS"、"IP_ADDRESS"、文字列、クラス名のいずれかを指定できます。 |
spring.cloud.vault.app-role.app-role-path |
| 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 |
| AppId 認証のアプリケーション名。 |
spring.cloud.vault.authentication | ||
spring.cloud.vault.aws-ec2.aws-ec2-path |
| AWS-EC2 認証バックエンドのマウントパス。 |
spring.cloud.vault.aws-ec2.identity-document | 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 認証バックエンドのマウントパス。 |
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 |
| 取得したアクセスキーのターゲットプロパティ。 |
spring.cloud.vault.aws.backend |
| aws バックエンドパス。 |
spring.cloud.vault.aws.credential-type | aws クレデンシャル型 | |
spring.cloud.vault.aws.enabled |
| 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 |
| 取得した秘密鍵のターゲットプロパティ。 |
spring.cloud.vault.aws.session-token-key-property |
| 取得した秘密鍵のターゲットプロパティ。 |
spring.cloud.vault.aws.ttl |
| sts トークンの TTL。デフォルトでは、ボールトロールが最大に対して持つ可能性のあるものは何でもです。また、AWS が STS の最大値としてサポートしているものに限定されます。@since 3.0.2 |
spring.cloud.vault.azure-msi.azure-path |
| 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 バックエンドパス。 |
spring.cloud.vault.cassandra.enabled |
| cassandra バックエンドの使用を有効にします。 |
spring.cloud.vault.cassandra.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.cassandra.role | クレデンシャルのロール名。 | |
spring.cloud.vault.cassandra.static-role |
| 静的なロールの使用を有効にします。@since 2.2 |
spring.cloud.vault.cassandra.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.config.lifecycle.enabled |
| ライフサイクル管理を有効にします。 |
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 |
| {@link org.springframework.core.env.PropertySource} の優先度を設定するために使用されます。これは、Vault を他のプロパティソースのオーバーライドとして使用する場合に便利です。@see org.springframework.core.PriorityOrdered |
spring.cloud.vault.connection-timeout |
| 接続タイムアウト。 |
spring.cloud.vault.consul.backend |
| Consul バックエンドパス。 |
spring.cloud.vault.consul.enabled |
| 領事のバックエンドの使用を有効にします。 |
spring.cloud.vault.consul.role | クレデンシャルのロール名。 | |
spring.cloud.vault.consul.token-property |
| 取得したトークンのターゲットプロパティ。 |
spring.cloud.vault.couchbase.backend |
| Couchbase バックエンドパス。 |
spring.cloud.vault.couchbase.enabled |
| カウチベースバックエンドの使用を有効にします。 |
spring.cloud.vault.couchbase.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.couchbase.role | クレデンシャルのロール名。 | |
spring.cloud.vault.couchbase.static-role |
| 静的なロールの使用を有効にします。 |
spring.cloud.vault.couchbase.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.database.backend |
| データベースのバックエンドパス。 |
spring.cloud.vault.database.enabled |
| データベースバックエンドの使用を有効にします。 |
spring.cloud.vault.database.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.database.role | クレデンシャルのロール名。 | |
spring.cloud.vault.database.static-role |
| 静的なロールの使用を有効にします。 |
spring.cloud.vault.database.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.discovery.enabled |
| Vault サーバー検出が有効になっていることを示すフラグ(ボールトサーバーの URL は検出を介して検索されます)。 |
spring.cloud.vault.discovery.service-id |
| Vault を見つけるためのサービス ID。 |
spring.cloud.vault.elasticsearch.backend |
| データベースのバックエンドパス。 |
spring.cloud.vault.elasticsearch.enabled |
| Elasticsearch バックエンドの使用を有効にします。 |
spring.cloud.vault.elasticsearch.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.elasticsearch.role | クレデンシャルのロール名。 | |
spring.cloud.vault.elasticsearch.static-role |
| 静的なロールの使用を有効にします。 |
spring.cloud.vault.elasticsearch.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.enabled |
| Vault 構成サーバーを有効にします。 |
spring.cloud.vault.fail-fast |
| Vault からデータを取得できない場合は、すぐに失敗します。 |
spring.cloud.vault.gcp-gce.gcp-path |
| 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 |
| Kubernetes 認証バックエンドのマウントパス。 |
spring.cloud.vault.gcp-iam.jwt-validity |
| 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 |
| Vault サーバーホスト。 |
spring.cloud.vault.kubernetes.kubernetes-path |
| Kubernetes 認証バックエンドのマウントパス。 |
spring.cloud.vault.kubernetes.role | ログインが試行されているロールの名前。 | |
spring.cloud.vault.kubernetes.service-account-token-file |
| サービスアカウントトークンファイルへのパス。 |
spring.cloud.vault.kv.application-name |
| コンテキストに使用されるアプリケーション名。 |
spring.cloud.vault.kv.backend |
| デフォルトのバックエンドの名前。 |
spring.cloud.vault.kv.backend-version |
| Key-Value バックエンドバージョン。現在サポートされているバージョンは次のとおりです。<ul><li> バージョン 1(バージョン管理されていない Key-Value バックエンド)。</li> <li> バージョン 2(バージョン管理された Key-Value バックエンド)。</li> </ul> |
spring.cloud.vault.kv.default-context |
| デフォルトコンテキストの名前。 |
spring.cloud.vault.kv.enabled |
| kev-value バックエンドを有効にします。 |
spring.cloud.vault.kv.profile-separator |
| プロファイル - アプリケーション名とプロファイルを組み合わせるための区切り文字。 |
spring.cloud.vault.kv.profiles | アクティブなプロファイルのリスト。@since 3.0 | |
spring.cloud.vault.mongodb.backend |
| MongoDB バックエンドパス。 |
spring.cloud.vault.mongodb.enabled |
| mongodb バックエンドの使用を有効にします。 |
spring.cloud.vault.mongodb.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.mongodb.role | クレデンシャルのロール名。 | |
spring.cloud.vault.mongodb.static-role |
| 静的なロールの使用を有効にします。@since 2.2 |
spring.cloud.vault.mongodb.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.mysql.backend |
| mysql バックエンドパス。 |
spring.cloud.vault.mysql.enabled |
| mysql バックエンドの使用を有効にします。 |
spring.cloud.vault.mysql.password-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.mysql.role | クレデンシャルのロール名。 | |
spring.cloud.vault.mysql.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
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 |
| Kubernetes 認証バックエンドのマウントパス。 |
spring.cloud.vault.pcf.role | ログインが試行されているロールの名前。 | |
spring.cloud.vault.port |
| Vault サーバーポート。 |
spring.cloud.vault.postgresql.backend |
| postgresql バックエンドパス。 |
spring.cloud.vault.postgresql.enabled |
| postgresql バックエンドの使用を有効にします。 |
spring.cloud.vault.postgresql.password-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.postgresql.role | クレデンシャルのロール名。 | |
spring.cloud.vault.postgresql.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.rabbitmq.backend |
| rabbitmq バックエンドパス。 |
spring.cloud.vault.rabbitmq.enabled |
| rabbitmq バックエンドの使用を有効にします。 |
spring.cloud.vault.rabbitmq.password-property |
| 取得したパスワードのターゲットプロパティ。 |
spring.cloud.vault.rabbitmq.role | クレデンシャルのロール名。 | |
spring.cloud.vault.rabbitmq.username-property |
| 取得したユーザー名のターゲットプロパティ。 |
spring.cloud.vault.read-timeout |
| 読み取りタイムアウト。 |
spring.cloud.vault.scheme |
| プロトコルスキーム。"http" または "https" のいずれかです。 |
spring.cloud.vault.session.lifecycle.enabled |
| セッションライフサイクル管理を有効にします。 |
spring.cloud.vault.session.lifecycle.expiry-threshold |
| {@linkLoginToken} の有効期限のしきい値。しきい値は、ログイントークンを有効と見なすための最小 TTL 期間を表します。TTL が短いトークンは期限切れと見なされ、使用されなくなります。トークンの有効期限を防ぐには、{@ coderefreshBeforeExpiry} より大きくする必要があります。 |
spring.cloud.vault.session.lifecycle.refresh-before-expiry |
| {@linkLoginToken} を更新する前に少なくとも必要な期間。 |
spring.cloud.vault.ssl.cert-auth-path |
| 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。スキーム、ホスト、ポートで設定できます。 |