Google CloudのSecrets Store CSI Driverを使ってみたらなんかちょっとハマった件


この辺りあまり日本語記事を見かけなかったので備忘録がてら残しておきます。
あくまでも投稿日時点（2024/12/06）の話だということを念頭においていただけますと幸いです。

# TL;DR
- [Google公式ドキュメントにあるSecrets Store CSI Driver](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)と[secrets-store-csi-driver-provider-gcp](https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp)はどうやら別物っぽい
- Autopilot clusterにおいてKubernetes Secretとの同期やそれを介した環境変数化をするのは今後に期待するしかなさそう

# 背景
あまり詳しくは言えないのですが、最近業務でGoogle Secret Managerに置いたSecretをGKE clusterのPod内に環境変数として展開したいと思うことがありました。なんとなくよくあるニーズな気もします。


KubernetesにおけるSecretの扱いに関しては偉大な先人らが残してくださった多くの比較記事があるので、ここでは割愛します。ZOZOでも比較記事が出てますので、よろしければこちらもご覧ください。

https://techblog.zozo.com/entry/kubernetes-external-secrets-to-external-secrets-operator

何やかんやで[Google公式ドキュメント](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)に書かれているという主理由により、今回は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の一種](https://kubernetes-csi.github.io/docs/drivers.html)です。

以下の公式ドキュメントによると、どうやらPod起動時にgRPCを利用して外部のSecret Storeと通信し、volumeに書き込まれたsecretをtmpfsとしてPodにmountし、Pod内から参照できるようにするのがコンセプトみたいです。

tmpfsを介してsecretをやりとりする都合上、Podが削除されたタイミングでsecretもnode上から削除される為、少なからず漏洩リスクについても考えられている手法と言えるのではないでしょうか。

https://secrets-store-csi-driver.sigs.k8s.io/concepts


実はGoogleがサポートしているCSI Driverは2つあります。（ここに気づくのが遅かった...)
- [secrets-store-csi-driver-provider-gcp](https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp)
    - おそらくSSCD公式からリンクで行き着く先です
    - providerがgcpになっています
    - alpha版ではありますが、secretのAuto RotationとKubernetes Secretとの同期がサポートされているみたいです
    - Kubernetes Secretを介した環境変数化もできそう
        - 公式での例がないのでこの辺分かりづらいですが、[このissue](https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/issues/157)を参考に書くと良さそうに思います
- [Secret Manager add-on with Google Kubernetes Engine](https://cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)
    - こちらがGoogle公式ドキュメントにあるやり方です
    - よく見るとproviderがgcpではなく、gkeになっています
    - 現状まだsecretのAuto RotationとKubernetes Secretとの同期はサポートされていません

個人的にKubernetes Secretを介して環境変数とするのが、コード管理的に楽そうだったので、一つ目を検討していました。

# 実際にインストールしてみる
素直に[公式の手順](https://secrets-store-csi-driver.sigs.k8s.io/getting-started/installation)に則ってインストールしてみます。
すると、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


https://cloud.google.com/kubernetes-engine/docs/concepts/autopilot-security#autopilot-pss

# issueが起票されていた...

下記のやり取りを見る感じ、結局のところGoogle CloudでSSCDを使っていくなら、Secret Manager Add-onを使っていくのが無難そうに個人的には思っています。既存のSSCDとAutopilotの互換性を維持するために生まれたのがAdd-on版っぽい(？)

https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/issues/158