この辺りあまり日本語記事を見かけなかったので備忘録がてら残しておきます。
あくまでも投稿日時点（2024/12/06）の話だということを念頭においていただけますと幸いです。
TL;DR
- Google公式ドキュメントにあるSecrets Store CSI Driverとsecrets-store-csi-driver-provider-gcpはどうやら別物っぽい
- Autopilot clusterにおいてKubernetes Secretとの同期やそれを介した環境変数化をするのは今後に期待するしかなさそう
背景
あまり詳しくは言えないのですが、最近業務でGoogle Secret Managerに置いたSecretをGKE clusterのPod内に環境変数として展開したいと思うことがありました。なんとなくよくあるニーズな気もします。
KubernetesにおけるSecretの扱いに関しては偉大な先人らが残してくださった多くの比較記事があるので、ここでは割愛します。ZOZOでも比較記事が出てますので、よろしければこちらもご覧ください。
何やかんやでGoogle公式ドキュメントに書かれているという主理由により、今回はSecrets Store CSI Driverを使うことになりました。
Secrets Store CSI Driverについて
Secrets Store CSI Driver(以降長いのでSSCDとします)とは、Kubernetes clusterと外部のSecret Store（Google Secret Manager やAWS Secret Manager等）を連携するためのCSI Driverの一種です。
以下の公式ドキュメントによると、どうやらPod起動時にgRPCを利用して外部のSecret Storeと通信し、volumeに書き込まれたsecretをtmpfsとしてPodにmountし、Pod内から参照できるようにするのがコンセプトみたいです。
tmpfsを介してsecretをやりとりする都合上、Podが削除されたタイミングでsecretもnode上から削除される為、少なからず漏洩リスクについても考えられている手法と言えるのではないでしょうか。
実はGoogleがサポートしているCSI Driverは2つあります。（ここに気づくのが遅かった...)
-
secrets-store-csi-driver-provider-gcp
- おそらくSSCD公式からリンクで行き着く先です
- providerがgcpになっています
- alpha版ではありますが、secretのAuto RotationとKubernetes Secretとの同期がサポートされているみたいです
- Kubernetes Secretを介した環境変数化もできそう
- 公式での例がないのでこの辺分かりづらいですが、このissueを参考に書くと良さそうに思います
-
Secret Manager add-on with Google Kubernetes Engine
- こちらがGoogle公式ドキュメントにあるやり方です
- よく見るとproviderがgcpではなく、gkeになっています
- 現状まだsecretのAuto RotationとKubernetes Secretとの同期はサポートされていません
個人的にKubernetes Secretを介して環境変数とするのが、コード管理的に楽そうだったので、一つ目を検討していました。
実際にインストールしてみる
素直に公式の手順に則ってインストールしてみます。
すると、helm installあたりで弾かれます。
$ helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system
Error: INSTALLATION FAILED: create: failed to create: secrets is forbidden: User
"xxx" cannot create resource "secrets" in API group "" in the
namespace "kube-system": GKE Warden authz [denied by managed-namespaces-limitation]:
the namespace "kube-system" is managed and the request's verb "create" is denied
Autopilot clusterの制約
どうやらAutopilot clusterでは、公式のSSCDは入らないみたいでした。
CSI DriverにはPrivileged pod(特権コンテナ)での実行とhostPathの許可が必要らしく、GKE Wardenという名のAutopilot組み込みのセキュリティに弾かれるみたいです。
詳しくは下記をご参照ください。
The Secrets Store CSI Driver daemonset runs as root in a privileged pod. This is because the daemonset is responsible for creating new tmpfs filesystems and mounting them into existing pod filesystems within the node’s hostPath.
ref. https://secrets-store-csi-driver.sigs.k8s.io/concepts#security
issueが起票されていた...
下記のやり取りを見る感じ、結局のところGoogle CloudでSSCDを使っていくなら、Secret Manager Add-onを使っていくのが無難そうに個人的には思っています。既存のSSCDとAutopilotの互換性を維持するために生まれたのがAdd-on版っぽい(？)