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 DeviceAuth methodsSecrets Engineをロードする。

Storage Backend(store configulation)

  • Audit DeviceAuth MethodSecrets 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 EngineSecretを返したら、Coreは、それにlease IDをアタッチして、Expiration Managerに登録する
  • lease IDは、Secretを更新/廃棄する為に使用される。
  • もしクライアントがリースの期限切れを許可した場合、Expirtation Managerは自動的にSecretを廃棄する。

Audit Broker / Audit Device

  • CoreAudit Brokerへのリクエスト/レスポンスのロギングを処理し、Audit Brokerにリクエストを送る。
  • Audit Brokerは、リクエストを、設定された全てのAudit Deviceに送り出す。
  • リクエストのフロー外では、Coreは特定のバックグラウンドアクティビティを実行する。
  • リースマネジメントは期限切れのClient TokenまたはSecretを自動的に取り消すことができるため、かなりクリティカルである。

Rollback Manager

  • 加えて、Vaultは、Rollback Managerというコンポーネントが先行書き込みログ記録を使用することによって、一部のfailureをハンドルする。
    • これはCoreでは透過的に管理され、ユーザーに見えることはない。