Vaultの概要

投稿日: 2019-10-18 2022-10-31
タグ: Security

1. 概要

このチュートリアルでは、HashicorpのVault –最新のアプリケーションアーキテクチャで機密情報を安全に管理するために使用される一般的なツールについて説明します。

ここで取り上げる主なトピックは次のとおりです。

Vaultはどのような問題を解決しようとしますか
Vaultのアーキテクチャと主な概念
簡単なテスト環境のセットアップ
コマンドラインツールを使用したVaultとの対話

2. 機密情報の問題

Vaultを掘り下げる前に、Vaultが解決しようとしている問題、つまり機密情報の管理について理解してみましょう。

ほとんどのアプリケーションは、正しく機能するために機密データにアクセスする必要があります。たとえば、eコマースアプリケーションでは、データベースに接続するために、どこかにユーザー名/パスワードが設定されている場合があります。また、支払いゲートウェイ、ロジスティクス、その他のビジネスパートナーなど、他のサービスプロバイダーと統合するためにAPIキーが必要になる場合があります。

データベースのクレデンシャルとAPIキーは、安全な方法でアプリケーションに保存して利用できるようにする必要がある機密情報の例です。

簡単な解決策は、これらの資格情報を構成ファイルに保存し、起動時に読み取ることです。ただし、このアプローチの問題は明らかです。 このファイルにアクセスできる人は誰でも、アプリケーションが持っているのと同じデータベース権限を共有します –通常、保存されているすべてのデータへのフルアクセスを許可します。

これらのファイルを暗号化することで、物事を少し難しくすることができます。ただし、このアプローチでは、全体的なセキュリティの観点からはあまり追加されません。主に、アプリケーションがマスターキーにアクセスできる必要があるためです。暗号化をこのように使用すると、「誤った」安心感しか得られません。

最新のアプリケーションとクラウド環境では、複雑さが増す傾向があります。分散サービス、複数のデータベース、メッセージングシステムなど、すべての場所に機密情報が少し広がっているため、セキュリティ違反のリスクが高まります。

それで、私たちは何ができますか？ヴォールトしよう！

3. Vaultとは何ですか？

Hashicorp Vaultは、機密情報の管理の問題に対処します。Vaultの用語ではsecretです。 このコンテキストでの「管理」とは、Vaultが機密情報のすべての側面を制御することを意味します：その生成、保存、使用、そして最後に重要なこととして、その取り消し。

Hashicorpは2つのバージョンのVaultを提供しています。この記事で使用されているオープンソースバージョンは、商用環境でも無料で使用できます。さまざまなSLAでの技術サポートや、HSM（ハードウェアセキュリティモジュール）サポートなどの追加機能を含む有料バージョンも利用できます。

3.1. アーキテクチャと主な機能

Vaultのアーキテクチャは一見シンプルです。その主なコンポーネントは次のとおりです。

永続性バックエンド–すべての秘密のストレージ
クライアントリクエストを処理し、シークレットに対して操作を実行するAPIサーバー
多数のシークレットエンジン、サポートされているシークレットタイプのタイプごとに1つ

すべてのシークレット処理をVaultに委任することで、セキュリティの問題を軽減できます。

アプリケーションはそれらを保存する必要がなくなりました。必要に応じてVaultに問い合わせて、破棄するだけです。
短命の秘密を使用できるため、攻撃者が盗まれた秘密を使用できる「機会の窓」を制限できます

Vaultは、ストアに書き込む前に、暗号化キーを使用してすべてのデータを暗号化します。この暗号化キーは、起動時にのみ使用されるマスターキーというさらに別のキーによって暗号化されます。

Vaultの実装の重要なポイントは、サーバーにマスターキーを保存しないことです。これは、起動後にVaultでさえ保存されたデータにアクセスできないことを意味します。この時点で、Vaultインスタンスは「封印された」状態にあると言われます。

後で、マスターキーを生成し、Vaultインスタンスを開封するために必要な手順を実行します。

封印を解除すると、VaultはAPIリクエストを受け入れる準備が整います。もちろん、これらの要求には認証が必要です。これにより、Vaultがクライアントを認証し、クライアントが実行できることと実行できないことを決定する方法がわかります。

3.2. 認証

Vaultのシークレットにアクセスするには、クライアントはサポートされている方法の1つを使用して自身を認証する必要があります。最も単純な方法はトークンを使用します。トークンは、特別なHTTPヘッダーを使用してすべてのAPIリクエストで送信される文字列です。

