訳しながら理解していくVault_Architecture

はじめに

Vaultのドキュメントって英語だし、英検3級レベルで英語力のない私にはつらい・・・
そして、一回(google翻訳を使って)訳しながら読んでまた忘れてまた(google翻訳を使って)訳すを繰り返すのをやめたい。
調べるときは全文を見ずに、必要な部分だけを見てたりするので、公式ドキュメントを訳しながら全体を理解していこうと思う。

英語読むのめんどくせーーーとなっている人の助けになればと思い公開した

今回は Architecture

注意事項

• 基本的にGoogle翻訳のまんまです。
• 一応、意味が分かるようには訳してるつもりですが、ちょいちょい意味分からない部分もあります。
  誤訳がある可能性があるので、最後はちゃんと公式ドキュメントを読みましょう
• 私の知りたい部分からやるので、訳す部分はバラバラになります。
• 公式ドキュメントに記載されていない部分(自分で調べた部分とか)はitalicで記載しています。

Architecture

Vaultは、さまざまな要素を含む複雑なシステムです。 Vaultのユーザと開発者の両方がそれがどのように機能するかのメンタルモデルを構築するのを助けるために、このページはシステムアーキテクチャを文書化します。

高度なトピックこのページはVaultの技術的な詳細をカバーしています。
Vaultを効果的に使用するためにこれらの詳細を理解する必要はありません。
ソースコードをざっと見なくても詳細を知りたい方のために、詳細がここに文書化されています。
ただし、Vaultの運営者であれば、環境内でのVaultの重要性から、アーキテクチャーについて学ぶことをお勧めします。

Glossary

アーキテクチャを説明する前に、議論されている内容を明確にするのに役立つ用語集を提供します。

• Storage Backend - ストレージバックエンドは暗号化されたデータの永続的な保存を担当します。バックエンドはVaultによって信頼されておらず、耐久性を提供することのみが期待されています。ストレージバックエンドはVaultサーバの起動時に設定されます。
• Barrier - barrierはVaultの周りの暗号化されたスチールとコンクリートです。Vaultとストレージバックエンドの間を流れるすべてのデータがバリアを通過します。バリアにより、暗号化されたデータのみが書き出され、データは途中で検証および復号化されます。銀行の金庫室のように、内部のものにアクセスするにはバリアを「開封」する必要があります。
• Secrets Engine - シークレットエンジンはシークレットの管理を担当します。"kv"シークレットエンジンのような単純なシークレットエンジンは、クエリされたときに単純に同じシークレットを返します。いくつかのシークレットエンジンはそれらがクエリされるたびに動的にシークレットを生成するためにポリシーの使用をサポートします。これにより、Vaultがきめ細かい失効とポリシーの更新を実行できるようにする固有のシークレットを使用することができます。一例として、MySQLのシークレットエンジンは"web"ポリシーで設定できます。"Web"シークレットが読み取られると、Webサーバーに対する限定された特権セットで新しいMySQLユーザー/パスワードのペアが生成されます。
• Audit Device - 監査デバイスは監査ログを管理します。Vaultへのすべての要求とVaultからの応答は、設定された監査デバイスを通過します。これにより、Vaultをさまざまな種類の複数の監査ログ記録先と統合する簡単な方法が提供されます。
• Auth Method - authメソッドは、Vaultに接続しているユーザーまたはアプリケーションを認証するために使用されます。認証されると、authメソッドは適用されるべき適用可能なポリシーのリストを返します。Vaultは認証されたユーザーを受け取り、将来の要求に使用できるクライアントトークンを返します。例として、userpass authメソッドは、ユーザーを認証するためにユーザー名とパスワードを使用します。あるいは、github authメソッドを使用すると、ユーザーはGitHub経由で認証を受けることができます。
• Client Token - クライアントトークン（別名「ボールトトークン」）は、概念的にはWebサイトのセッションクッキーに似ています。ユーザーが認証されると、Vaultは将来の要求に使用されるクライアントトークンを返します。このトークンは、クライアントの身元を確認し、適切なACLポリシーを適用するためにVaultによって使用されます。このトークンはHTTPヘッダーを介して渡されます。
• Secret - シークレットとは、機密または暗号化された内容を含む、Vaultから返されるものすべての用語(term)です。Vaultから返されたすべてがシークレットになるわけではありません。たとえば、システム構成、ステータス情報、またはポリシーはシークレットとは見なされません。シークレットには必ず関連するリースがあります。つまり、クライアントは、シークレットのコンテンツを無期限に使用できるとは想定できません。Vaultは、リースの終了時にシークレットを取り消します。リースが終了する前に、オペレーターがそのシークレットを取り消すために介入することがあります。Vaultとそのクライアント間のこの契約は、手動の介入なしにキーとポリシーの変更を可能にするため、重要です。
• Server - Vaultは、サーバーとして動作する長時間のインスタンスに依存しています。Vaultサーバは、クライアントがすべてのシークレットエンジン、ACLの適用、およびシークレットリースの失効の間のやり取りをやり取りして管理するためのAPIを提供します。サーバーベースのアーキテクチャを採用することで、セキュリティキーとポリシーからクライアントを切り離し、集中監査ログを有効にし、オペレータの管理を簡素化します。

