Vaultのアーキテクチャを理解する為に、公式サイトのArchitectureを読んだ結果をまとめる。（拙い和訳に近い）
Glossary
Storage Backend
- Storage Backendは、暗号化されたデータの恒久的な保存に責務を持つ。
- バックエンドは信頼されず、耐久性を求められる。
- ストレージバックエンドは、Vault serverを開始したときに設定される。
Barrier
- Barrierは、Vaultの周りの、暗号化されたスチール＆コンクリートである。
- VaultとStorageBackendの間を流れる全てのデータは、Barrierを経由する。
- Barrierは、暗号化されたデータのみを書き出すこと保証し、そのデータは検証・復号化される。
- つまり、StorageBackendに保存されるデータは、暗号化されたデータになる。
- 銀行の金庫室のように、内部のものにアクセスする際には、Barrierを
unsealする必要がある。
Secrets Engine
- Secrets Engineは、機密情報を管理することに責務を持つ。
- いくつかのSecrets Engineは、クエリを投げるたびに、動的に機密情報を生成することをサポートする。
- ポリシーに対するきめ細かい失効と更新を実行することで、ユニークな機密情報を使用させることが出来る。
- 例えば、Webサーバからのリクエストをもとに、読み取り専用のMySQLのユーザ・パスワードを一時的に発行し、期限が来たら無効化、みたいなことができる。
Audit Device
- Audit Deviceは、audit logsの管理に責務を持つ。
- Vaultへの全てのリクエストとレスポンスは、Audit Deviceを経由する。
- これにより、「Vault」と、「様々な種類の複数の監査ログ記録サービス」を統合する、シンプルな方法が提供される。
Auth Method
- Auth Methodは、ユーザ及びアプリケーションが、Vaultに対して接続する時の認証に使われる。
- 一度認証されると、Auth Methodは（適用されるべき？）適用可能なポリシーのリストを返す
- Vaultは認証されたユーザを引き受け、次のリクエストに使用するClient Tokenを返す
- 例えば、userpassAuthMethodはユーザの認証にユーザ名とパスワードを使う
- あるういは、github auth methodはGitHubを通じてユーザ認証をおこなう
Client Token
- Valut Tokenと呼ばれるClient Tokenは、概念的にはWebSiteにおけるsession cookieと類似している。
- 一度ユーザ認証が行われると、Vaultは次のリクエストの為のClient Tokenを返す。
- Client Tokenは、Vaultによって、クライアントを検証すること及び該当するACL Policiesを適用することに使われる。
- Client Tokenは、HTTP headersを通して、クライアントに渡される。
Secret
- Secrettは、機密情報あるいは暗号化された構成要素を含む、Vaultによって返却されるあらゆるもののこと。
- Vaultによって返される全てのものが"機密情報"ではない。例えば、システム構成情報、Statusの情報、ポリシーは、“機密情報"としては捉えられないだろう。
- Secretは、常にリース期間を持つ。これは、クライアントは機密情報を永続的に使用できないことを意味する。
- Vaultはリース期間が終わると、SecretをRevokeする。
Server
- Vaultはサーバとして動作する長時間稼働するインスタンスに依存する。
- Vault serverは、クライアントによる、Secret Engine、ACL、SecretのRevokeの管理及びやり取りをする為のAPIを提供する。
- サーバベースのアーキテクチャを持つことで、クライアントとセキュリティキー・ポリシーを切り離し、監査ログの集中管理と、管理者のオペレーションの簡素化を実現する。
High-Level Overview
- Storage BackendとHTTP/S APIだけがBarrierの外側のコンポーネントで、他にコンポーネントはBarrierの内側にある
- Storage Backendは信頼されず、暗号化されたデータを堅牢に保存する為に使われる
- Vault serverの起動時に、Storage Backend及びHTTP APIは提供される（データの永続化とクライアントがVault serverとやり取りするために）
Seal / Unseal
- Vault serverが起動されると
sealedというステータスになる- Key-Valueの値を取得することができないなど、この状態では基本何も出来ない。（Barrierによってプロテクトされている）
- Vaultに対するあらゆるオペレーションを行う際には、Vaultは
unsealedというステータスである必要がある。- これは、
unseal keysを提供することによって行われる。 - Vaultが初期される時に、
encryption keyを生成する。（全てのデータを保護する為に使用される。Storage Backendで管理される） - この
encryption keyは、master keyによって更に暗号化されている。（master keyはStorage Backendでは管理されない）master keyによってencryption keyを複合するので、データにアクセスする（Vaultをunsealed状態にする）為にはmaster keyが必要になる。
- これは、
- デフォルト設定だと、Vaultは
master keyを分割している。- シャミアの秘密分散法
- 共有数と必要な閾値の最小数は、両方指定することができる。
- シャミアの秘密分散法は無効化することが出来て、unsealingに
master keyを直接使うことも可能。
- 一度Vaultが
encryption keyを受け取ったら、StorageBackend内のデータを復号化し、unseled状態になる。 - 一度
unsealed状態になると、VaultはAudit Device・Auth methods・Secrets Engineをロードする。
Storage Backend(store configulation)
Audit Device、Auth Method、Secrets Engineの設定は、Vaultにて保管される。（セキュリティ的にsensitiveなため）- 正しく許可されたユーザのみ、これらの設定を変更する事ができる。（Barrierの外側では、設定を変更できない）
- Vaultにこれらの設定を保管することにより、あらゆる変更はACLおよびaudit Logsによって保護・管理される。
Core
- Vaultが
unsealed状態になった後、リクエストはHTTP APIからCoreまで処理することが出来る。 Coreは、システム間のリクエストフローをマネージしたり、ACLを適用したり、audit logsを保証したりするのに使われる。
Auth Method
- Vaultにクライアントが接続するときは、認証が必要である。
- Hunam friendlyなユーザID/パスワードやGithubといったものだったり、アプリケーションにとってはおそらくpublic/privatekey,tokensが良いだろう。
- 認証リクエストはコアからAuthMethodへと流れる。もしリクエストが有効なら、関連付けられているACL Policyを返す。
Policy Store(ACL Policy)
- ACL Policyは、単なる名前付きのアクセスコントロールのルールである。
- 例えば、“root"policyは組み込みで全てのリソースへのアクセスを許可する。
- パスを細かく制御して、任意の数の名前付きポリシーを作成することもできる。
- Vaultはwhitelist modeでのみ動作する。これは、はっきりと認められたポリシーでない場合は、そのActionは許可されないことを意味する。
- ユーザは複数のポリシーを関連付けられているだろうから、何らかのポリシーが許可していれば、Actionは許可される。
- ポリシーはPolicy Storeにて保存及び管理される。常に
sys/にマウントされているSystem Backendを通して操作される。
Token Store(Cluent Token)
- 一度認証が行われると、Auth Methodは、適用可能なポリシーを付与した新しいClient Tokenを生成し、Token Storeで管理する。
- Client Tokenはリクエスト元のクライアントに送られ、次回以降のリクエストを生成する為に使用される。
- これは、ユーザがログインした後に、Websiteから送られるCookieに似ている。
- Client Tokenは、Auth Methodの定義によって決まる、リース期間を持っている。
- これは、Client Tokenが、Revokeを避ける為に、定期的に更新される必要があることを意味している。
Secret Engine / Expiration Manager
- 一度認証が行われると、Client Tokenを用いてリクエストを生成する。
- Client Tokenは、「クライアントが認可されたことを検証する」及び「関連のポリシーをロードする」ことに使用される。
- ポリシーはクライアントのリクエストを認可する為に使用される。
- その後、リクエストは
Secret Engineにルーティングされ、Secret Engineの種類に応じて処理される。 - もし、
Secret EngineがSecretを返したら、Coreは、それにlease IDをアタッチして、Expiration Managerに登録する lease IDは、Secretを更新/廃棄する為に使用される。- もしクライアントがリースの期限切れを許可した場合、Expirtation Managerは自動的にSecretを廃棄する。
Audit Broker / Audit Device
CoreはAudit Brokerへのリクエスト/レスポンスのロギングを処理し、Audit Brokerにリクエストを送る。Audit Brokerは、リクエストを、設定された全てのAudit Deviceに送り出す。- リクエストのフロー外では、
Coreは特定のバックグラウンドアクティビティを実行する。 - リースマネジメントは期限切れのClient TokenまたはSecretを自動的に取り消すことができるため、かなりクリティカルである。
Rollback Manager
- 加えて、Vaultは、Rollback Managerというコンポーネントが先行書き込みログ記録を使用することによって、一部のfailureをハンドルする。
- これは
Coreでは透過的に管理され、ユーザーに見えることはない。
- これは