Vaultは、最初にインストールされると、「ルートトークン」を自動的に生成します。このトークンは、Linuxシステムのrootスーパーユーザーと同等であるため、その使用は最小限に制限する必要があります。ベストプラクティスとして、このルートトークンを使用して、より少ない権限で他のトークンを作成し、それを取り消す必要があります。ただし、これは問題ではありません。後で、シール解除キーを使用して別のルートトークンを生成できるためです。

Vaultは、LDAP、JWT、TLS証明書などの他の認証メカニズムもサポートしています。これらのメカニズムはすべて、基本的なトークンメカニズムの上に構築されています。Vaultがクライアントを検証すると、他のAPIにアクセスするために使用できるトークンが提供されます。

トークンには、いくつかのプロパティが関連付けられています。主なプロパティは次のとおりです。

関連するポリシーのセット（次のセクションを参照）
有効期間
更新できるかどうか
最大使用回数

特に明記されていない限り、Vaultによって作成されたトークンは親子関係を形成します。子トークンは、親が持つ特権と最大で同じレベルを持つことができます。

逆は当てはまりません。制限付きポリシーを使用して子トークンを作成できます（通常は実行できます）。この関係に関するもう1つの重要なポイント：トークンを無効にすると、すべての子トークンとその子孫も無効になります 。

3.3. ポリシー

ポリシーは、クライアントがアクセスできるシークレットと、クライアントがそれらを使用して実行できる操作を正確に定義します。単純なポリシーがどのように見えるかを見てみましょう。

path "secret/accounting" {
    capabilities = [ "read" ]
}

ここでは、HCL（Hashicorpの構成言語）構文を使用してポリシーを定義しました。 Vaultもこの目的でJSONをサポートしていますが、読みやすいため、例ではHCLを使用します。

Vaultのポリシーは「デフォルトで拒否」されます。このサンプルポリシーに添付されたトークンは、 secret /accountingの下に保存されているシークレットにアクセスできます。作成時に、トークンを複数のポリシーに添付できます。これにより、より小さなポリシーを作成してテストし、必要に応じてそれらを適用できるため、非常に便利です。

ポリシーのもう1つの重要な側面は、遅延評価を活用することです。 これは、特定のポリシーを更新でき、すべてのトークンがすぐに影響を受けることを意味します。

これまでに説明したポリシーは、アクセス制御リストポリシーまたはACLポリシーとも呼ばれます。 Vaultは、EGPポリシーとRGPポリシーの2つの追加ポリシータイプもサポートします。これらは有料バージョンでのみ利用可能であり、Sentinelサポートで基本的なポリシー構文を拡張します。

利用可能な場合、これにより、時間帯、複数の認証要素、クライアントネットワークの発信元などの追加の属性をポリシーで考慮することができます。たとえば、特定のシークレットへのアクセスを営業時間にのみ許可するポリシーを定義できます。

ポリシー構文の詳細については、Vaultのドキュメントを参照してください。

4. シークレットタイプ

Vaultは、さまざまなユースケースに対応するさまざまなシークレットタイプをサポートしています。

キー値：単純な静的キーと値のペア
動的に生成された資格情報：クライアントからの要求に応じてVaultによって生成されます
暗号化キー：クライアントデータで暗号化機能を実行するために使用されます

各シークレットタイプは、次の属性によって定義されます。

マウントポイント、はRESTAPIプレフィックスを定義します
対応するAPIを介して公開される一連の操作
構成パラメーターのセット

特定のシークレットインスタンスには、ファイルシステムのディレクトリツリーのように、パスを介してアクセスできます。 このパスの最初のコンポーネントは、このタイプのすべてのシークレットが配置されているマウントポイントに対応します。

たとえば、文字列 secret / my-application は、my-applicationのキーと値のペアを見つけることができるパスに対応します。

4.1. キーバリューシークレット

Key-Valueシークレットは、その名前が示すように、特定のパスで使用可能な単純なペアです。たとえば、ペアを保存できます foo = bar パスの下 / secret/my-application。

後で、同じパスを使用して同じペアを取得します。複数のペアを同じパスに格納できます。

Vaultは、次の3種類のキー値シークレットをサポートしています。

