🐱

HashiCorp Vaultを何となく理解する(1):アーキテクチャ

2024/04/04に公開

イオン⁠⁠⁠⁠⁠⁠⁠スマートテクノロジーのCTO室SREチームの@hikkie13です。

過去の記事に記載がある通り、弊社ではHCP Vaultの導入を進めています。
https://zenn.dev/aeonpeople/articles/6625a900552311
https://zenn.dev/aeonpeople/articles/0b4492898a0fd3

導入には教育・学習が欠かせません。
その過程で得た知識を何回かに分けてまとめていこうと思います。(心が折れない限り)

今回は、Vaultのアーキテクチャや概要についてです。

HashiCorp Vaultとは

https://www.vaultproject.io/
クラウド運用モデルに適した、シークレットやアプリケーションデータを安全に保つクラウドセキュリティ基盤ツール。
主に以下の機能を有する。

  • シークレットの一元管理
  • データ暗号化

Vault Architecture

https://developer.hashicorp.com/vault/docs/internals/architecture


https://developer.hashicorp.com/vault/docs/internals/architecture より引用

  • ユーザ、マシンはAPIを経由してVaultとやり取りをする。
  • Storage Backendには暗号化したデータを保存する。

Vault Components

Vaultにおいて、以下の主要な4つのcomponentが存在する。

  • Storage Backends
  • Secrets Engines
  • Auth Methods
  • Audit Devices

Storage Backends

https://developer.hashicorp.com/vault/docs/configuration/storage

  • Vaultの情報を永続的に保存するストレージの設定
  • configuration fileの storage ブロックで定義する。
  • 全てのデータは転送中および受信時に暗号化される
  • Vault Clusterにつき1つのみStorage Backendが設定できる。

Secrets Engines

https://developer.hashicorp.com/vault/docs/secrets

  • 組織の機密情報を管理するコンポーネントである。
  • Secrets Enginesはデータを保存、生成、暗号化する。
  • 多くのSecrets Enginesは他のサービスと接続し、動的にクレデンシャルを生成する。
  • kvのように静的なクレデンシャルも管理可能。

Auth Methods

https://developer.hashicorp.com/vault/docs/auth

  • 認証の実行とIDの管理を行う。
  • IDやポリシーの割り当てを担当する。
  • ユースケースに応じて複数の認証方法を有効にできる。
  • 大きく分けて人間による方法とシステムによる方法で区別する。
  • 一度認証されると、vaultはクライアントトークンを発行し、それ以降のvaultへのリクエスト(読み取り/書き込み)に使用する。
  • つまり、認証メソッドの基本的な目的は、トークンの取得となる。
    • 各トークンは関連するポリシーとTTLを持つ。

Audit Devices

https://developer.hashicorp.com/vault/docs/audit

  • Vaultへのすべてのrequestとresponseの詳細なログを保管する。
  • 監査ログはJSONでフォーマットされる。
  • 機密情報はログに記録する前にハッシュ化される。
  • 複数の認証デバイスを使用可能
    • Vaultのリクエストを完了する前に、少なくとも1つの監査デバイスがログを書き込む必要があることに留意する。

