Vault Secrets Operator は、HashiCorp Vault で管理されているシークレットを Kubernetes クラスタに同期することができるオペレータです。
2023年6月13日に v0.1.0 がリリースされて GA となりました。 それ以降、2～3 ヶ月ごとにリリースされており、2024年5月7日現在は v0.6.0 が最新バージョンとなっています。
| バージョン | リリース日 |
|---|---|
| v0.6.0 | 2024年4月25日 |
| v0.5.0 | 2024年2月16日 |
| v0.4.0 | 2023年11月17日 |
| v0.3.0 | 2023年9月28日 |
| v0.2.0 | 2023年8月17日 |
| v0.1.0 | 2023年6月13日 |
GA からもうすぐ 1 年が経とうとしているのですが、最新のバージョンまでにどのような機能が追加されているのか、また、どのような改善が行われているのか追えていませんでした。
そこで今回は、Vault Secrets Operator の v0.1.0 から v0.6.0 までの主な変更点をまとめてみたいと思います。 そして、少しでも興味を持っていただけたら、ぜひ Vault と合わせて Vault Secrets Operator を使ってみてください。
主要な変更点
それでは v0.1.0 の機能をベースに、最新の v0.6.0 までの主な変更点を見てみましょう。
GitHub のリリースページから情報を拾ってきていますので、ここで述べた変更点以外も確認したい方は以下のリンクからリリースノートを参照してください。
別名前空間の VaultConnection と VaultAuth をサポート (v0.2.0)
VSO では主に 3 種類のカスタムリソースを使って Vault クラスタからシークレットを引っ張ってきます。
VaultConnection が Vault クラスタのアドレスなどの接続情報、VaultAuth が Vault クラスタへの認証情報、VaultDynamicSecret や VaultStaticSecret などが実際にシークレットを取得するためのリソースになっており、VaultDynamicSecret が VaultAuth を、VaultAuth が VaultConnection を参照する形になっています。
簡単に表すとこんな感じです。
VaultConnection <- VaultAuth <- VaultDynamicSecret
v0.1.0 時点では各リソースの参照先を示す vaultAuthRef と vaultConnectionRef というフィールドにはリソース名の指定しかできず、同じ名前空間にあるリソースしか参照できませんでした。
v0.2.0 からは、vaultAuthRef と vaultConnectionRef フィールドの接頭辞として名前空間を指定できるようになっており、別の名前空間にあるリソースを参照することができるようになりました。
例えば、接続情報は Kubernetes クラスタ内で 1 つ、認証情報は別の名前空間に分けて管理、さらにシークレットは別の名前空間に分ける、といった使い方もできるようになりました。
とはいえ、「Kubernetes クラスタ内で 1 つ」のような構成であれば、vaultAuthRef や vaultConnectionRef を省略することで VSO のデフォルトの情報を参照させることができるので、あえてカスタムリソースをデプロイする必要もありません。
Vault クラスタの接続情報や認証情報に VSO のデフォルトを使う場合は Helm の values.yaml で設定が必要です。
HCP Vault Secrets のサポート (v0.3.0)
HashiCorp Cloud Platform (HCP) で提供されている HCP Vault Secrets に格納したシークレットも VSO を使って Kubernetes に同期できるようになりました。
HCP Vault Secrets は、Vault の KV シークレットエンジンのみをサポートして機能を制限する代わりに運用負荷を軽減したサービスです。
これまでの VSO は Vault クラスタにのみ対応しており、コミュニティ版 Vault や HCP Vault など Vault の動く環境は選びませんでしたが、サービスの種類自体が異なる HCP Vault Secrets には対応していませんでした。
HCP Vault Secrets に対応したことで、「マルチクラウド環境のシークレットを統合管理したいけど Vault クラスタを用意するのはハードルが高い」といったユースケースにも対応できるようになりました。
HCP Vault Secrets は 3 大クラウドのシークレットマネージャーに対応しているのはもちろん、GitHub や Vercel などその他のサービスのシークレットも管理することができ、かつコストも抑えられるので、シークレットの統合管理の第一歩としてとても使いやすいサービスだと思います。
スケジュールベースの静的ロールローテーションのサポート(v0.3.0)
本家の Vault では v1.5.0 から「スケジュールベースの静的ロールローテーション」という機能が追加されましたが、VSO でも v0.3.0 からスケジュールベースの静的ロールローテーションが利用できるようになりました、というアップデートです。
「そもそも静的ロールとはなんだ」という疑問があると思いますが、Vault の Dynamic Secrets という機能にはデータベースに対して認証情報を作成する「動的ロール」と「静的ロール」があり、「動的ロールはユーザ名とパスワードを Vault 側が生成、静的ロールはユーザ名を事前に指定してパスワードは Vault が生成」という違いがあります。
そして、「スケジュールベースの静的ロールローテーション」では静的ロールで作成されたデータベースの認証情報を CRON スタイルで指定したスケジュールでローテーションできるようになり、例えば以下の例では「毎週土曜日の 0 時に vault ユーザのパスワードをローテーション」するように設定できます。
$ vault write database/static-roles/my-role \
db_name=my-database \
username="vault" \
rotation_schedule="0 * * * SAT"
VSO では VaultDynamicSecret カスタムリソースの spec.allowStaticCreds フィールドを true に設定することで、静的ロールを使った Dynamic Secrets が有効になります（この機能自体は以前からありました）。
v0.3.0 でのスケジュールベースの静的ロールローテーションのサポートというのは、VaultDynamicSecret カスタムリソースのステータスに rotationSchedule フィールドが追加されて VSO のコントローラの処理で使われるようになったということで、VSO 利用者からすると Vault 側で「スケジュールベースの静的ロールローテーション」を設定していれば特に意識する必要はないと思います。
apiVersion: secrets.hashicorp.com/v1beta1 kind: VaultDynamicSecret metadata: namespace: vso-example name: vault-dynamic-secret-db spec: vaultAuthRef: vault-auth mount: db path: creds/my-postgresql-role destination: create: true name: dynamic-db allowStaticCreds: true # 静的ロールを利用
GCP Auth Method のサポート (v0.4.0)
Google Kubernetes Engine (GKE) の Workload Identity を使用した Google Cloud Auth Method をサポートするようになりました。
あらかじめ、GKE で Workload Identity を有効にしておき Vault にも Google Cloud Auth Method を有効化、ロールを作成しておきます。
その後、VSO の認証情報を定義した VaultAuth カスタムリソースに gcp フィールドを追加し、Google Cloud Auth Method の認証情報を設定することで、VSO が Google Cloud Auth Method を使った Vault への認証が可能になります。
現時点ではこのような認証方法をサポートされているのは、今回追加された Google Cloud と以前からサポートされている AWS のみで、Azure などではサポートされていないようです。
Vault Dynamic Secrets の改善 (v0.4.0)
VSO は Vault Dynamic Secrets (VDS) もサポートしていますが、v0.4.0 以前には Vault Dynamic Secrets 周りで以下の不具合があったようです。
- VSO Pod
vault-secrets-operator-controller-managerの再起動によってアプリケーションの Pod が意図せず再起動がされる - Dynamic Secrets で取得された Secret リソースがローテーションされない
v0.4.0 ではこれらの不具合が修正され、VDS の利用が安定して行えるようになりました。 Vault Dynamic Secrets (VDS) を利用していて v0.4.0 以前のバージョンを利用している場合は、アップグレードを検討することをおすすめします。
シークレットデータの変換機能の追加 (v0.5.0)
v0.5.0 からは、Vault から取得したシークレットデータを変換して Secret リソースにデプロイする機能が追加されました。 この機能には「テンプレート」と「フィルター」の 2 つの変換方法が提供されています。
今までは、Vault から取得したシークレットデータをそのまま Secret リソースにデプロイすることしかできませんでしたが、シークレットデータの変換を使うことで、取得したデータを加工してデプロイしたり、Secret リソースに格納するデータをフィルタリングすることができるようになります。
この機能を実現するために、VaultDynamicSecret などのシークレット用カスタムリソースに spec.Destination.Transformation フィールドが追加されています。
また、SecretTransformation という専用のカスタムリソースも追加されており、SecretTransformation で変換方法を定義し、VaultDynamicSecret などのカスタムリソースで参照することで変換機能を利用できます。
公式ドキュメントだけではいまいちイメージが沸かなかったので、別途記事を投稿してみようと思います。
注意点
v0.6.0 と v0.5.0 、および v0.4.1 では CRD (Custom Resource Definition) の仕様が変更されており、既存のリソースをアップグレードする際に注意が必要です。 Helm で VSO を上記のバージョンにアップグレードする前に、CRD を手動で更新していないと VSO のアップグレードに失敗してしまいます。
詳細は公式ドキュメントを参照してください。
まとめ
今回は Vault Secrets Operator の v0.1.0 から v0.6.0 までの追加機能や改善点について紹介しました。
Vault を使っている環境であれば、VSO を使ってシークレットを管理することで、Vault と Kubernetes の連携をよりスムーズに行うことができるようになります。 バージョンが上がるにつれて VSO はより多くの機能をサポートするようになっているため、最新のバージョンを利用することをおすすめします。 また、CRD の仕様変更には注意が必要ですので、アップグレードの際には公式ドキュメントを参照してください。
ロードマップなども紹介したいところですが、残念ながロードマップは公開されていないようですので、今後どのような機能が追加されていくかはリリースに期待しましょう。
【PR】
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。
一緒に働いていただける仲間も募集中です！
まだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
我々の事業部のCultureDeckはコチラ。