バージョン管理されていないキーペア。更新により既存の値が置き換えられます
バージョン化されたキーペア、これは構成可能な数の古いバージョンを維持します
Cubbyhole 、値が特定のアクセストークンにスコープされている特殊なタイプの非バージョン化キーペア（詳細は後で説明します）。

キー値シークレットは本質的に静的であるため、それらに関連付けられた有効期限の概念はありません。この種のシークレットの主な使用例は、APIキーなどの外部システムにアクセスするための資格情報を保存することです。

このようなシナリオでは、クレデンシャルの更新は半手動のプロセスであり、通常、誰かが新しいクレデンシャルを取得し、VaultのコマンドラインまたはそのUIを使用して新しい値を入力する必要があります。

4.2. 動的に生成されたシークレット

動的シークレットは、アプリケーションから要求されたときに、Vaultによってオンザフライで生成されます。 Vaultは、次のようないくつかのタイプの動的シークレットをサポートしています。

データベースのクレデンシャル
SSHキーペア
X.509証明書
AWSクレデンシャル
GoogleCloudサービスアカウント
ActiveDirectoryアカウント

これらはすべて同じ使用パターンに従います。まず、関連するサービスに接続するために必要な詳細を使用してシークレットエンジンを構成します。次に、実際の秘密の作成を記述する1つ以上のロールを定義します。

例としてデータベースシークレットエンジンを取り上げましょう。まず、新しいユーザーを作成するための管理者権限を持つ既存のユーザーからの資格情報を含む、すべてのユーザーデータベース接続の詳細を使用してVaultを構成する必要があります。

次に、新しいユーザーの作成に使用される実際のSQLステートメントを含む1つ以上のロール（データベースロールではなくVaultロール）を作成します。これらには通常、ユーザー作成ステートメントだけでなく、スキーマオブジェクト（テーブル、ビューなど）にアクセスするために必要なすべての付与ステートメントも含まれます。

クライアントが対応するAPIにアクセスすると、Vaultは提供されたステートメントを使用してデータベースに新しい一時ユーザーを作成し、その資格情報を返します。その後、クライアントはこれらの資格情報を使用して、要求された役割の存続時間属性で定義された期間中にデータベースにアクセスできます。

クレデンシャルが有効期限に達すると、Vaultはこのユーザーに関連付けられているすべての特権を自動的に取り消します。クライアントは、これらの資格情報を更新するようにVaultに要求することもできます。更新プロセスは、特定のデータベースドライバーによってサポートされ、関連するポリシーによって許可されている場合にのみ発生します。

4.3. 暗号化キー

タイプのシークレットエンジンは、暗号化、復号化、署名などの暗号化機能を処理します。 これらの操作はすべて、Vaultによって内部で生成および保存された暗号化キーを使用します。明示的に指示されない限り、Vaultは特定の暗号化キーを公開しません。

関連するAPIを使用すると、クライアントはVaultのプレーンテキストデータを送信し、その暗号化されたバージョンを受信できます。逆も可能です。暗号化されたデータを送信して、元のテキストを取り戻すことができます。

現在、このタイプのエンジンはTransitエンジンのみです。このエンジンは、RSAやECDSAなどの一般的なキータイプをサポートし、収束暗号化もサポートします。このモードを使用すると、特定のプレーンテキスト値は常に同じ暗号文結果になります。これは一部のユーザーにとって非常に便利なプロパティです。アプリケーション。

たとえば、このモードを使用して、トランザクションログテーブルのクレジットカード番号を暗号化できます。コンバージド暗号化では、新しいトランザクションを挿入するたびに、暗号化されたクレジットカードの値が同じになるため、レポートや検索などに通常のSQLクエリを使用できます。

5. Vaultのセットアップ

このセクションでは、Vaultの機能をテストするために、ローカルテスト環境を作成します。

Vaultの展開は簡単です。オペレーティングシステムに対応するパッケージをダウンロードし、その実行可能ファイル（Windowsではvaultまたはvault.exe）を上のディレクトリに抽出するだけです。私たちのパス。 この実行可能ファイルにはサーバーが含まれており、標準クライアントでもあります。公式のDockerイメージも利用可能ですが、ここでは取り上げません。

Vaultは開発モードをサポートします。これは、いくつかのクイックテストとコマンドラインツールに慣れるには問題ありませんが、実際のユースケースには単純すぎます。再起動とAPIですべてのデータが失われますアクセスはプレーンHTTPを使用します。

