認証方法

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

トークン認証

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

トークン認証がデフォルトの認証方法です。トークンが公開されると、意図しない当事者が Vault にアクセスし、意図したクライアントの秘密にアクセスできるようになります。

application.yml

spring.cloud.vault:
    authentication: TOKEN
    token: 00000000-0000-0000-0000-000000000000

authentication がこの値を TOKEN に設定すると、トークン認証方法が選択されます
token は、使用する静的トークンを設定します。欠落しているか空の場合は、~/.vault-token からトークンを取得しようとします。

関連事項:

Vault エージェント認証

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

application.yml

spring.cloud.vault:
    authentication: NONE

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

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

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 アドレスを使用します。

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 から始まる) のいずれかを指定できます。

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 フラグを含めてください。

カスタム 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 を取得します。

application.yml

spring.cloud.vault:
    authentication: APPID
    app-id:
        user-id: com.examlple.MyUserIdMechanism

MyUserIdMechanism.java

public class MyUserIdMechanism implements AppIdUserIdMechanism {

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

AppRole 認証

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

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

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

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 のリアクティブ自動構成が有効になります。

すべての 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 は、使用するアプリケーション認証マウントのパスを設定します。

AWS-EC2 認証

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

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 プロパティを設定することで、認証ロールを構成できます。

構成されたロールを含む application.yml

spring.cloud.vault:
    authentication: AWS_EC2
    aws-ec2:
        role: application-server

すべての 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 認証に使用されます。空のノンスはデフォルトでノンスが生成されます

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 ロールのフレンドリ名になります。

必要な AWS-IAM 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: AWS_IAM

すべての AWS-IAM 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: AWS_IAM
    aws-iam:
        region: aws-global
        role: my-dev-role
        aws-path: aws
        server-name: some.server.name
        endpoint-uri: https://sts.eu-central-1.amazonaws.com

region は AWS リージョンの名前を設定します。指定しない場合、リージョンは AWS のデフォルトによって決定されます。
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 v2 依存関係 (software.amazon.awssdk:auth) が必要です。

Azure MSI 認証

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

必要な Azure 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: AZURE_MSI
    azure-msi:
        role: my-dev-role

すべての 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 を設定します。

関連事項:

TLS 証明書認証

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

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

SSL を使用します。Vault クライアント SSL 構成を参照してください
クライアント証明書と秘密鍵を含む Java Keystore を構成する
spring.cloud.vault.authentication を CERT に設定します

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

カビーホール認証

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

application.yml

spring.cloud.vault:
    authentication: CUBBYHOLE
    token: 397ccb93-ff6c-b17b-9389-380b01ca2645

関連事項:

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

必要な GCP-GCE 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: GCP_GCE
    gcp-gce:
        role: my-dev-role

すべての 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 サービスアカウントです。

関連事項:

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 を含んでいるため、推奨される形式です。

必要な GCP-IAM 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: GCP_IAM
    gcp-iam:
        role: my-dev-role

すべての 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 をサポートしません。

関連事項:

Kubernetes 認証

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

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

すべての 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 です。

関連事項:

重要な CloudFoundry 認証

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

必要な PCF 認証プロパティを含む application.yml

spring.cloud.vault:
    authentication: PCF
    pcf:
        role: my-dev-role

すべての 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 署名のクラスパス上に存在する必要があります。

ACL の要件

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

機能関連する HTTP 動詞

機能	関連する HTTP 動詞
create	`POST`/`PUT`
read	`GET`
update	`POST`/`PUT`
delete	`DELETE`
list	`LIST` (`GET`)

create

POST/PUT

read

GET

update

POST/PUT

delete

DELETE

list

LIST (GET)

Authentication

KeyValue マウントディスカバリ

GET sys/internal/ui/mounts/$mountPath

SecretLeaseContainer

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

LeaseEndpoints.Legacy

失効: PUT sys/revoke
リニューアル: PUT sys/renew

LeaseEndpoints.Leases (SysLeases)

失効: PUT sys/leases/revoke
リニューアル: PUT sys/leases/renew

セッション管理

トークンの検索: GET auth/token/lookup-self
リニューアル: POST auth/token/renew-self
取り消す: POST auth/token/revoke-self