Cloud でのKubernetesとSecrets Management（シークレットの管理）―後半

APIキー、パスワード、証明書、その他の機密データをクラウドネイティブのシークレット管理サービスに保存し、K8sクラスタからアクセスします。

はじめに

シークレットは多くのプロダクションシステムの運用に欠かせないものです。意図しないシークレットの暴露は、適切に対処すべきトップリスクの一つです。開発者は、アプリケーションのシークレットを守るために最善を尽くすべきです。

企業がマイクロサービス・アーキテクチャに移行し、複数のサービスが適切に動作するためには異なる秘密へのアクセスが必要になると、問題はさらに難しくなります。そして、これは新たな課題につながります。アプリケーションのシークレットをどのように分散、管理、監視、ローテーションし、意図しない暴露を避けるか、ということです。

前回の記事（前編）では、対象のPodに手動で追加した doitintl/secrets-init initContainerを使って、AWSとGoogle Cloudのsecrets managementサービス（AWS Secrets Manager, AWS SSM Parameter Store、Google Cloud Secret Manager）をKubernetesに統合する方法を紹介しました。

今回の記事では、上記のクラウドsecrets managementサービスをKubernetesネイティブで統合する方法を紹介します。

Automatic Cloud Secret Injection

コンテナのinitシステムとしてsecret-initを使用するようにKubernetes DeploymentのYAMLファイルを手動で修正することは可能ですが、誰かがあなたの代わりにそれをやってくれて、クラウドのsecretを参照しているKubernetesのPodにだけ実行してくれるならば、より素晴らしいですよね。幸いなことに、Kubernetesではコンテナが作成される前に、 mutating admission webhookとして知られているメカニズムを使って、任意のPodを検査して修正することができます。

doitintl/kube-secrets-initは、cloud secrets injectionのためのKubernetesのmutating admission webhook を実装した DoiT Internationalのオープンソースプロジェクトで、AWSとGoogle Cloudの両方の管理されたシークレットに対応しています。

kube-secrets-initは、新規作成または更新されたPodsに対してKubernetesクラスタを監視し、直接(環境変数を介して)および/または間接的に(Kubernetes SecretとConfigMapを介して)cloud secretを参照しているPodsにdoitintl/secrets-initユーティリティを持つinitContainerを追加します。