代わりに、ファイルベースの永続ストレージとセットアップHTTPSを使用して、問題の原因となる可能性のある実際の構成の詳細の一部を調査できるようにします。

5.1. VaultServerの起動

Vaultは、HCLまたはJSON形式を使用する構成ファイルを使用します。次のファイルは、ファイルストレージと自己署名証明書を使用してサーバーを起動するために必要なすべての構成を定義しています。

storage "file" {
  path = "./vault-data"
}
listener "tcp" {
  address = "127.0.0.1:8200"
  tls_cert_file = "./src/test/vault-config/localhost.cert"
  tls_key_file = "./src/test/vault-config/localhost.key"
}

それでは、Vaultを実行してみましょう。コマンドシェルを開き、構成ファイルを含むディレクトリに移動して、次のコマンドを実行します。

$ vault server -config ./vault-test.hcl

Vaultが起動し、いくつかの初期化メッセージが表示されます。それらには、そのバージョン、いくつかの構成の詳細、およびAPIが使用可能なアドレスが含まれます。以上です。Vaultサーバーが稼働しています。

5.2. Vaultの初期化

Vaultサーバーは現在実行中ですが、これが最初の実行であるため、初期化する必要があります。

新しいシェルを開き、次のコマンドを実行してこれを実現しましょう。

$ export VAULT_ADDR=https://localhost:8200
$ export VAULT_CACERT=./src/test/vault-config/localhost.cert
$ vault operator init

ここでは、いくつかの環境変数を定義したので、パラメーターとして毎回Vaultに渡す必要はありません。

VAULT_ADDR ：APIサーバーがリクエストを処理するベースURI
VAULT_CACERT ：サーバーの証明書公開鍵へのパス

この例では、 VAULT_CACERT を使用して、HTTPSを使用してVaultのAPIにアクセスできるようにします。自己署名証明書を使用しているため、これが必要です。これは、通常CA署名付き証明書にアクセスできる実稼働環境では必要ありません。

上記のコマンドを発行すると、次のようなメッセージが表示されます。

Unseal Key 1: <key share 1 value>
Unseal Key 2: <key share 2 value>
Unseal Key 3: <key share 3 value>
Unseal Key 4: <key share 4 value>
Unseal Key 5: <key share 5 value>

Initial Root Token: <root token value>

... more messages omitted

最初の5行は、後でVaultのストレージを開封するために使用するマスターキー共有です。 Vaultは初期化中にマスターキー共有のみを表示し、それ以上は表示しないことに注意してください。 メモして安全に保管してください。そうしないと、サーバーの再起動時にシークレットにアクセスできなくなります。

また、後で必要になるため、ルートトークンに注意してください。封印解除キーとは異なり、ルートトークンは後で簡単に生成できるため、すべての構成タスクが完了したら安全に破棄できます。後で認証トークンを必要とするコマンドを発行するので、今のところルートトークンを環境変数に保存しましょう。

$ export VAULT_TOKEN=<root token value> (Unix/Linux)

次のコマンドを使用して、サーバーを初期化したので、サーバーのステータスを確認しましょう。

$ vault status
Key                Value
---                -----
Seal Type          shamir
Sealed             true
Total Shares       5
Threshold          3
Unseal Progress    0/3
Unseal Nonce       n/a
Version            0.10.4
HA Enabled         false

Vaultはまだ封印されていることがわかります。開封の進捗状況を追跡することもできます。「0/3」は、Vaultに3つの共有が必要であることを意味しますが、これまでのところ何も取得していません。先に進んで、私たちの株を提供しましょう。

5.3. Vaultの開封

Vaultのシールを解除して、その秘密のサービスの使用を開始できるようにします。開封プロセスを完了するには、5つの主要な共有のうち3つを提供する必要があります。

$ vault operator unseal <key share 1 value>
$ vault operator unseal <key share 2 value>
$ vault operator unseal <key share 3 value>

各コマンドを発行した後、ボールトは必要な共有数など、開封の進行状況を出力します。最後のキー共有を送信すると、次のようなメッセージが表示されます。

Key             Value
---             -----
Seal Type       shamir
Sealed          false
... other properties omitted

この場合、「Sealed」プロパティは「false」です。これは、Vaultがコマンドを受け入れる準備ができていることを意味します。

6. Vaultのテスト

