HashiCorp VaultをKubernetesにYAMLマニフェストを大量作成せずにデプロイする方法

KubernetesクラスタにHashiCorp Vaultを手動でセットアップしようとしたことがある人なら、Deployment、StatefulSet、ConfigMap、TLSシークレット、サイドカーコンテナなどを延々と組み合わせた記憶があるでしょう。YAMLファイルのインデントを1つ間違えるだけで、アプリケーションがデータベースにアクセスできなくなります。

公式のvault-helmチャートれば、この問題が解決します。HashiCorpのエンジニアたちが、ローカル開発環境から分散HAクラスタまで対応のシークレットマネージャー デプロイを1つのチャートにパッケージ化了。

そもそもなぜこのチャートを使うのか？

このリポジトリは、Kubernetes内でVaultを実行する標準的な方法となっています。Podの仕様をゼロから記述したり、組み込みのRaftコンセンサスのストレージマウント方法を調べたりする必要はありません。設定はすでにvalues.yaml設定ファイルに組み込まれています。

このツールは、インフラ内でシークレットストレージを整備するDevOpsエンジニアやシステム管理者にとって便利です。サービスがAPIキー、データベース認証情報、TLS証明書が必要な場合、チャートれば数分で信頼性の高いVaultをデプロイできます。

主な機能

チャート開発者は主要なユースケースを想定しています：

• 動作モードのクイック切り替え

  設定パラメータを通じて、インスタンスをスタンドアロンモードから障害耐性クラスタに切り替えられます。ローカルテストには最小限のvaluesファイルで十分ですが、本番環境では組み込みのRaftまたは外部データベースを有効にします。

• Vault Agent Injectorによるシークレット注入

  アプリケーションはVaultのREST APIの使い方を知る必要がなくなります。インジェクタは自動的にPodにサイドカーコンテナを追加します。このコンテナがシークレットを取得し、Podのローカルファイルシステムに保存します。アプリケーションはVaultネットワークに一切アクセスせずにファイルからデータを読み取ります。

• Kubernetes Auth Engineによる認証

  チャートはKubernetesの認可メカニズムと統合しています。VaultはPodサービスアカウントを検証し、承認されたアプリケーションにのみシークレットを配信します。

• コンポーネントの分離

  サーバーサイド、エージェント、インジェクタを別々にデプロイできます。これにより、Vaultサーバーをメインアプリケーションの外部に移動したり、workerノードで軽量なエージェントのみを実行したりすることが可能になります。

Vaultのデプロイ方法

実行中のKubernetesクラスタ（バージョン1.29以上）とHelmバージョン3.6以上が必要です。基本的なリリースインスタンスのセットアップは、たった2つのコマンドで完了します：

実際の環境では、標準設定では不十分な 경우가ほとんどです。カスタムパラメータファイル（例：my-values.yaml）が必要です：

組み立てたパラメータでチャートをデプロイします：

その後、実行中のPodにアクセスしてvault operator initコマンドを実行し、Vaultの封印を解除するだけです。

運用の考慮事項

values.yaml設定ファイルには数百のオプションが含まれています。初めてですべてを把握するのは難しいので、公式ドキュメントを読む時間を確保しておきましょう。

2つ目のポイントは、再起動後の封印解除に関するものです。デフォルトでは、Vaultは封印された状態で起動します。本番環境では最初からクラウドKMSサービスを使ったAuto-Unsealを設定することをお勧めします。そうしないと、ポッドがクラッシュするたびに手動でキーを入力する必要があります。

このツールの対象ユーザーは？

Kubernetesで作業しており、集中型シークレット管理の実装を計画している場合、このチャートは独自のマニフェスト作成に何週間も費やす必要性をなくしてくれます。

隔離された名前空間でテストインスタンスをデプロイすることから始めましょう。シンプルなテストアプリケーションにインジェクタのアノテーションを追加し、ソースコードを変更せずにシークレットがコンテナに届く様子を確認してみてください。