Kubernetesパターン 第2版 ―クラウドネイティブアプリケーションのための再利用可能パターン

25章Secure Configuration（セキュア設定）

現実世界のアプリケーションは、それぞれが孤立しているわけではありません。それぞれが外部システムと繋がってやり取りをしています。この場合の外部システムには、巨大クラウドプロバイダが提供する付加価値サービス、あなたのサービスが接続する別のマイクロサービス、データベースなどがあります。アプリケーションがどのリモートサービスに接続するかによらず、ユーザ名とパスワード、あるいは他のセキュリティトークンといった認証情報を送る必要のある認証プロセスを避けては通れないでしょう。このような機密情報は、アプリケーションに近いところでセキュアかつ安全に保存される必要があります。この章で取り上げるのは、Kubernetes上でアプリケーションを動かす際に認証情報を可能な限りセキュアに保存する最適な方法に関するSecure Configuration（セキュア設定）パターンです。

25.1　問題

「20章　Configuration Resource（設定リソース）」で学んだように、その名前に反してSecretリソースの中身は暗号化されておらず、Base64エンコードされています。とは言えKubernetesは、Secretの中身に対しては最大限のアクセス制限を行っており、その手法については20章のコラム「Secretはどのくらいセキュアなのか」で取り上げました。

ところが、ひとたびSecretリソースがクラスタの外に保存されてしまうと、その値は丸裸で脆弱になってしまいます。サーバサイドアプリケーションをデプロイし、メンテナンスする方法として普及している考え方であるGitOpsの登場により、こういったセキュリティ上の課題の解決は急を要す事態になっています。SecretはリモートのGitリポジトリに保存するべきでしょうか。そうだとすると、暗号化しないで保存するわけには行きません。しかしGitのようなソースコード管理システムに暗号化した状態でコミットしてしまったら、どこでどのように復号してKubernetesクラスタに入れればいいのでしょうか。 ...