High-Level Overview

Vaultの非常に高いレベルの概要は次のようになります。

この絵を分解し始めましょう。セキュリティバリアの内側または外側にあるコンポーネントは明確に分離されています。ストレージバックエンドとHTTP APIだけが外側にあり、他のすべてのコンポーネントはバリアの内側にあります。

ストレージバックエンドは信頼できず、暗号化されたデータを永続的に保存するために使用されます。Vaultサーバを起動したら、再起動後もデータを利用できるようにストレージバックエンドを提供する必要があります。HTTP APIも同様に、クライアントと対話できるように、起動時にVaultサーバによって起動される必要があります。

起動すると、Vaultはsealed(封印)された状態になります。Vaultで操作を実行する前に、unsealed(開封)する必要があります。これはunseal keysを提供することによって行われます。Vaultを初期化すると、すべてのデータを保護するために使用される暗号化キーが生成されます。その鍵はマスター鍵によって保護されています。デフォルトでは、VaultはShamirの秘密共有アルゴリズムとして知られる技術を使用してマスターキーを5つの共有に分割します。そのうち3つはマスターキーを再構築するために必要です。

共有数と必要な最小しきい値の両方を指定できます。Shamirの技術は無効にすることができ、マスターキーはunsealに直接使用されます。Vaultが暗号化キーを取得すると、ストレージバックエンドのデータを復号化して封印を解かれた(unsealed)状態になります。開封されると、Vaultは設定されたすべての監査デバイス、認証方法、および秘密エンジンをロードします。

これらの監査デバイス、認証方法、およびシークレットエンジンの設定は、セキュリティ上重要なので、Vaultに保存する必要があります。正しい権限を持つユーザーのみがそれらを変更できます。つまり、バリアの外側では指定できません。それらをVaultに保存することで、それらに対する変更はACLシステムによって保護され、監査ログによって追跡されます。

Vaultが開封された後、HTTP APIからCoreへのリクエストを処理できます。このコアは、システム内の要求の流れを管理し、ACLを適用し、監査ログを確実に記録するために使用されます。

クライアントが最初にVaultに接続するときには、認証が必要です。Vaultは設定可能な認証方法を提供し、使用される認証メカニズムに柔軟性を提供します。ユーザ名/パスワードやGitHubなどの人に優しいメカニズムがオペレータに使用されることがありますが、アプリケーションは認証に公開/秘密鍵またはトークンを使用することがあります。認証要求は、コアを通ってauthメソッドに流れます。認証メソッドは、要求が有効かどうかを判断し、関連付けられているポリシーのリストを返します。

ポリシーは単なる名前付きACLルールです。たとえば、"root"ポリシーは組み込み(built-in)であり、すべてのリソースへのアクセスを許可します。パスをきめ細かく制御して、名前付きポリシーをいくつでも作成できます。Vaultは、ホワイトリストモードで排他的に動作します。つまり、ポリシーを介してアクセスが明示的に許可されていない限り、アクションは許可されません。ユーザには複数のポリシーが関連付けられている可能性があるため、いずれかのポリシーで許可されていればアクションが許可されます。ポリシーは内部ポリシーストアによって格納および管理されます。この内部ストアは常にsys/にマウントされているシステムバックエンドを通して操作されます。

認証が行われ、認証方法によって一連の適用可能なポリシーが提供されると、新しいクライアントトークンが生成され、トークンストアによって管理されます。このクライアントトークンはクライアントに送り返され、将来の要求を出すために使用されます。これは、ユーザーがログインした後にWebサイトによって送信されるCookieに似ています。認証方式の設定によっては、クライアントトークンにリースが関連付けられている場合があります。つまり、無効化を回避するためにクライアントトークンを定期的に更新する必要があります。

認証されると、クライアントトークンを提供して要求が行われます。トークンは、クライアントが承認されていることを確認し、関連するポリシーをロードするために使用されます。ポリシーは、クライアント要求を承認するために使用されます。その後、要求はシークレットエンジンにルーティングされ、シークレットエンジンはその種類に応じて処理されます。シークレットエンジンがシークレットを返すと、コアはそれを期限切れマネージャに登録し、リースIDを添付します。リースIDは、クライアントが自分の秘密を更新または取り消すために使用されます。クライアントがリースの期限切れを許可すると、期限切れマネージャは自動的にその秘密を取り消します。

コアは監査ブローカーへの要求と応答のロギングを処理します。監査ブローカーは設定されたすべての監査デバイスに要求を送り出します。リクエストフロー以外では、コアは特定のバックグラウンドアクティビティを実行します。リース管理は、期限切れのクライアントトークンまたは秘密を自動的に取り消すことができるため、重要です。さらに、Vaultは、ロールバックマネージャで先行書き込みログ記録を使用することによって、特定の部分的な障害ケースを処理します。これはコア内で透過的に管理され、ユーザーには見えません。

Getting in Depth

これは、Vaultのアーキテクチャの概要の概要です。サブシステムごとに詳細があります。
その他の詳細については、コードを調べるか、IRCに問い合わせるか、メーリングリストに連絡してください。