Pathについて

  • Vaultの全てはPATHベースである。(https://developer.hashicorp.com/vault/docs/concepts/policies)

  • PATHのprefixにより、リクエストがどのコンポーネントにルーティングされるかを決める。(Architectureのpath-routingの部分)

  • Secret Engines,Auth Methods,Audit Devicesも、実体は指定されたパスにマウントされる

  • パスは、Auth MethodsやSecrets Enginesなど、有効化することで利用可能となる。

  • System backendは、/sysエンドポイントにマウントされるVaultのデフォルトbackendである。

    • このエンドポイントは無効にしたり移動したりすることはできない。
    • Vault を設定し、Vault の内部機能の多くとやり取りするために使用される。
    • 詳細は、https://developer.hashicorp.com/vault/api-docs/system を参照
    • /sysエンドポイントの利用には、sudo権限が必要
  • Vaultには、使用または削除できないシステム予約Pathがいくつか存在する。

  • 各Componentには、デフォルトPATHがある。(以下は一例)

Pathのマウントポイント 概要
sys/ System Backendのエンドポイント
auth/ Auth Methodsのエンドポイント
database/ SecretsEnginenのdatabaseのエンドポイントと構成

データの保護

https://developer.hashicorp.com/vault/docs/internals/architecture

Vaultには2種類の鍵がある。

https://developer.hashicorp.com/vault/docs/internals/architecture より引用

ルートキー(Root Key)

  • 暗号キー(Encryption Key)を復号するために利用する。
  • Vaultの初期化時またはRekey操作時に作成される。
  • 従来のUnsealメカニズム使用時には、ストレージに書き込まれない ※ Unsealについては後述

暗号キー(Encryption Key)

  • Storage Backendに書き込まれたデータの暗号化/復号化に使用される。
  • ルートキー(Root Key)で暗号化する。
  • Storage Backendのキーリングにデータと共に保存される。
  • ローテーション可能(手動操作が必要)

Seal/Unseal

https://developer.hashicorp.com/vault/docs/concepts/seal
seal とは直訳で封印を意味する。unseal は封印解除の意味。

  • statusは vault status コマンドで確認可能。
  • Vaultは sealed statusで開始される。この状態では、復号化することはできない。
  • Vaultが sealed status では、ステータスチェックとunsealのみが可能。
  • Vaultをunsealすることは、ノードが暗号キーを解読するためにルートキーを再構築し、最終的にデータを読み取ることを意味する。
  • unseal後、暗号キーはメモリに保存される。

Vault Initialization(Vaultの初期化)

https://developer.hashicorp.com/vault/docs/commands/operator/init

  • 初期化により、バックエンドストレージがデータを受け取る準備ができる。
  • 初期化は、Vaultがルートキーとキーシェアを作成する行為。
  • CLI、API、UIを通じて初期化する。
  • 閾値、キーシェア、リカバリキー、暗号化などのオプションがある。

Vault Configuration(Vaultの設定)

https://developer.hashicorp.com/vault/docs/configuration

  • HCLまたはJSONで書かれたconfigファイルで設定する。
  • --config フラグにより設定ファイルを指定してVaultサーバを起動すれば反映される。

Vaultのインターフェースについて

  • Vaultと対話するために3つのインターフェースがある(UI、CLI、API)
  • 全てのVault機能がUIとCLIで利用可能なわけではないが、すべての機能はAPIを使用してアクセスできる。
  • CLIとUIからの呼び出しはHTTP APIを呼び出す。CLIはHTTP APIの上に薄くラップされたものである。
  • UIは設定ファイルを介して有効にする必要がある。
  • インターフェースにアクセスするには認証が必要。

Vaultで利用するポート

Vaultの推奨アーキテクチャを元に、必要な通信ポートを整理する。
Vaultの推奨アーキテクチャは、Hashicorp社ドキュメントに以下の通り記載がある。


https://developer.hashicorp.com/vault/tutorials/day-one-raft/raft-reference-architecture より引用

ポート番号 用途
443 ・クライアントからAPIのLBへのトラフィック
8200 ・LBからVault Serversへの通信(Vault API)
・Vault Server間の通信(Cluster bootstrapping)
8201 ・クラスタ内の通信
・レプリケーション

devモード

https://developer.hashicorp.com/vault/docs/concepts/dev-server
vaultサーバの起動オプションには devモードがある。(サーバ起動時に引数で設定)
devモードでも全ての機能を利用できるため、PoCやvaultの機能テスト、アプリケーションとのインテグレーションテストなどに利用する。

以下の特徴を持つ。

  • 設定不要で起動可能。
  • 自動的にrootとしてログイン
  • 初めからstatusが initializedおよびunsealedとなる。
  • 単一のunseal keyが提供される
  • リスナーを127.0.0.1:8200に設定します。
    • localhostの利用
    • TLSは利用しない(つまり、安全ではない)
  • K/V v2シークレットエンジンをマウントする。
  • メモリ上で動作するので、永続化はしない

Comunity/Enterprise/HCP Vaultの違い

ComunityとEnterpriseの違い

https://shankar-lal.medium.com/ç-1e1e0f223d41

communityにはないものは以下

  • HashiCorp社のサポート
  • レプリケーション機能
  • スケーラビリティ
  • Sentinelによるポリシー制御
  • namespace

EnterpriseとHCP Vaultの違い

以下の公式ドキュメントに比較が言及されている。
最も大きな違いとして、HCP Vaultはマネージドサービスとなっており、ホストの管理やアップグレードをHashiCorp社にお任せできる。
https://developer.hashicorp.com/vault/tutorials/cloud/vault-introduction
https://www.hashicorp.com/products/vault/pricing

また、触っていると気づくが、最上位のnamespaceがEnterpriseだと root 、HCP vaultだと admin となっている。(地味にややこしい)

参考

https://developer.hashicorp.com/vault/docs
https://youtube.com/playlist?list=PLFkEchqXDZx7CuMTbxnlGVflB7UKwf_N3&si=uJE2c_GhjxQ4FmMA
HashiCorp Certified: Vault Associate 2024 (w/ Hands-On Labs)
HashiCorp Certified: Vault Operations Professional

最後に(採用のお知らせ)

イオンスマートテクノロジーではエンジニアをはじめとした様々な職種を積極的に採用中です!
これからとてもおもしろいフェーズへ突入していくと思いますので興味のある方は是非カジュアル面談などで話を聞いてください!

https://engineer-recuruiting.aeon.info/

AEON TECH HUB

Discussion