このセクションでは、サポートされている2つのシークレットタイプ（キー/値とデータベース）を使用して、Vaultのセットアップをテストします。また、特定のポリシーが付加された新しいトークンを作成する方法も示します。

6.1. キー/バリューシークレットの使用

まず、秘密のKey-Valueペアを保存し、それらを読み戻しましょう。 Vaultの初期化に使用されるコマンドシェルがまだ開いていると仮定して、次のコマンドを使用して、これらのペアを secret /fakebankパスの下に保存します。

$ vault kv put secret/fakebank api_key=abc1234 api_secret=1a2b3c4d

これで、次のコマンドを使用して、いつでもこれらのペアを回復できます。

$ vault kv get secret/fakebank
======= Data =======
Key           Value
---           -----
api_key       abc1234
api_secret    1a2b3c4d

この簡単なテストは、Vaultが正常に機能していることを示しています。これで、いくつかの追加機能をテストできます。

6.2. 新しいトークンの作成

これまで、リクエストを認証するためにルートトークンを使用してきました。ルートトークンはwayが強力すぎるため、特権が少なく、存続時間が短いトークンを使用することをお勧めします。

ルートトークンと同じように使用できるが、1分後に期限切れになる新しいトークンを作成しましょう。

$ vault token create -ttl 1m
Key                  Value
---                  -----
token                <token value>
token_accessor       <token accessor value>
token_duration       1m
token_renewable      true
token_policies       ["root"]
identity_policies    []
policies             ["root"]

このトークンをテストして、以前に作成したキーと値のペアを読み取りましょう。

$ export VAULT_TOKEN=<token value>
$ vault kv get secret/fakebank
======= Data =======
Key           Value
---           -----
api_key       abc1234
api_secret    1a2b3c4d

1分待ってからこのコマンドを再発行しようとすると、エラーメッセージが表示されます。

$ vault kv get secret/fakebank
Error making API request.

URL: GET https://localhost:8200/v1/sys/internal/ui/mounts/secret/fakebank
Code: 403. Errors:

* permission denied

このメッセージは、トークンが無効になったことを示しています。これは、予想どおりです。

6.3. テストポリシー

前のセクションで作成したサンプルトークンは短命でしたが、それでも非常に強力です。次に、ポリシーを使用して、より制限されたトークンを作成しましょう。

たとえば、以前に使用した secret /fakebankパスへの読み取りアクセスのみを許可するポリシーを定義しましょう。

$ cat > sample-policy.hcl <<EOF
path "secret/fakebank" {
    capabilities = ["read"]
}
EOF
$ export VAULT_TOKEN=<root token>
$ vault policy write fakebank-ro ./sample-policy.hcl
Success! Uploaded policy: fakebank-ro

次に、次のコマンドを使用して、このポリシーを使用してトークンを作成します。

$ export VAULT_TOKEN=<root token>
$ vault token create -policy=fakebank-ro
Key                  Value
---                  -----
token                <token value>
token_accessor       <token accessor value>
token_duration       768h
token_renewable      true
token_policies       ["default" "fakebank-ro"]
identity_policies    []
policies             ["default" "fakebank-ro"]

以前と同じように、このトークンを使用してシークレット値を読み取りましょう。

$ export VAULT_TOKEN=<token value>
$ vault kv get secret/fakebank
======= Data =======
Key           Value
---           -----
api_key       abc1234
api_secret    1a2b3c4d

ここまでは順調ですね。期待通りにデータを読み取ることができます。この秘密を更新しようとするとどうなるか見てみましょう。

$ vault kv put secret/fakebank api_key=foo api_secret=bar
Error writing data to secret/fakebank: Error making API request.

URL: PUT https://127.0.0.1:8200/v1/secret/fakebank
Code: 403. Errors:

* permission denied

ポリシーでは書き込みが明示的に許可されていないため、Vaultは403 –AccessDeniedステータスコードを返します。

6.4. 動的データベースクレデンシャルの使用

この記事の最後の例として、動的な資格情報を作成するためにVaultのデータベースシークレットエンジンを使用してみましょう。ここでは、MySQLサーバーがローカルで利用可能であり、「root」権限でアクセスできると想定しています。また、単一のテーブルaccountで構成される非常に単純なスキーマを使用します。

このスキーマと特権ユーザーの作成に使用されるSQLスクリプトは、こちらから入手できます。

