こんばんは、ACS 事業部の埜下です。
KubeCon + CloudNativeCon Europe 2023 の 3 日目、Secrets Store CSI Driver に関するセッションがあったため紹介いたします。
シークレットの課題
Kubernetes シークレットはアプリケーションが使用するアクセスキーやトークン、パスワードのデータを格納しています。
Kubernetes 上のアプリケーションはデータボリュームや環境変数といった形でシークレットを使うことができます。
秘匿情報を含むシークレットは Git などのバージョン管理システムには格納できず、どこかから Kubernetes に持ってくる必要があります。
また、IaC を使ったシークレット管理もありますが、Kubernetes のドキュメントには以下のような注意書きがあり、安全にシークレットを扱うことが難しいです。
KubernetesのSecretは、デフォルトでは、APIサーバーの基礎となるデータストア(etcd)に暗号化されずに保存されます。 APIにアクセスできる人は誰でもSecretを取得または変更でき、etcdにアクセスできる人も同様です。 さらに、名前空間でPodを作成する権限を持つ人は、そのアクセスを使用して、その名前空間のあらゆるSecretを読むことができます。 これには、Deploymentを作成する能力などの間接的なアクセスも含まれます。
引用：https://kubernetes.io/ja/docs/concepts/configuration/secret/
ではどうすればよいのでしょうか？ 先ほどの注意書きには続きがあります。
Secretsを安全に使用するには、以下の手順を推奨します。
- Secretsを安全に暗号化する
- Secretsのデータの読み取りを制限するRBACルールの有効化または設定
- 適切な場合には、RBACなどのメカニズムを使用して、どの原則が新しいSecretの作成や既存のSecretの置き換えを許可されるかを制限します。
これらを考慮された HashiCorp Vault などのシークレットプロバイダを使う方法があります。 アプリケーションが参照するシークレットをシークレットプロバイダに格納することで問題を回避できます。
しかし、アプリケーションから直接シークレットプロバイダに接続するのは避けるべきです。 それは、シークレット管理 API/SDK を呼び出すためにコード修正が必要になり、ベンダーロックインの可能性も発生するからです。
Secrets Store CSI Driver
そこで今回の解決策として紹介されているのが、Secrets Store CSI Driver です。
secrets-store-csi-driver.sigs.k8s.io
Secrets Store CSI Driver は、Container Storage Interface (CSI) ボリュームを介してシークレット ストアを Kubernetes と統合します。 CSI ドライバを使用すると、シークレットプロバイダに保存されているシークレットを Pod にボリュームとしてマウントできます。
アプリケーションが直接シークレットプロバイダに接続しなくてもシークレットを参照できるようになるのです。
デメリット
とても便利な Secrets Store CSI Driver にもデメリットはあります。
1 つ目は、管理が複雑になること。
2 つ目は、パフォーマンスにオーバーヘッドが掛かること。
そして最後のデメリットとして、シークレットの値が更新されても自動的に Pod に反映されないことです。
そんな Secrets Store CSI Driver に対して、先日 HashiCorp から Vault Secret Operator というものがプレビュー公開されました。 こちらはシークレット管理をオペレータがおこなうため、シークレットの更新も自動的に反映することができます。
詳しくは以下の記事をご参照ください。
おわりに
Kubernetes を運用していくうえでシークレット管理は誰しもが直面する課題かと思います。
今回は 1 つの解決方法である Secrets Store CSI Driver のセッション情報をまとめました。
シークレット管理については改めて情報を整理していきたいです。