それでは、このデータベースを使用するようにVaultを構成しましょう。データベースシークレットエンジンはデフォルトで有効になっていないため、先に進む前にこれを修正する必要があります。

$ vault secrets enable database
Success! Enabled the database secrets engine at: database/

ここで、データベース構成リソースを作成します。

$ vault write database/config/mysql-fakebank \
  plugin_name=mysql-legacy-database-plugin \
  connection_url="{{username}}:{{password}}@tcp(127.0.0.1:3306)/fakebank" \
  allowed_roles="*" \
  username="fakebank-admin" \
  password="Sup&rSecre7!"

パスプレフィックスdatabase/ config は、すべてのデータベース構成を保存する必要がある場所です。 mysql-fakebank という名前を選択して、この構成がどのデータベースを参照しているかを簡単に把握できるようにします。構成キーについて：

plugin_name：使用するデータベースプラグインを定義します。利用可能なプラグイン名は、Vaultのドキュメントに記載されています。
connection_url ：これは、データベースに接続するときにプラグインによって使用されるテンプレートです。 {{username}}および{{password}}テンプレートのプレースホルダーに注意してください。データベースに接続すると、Vaultはそれらのプレースホルダーを実際の値に置き換えます
allowed_roles ：この構成を使用できるVaultの役割（次に説明）を定義します。この例では「*」を使用しているため、すべての役割で使用できます
ユーザー名パスワード： これは、Vaultが新しいユーザーの作成やその権限の取り消しなどのデータベース操作を実行するために使用するアカウントです。

Vaultデータベースの役割の設定

最後の構成タスクは、ユーザーの作成に必要なSQLコマンドを含むVaultデータベースの役割リソースを作成することです。セキュリティ要件に応じて、必要な数の役割を作成できます。

ここでは、fakebankスキーマのすべてのテーブルへの読み取り専用アクセスを許可するロールを作成します。

$ vault write database/roles/fakebank-accounts-ro \
    db_name=mysql-fakebank \
    creation_statements="CREATE USER '{{name}}'@'%' IDENTIFIED BY '{{password}}';GRANT SELECT ON fakebank.* TO '{{name}}'@'%';"

データベースエンジンは、パスプレフィックスデータベース/ロールをロールを格納する場所として定義します。 fakebank-accounts-ro は、後で動的クレデンシャルを作成するときに使用するロール名です。次のキーも提供しています。

db_name ：既存のデータベース構成の名前。構成リソースの作成時に使用したパスの最後の部分に対応します
creation_statements：Vaultが新しいユーザーを作成するために使用するSQLステートメントテンプレートのリスト

動的資格情報の作成

データベースの役割とそれに対応する構成の準備ができたら、次のコマンドを使用して新しい動的クレデンシャルを生成します。

$ vault read database/creds/fakebank-accounts-ro
Key                Value
---                -----
lease_id           database/creds/fakebank-accounts-ro/0c0a8bef-761a-2ef2-2fed-4ee4a4a076e4
lease_duration     1h
lease_renewable    true
password           <password>
username           <username>

database / creds プレフィックスは、使用可能な役割の資格情報を生成するために使用されます。 fakebank-accounts-ro ロールを使用したため、返されるユーザー名/パスワードはselect操作に制限されます。

これを確認するには、提供された資格情報を使用してデータベースに接続し、いくつかのSQLコマンドを実行します。

$ mysql -h 127.0.0.1 -u <username> -p fakebank
Enter password:
MySQL [fakebank]> select * from account;
... omitted for brevity
2 rows in set (0.00 sec)
MySQL [fakebank]> delete from account;
ERROR 1142 (42000): DELETE command denied to user 'v-fake-9xoSKPkj1'@'localhost' for table 'account'

最初の選択が正常に完了したことがわかりますが、削除ステートメントを実行できませんでした。最後に、1時間待って同じ資格情報を使用して接続しようとすると、データベースに接続できなくなります。 Vaultは、このユーザーからのすべての特権を自動的に取り消しました

7. 結論

この記事では、HashicorpのVaultの基本について説明しました。これには、Hashicorpが対処しようとしている問題の背景、アーキテクチャ、基本的な使用法などが含まれます。

その過程で、フォローアップ記事で使用するシンプルで機能的なテスト環境を作成しました。

次の記事では、Vaultの非常に具体的なユースケースについて説明します。SpringBootアプリケーションのコンテキストでの使用。乞うご期待！

getdocs

13036