Secretとは、パスワードやトークン、キーなどの機密データを含むKubernetersのリソースです。

例えば、GKEからDBに接続する場合、ユーザー名やパスワードといった情報をPodに渡す必要があります。
Secretを利用しない場合はこのような情報をアプリケーションのコードに記載する必要があり、
セキュリティリスクとなります。

Secretを利用すると、Podと独立したリソースで機密データの管理が可能であり、
アプリケーションのコードに機密データの記載が不要です。

もう少しかみ砕いて説明すると、
Secret内で、変数名(例:username)と値(例：admin)を定義します。
PodからSecretをマウントすることで、アプリケーションコードにてSecretで定義した変数が利用可能となります。

Secretは、Base64でエンコード/デコードが行われるという特性があり、以下2つの問題点があります。

①SecretのマニュフェストファイルにはBase64でエンコードした値を記載する必要があり、
　ファイルの閲覧権限があれば誰でもデコードして平文データを取得可能
②Secretへ読み込み権限があれば誰でもデコードして平文データを取得可能

マニュフェストファイル上では暗号化されていますが、
暗号化方法がBase64と知られているため、
簡単に復元できてしまうのでセキュリティリスクになります。

Kubernetesを利用する場合、
マニュフェストファイルの管理にGitHubなどのソース管理ツールを利用するかと思いますので、
今回は①の解決方法についてご説明いたします。

②についてはGoogle Cloudのベストプラクティスに従い、RBACロールの設計を行うことが解決策のため、今回の記事では割愛させていただきます。

※Secretのマニュフェストファイルの例

数あるSecret管理方法の中から、今回は以下5つの方法についてご説明いたします。

1. KubeSecを利用する方法
2. Sealed Secretsを利用する方法
3. Kubernetes External Secretsを利用する方法
4. External Secrets Operatorを利用する方法
5. Secretのマニュフェストファイルを作成しない方法

1.KubeSecを利用する方法

KubeSecとはKubernetesのSecretを暗号化するツール。
マニュフェストファイルのデータ構造を保ったまま、必要な部分のみを暗号化することができる。

・機密データのみを暗号化するため、可読性が高い状態でマニュフェストファイルを管理できる。

・開発環境とデプロイ環境にkubesecコマンドをインストールする必要がある。
・鍵管理が必要となる。
・マニュフェストファイル作成時に暗号化、Secretデプロイ時に復号する必要があり、手間がかかる。

※今後出てくるアーキテクチャのソース管理ツールはGitHubとする

1. 開発環境にて、マニュフェストファイル(Secret.yaml)を作成
2. 開発環境にて、暗号化鍵を用いてマニュフェストファイル(Secret.yaml)を暗号化
3. 開発環境にて、暗号化したマニュフェストファイル(SecretDescription.yaml)をGitHubにPush
4. デプロイ環境にて、GitHub上の暗号化されたマニュフェストファイル(SecretDescription.yaml)をClone
5. デプロイ環境にて、暗号化したマニュフェストファイルを復号(SecretDescription.yaml→Secret.yaml)
6. デプロイ環境にて、復号したマニュフェストファイル(Secret.yaml)から、Secretをデプロイ
7. PodからSecretをマウント

※暗号化したファイル例

参考
https://kubesec.aquasec.com

2.Sealed Secretsを利用する方法

Sealed Secretsとは、Bitnamiが開発する公開鍵暗号方式を採用したSecretの暗号化ソリューション。
GKEにSealed Secrets Controllerを構築することで、Secretの復号を自動的に行う。

・GKE内でマニュフェストファイルの復号が自動実行される(手動での復号作業が不要)。
・機密データのみを暗号化するため、可読性が高い状態でマニュフェストファイルを管理できる。
　※暗号化したマニュフェストファイルはKubeSecと同様

・開発環境にkubesealコマンドをインストールする必要がある。
・手動で暗号化が必要となる。
・鍵管理が必要となる。
・コントロールプレーンにSealed Secretsをインストールする必要があり、初期構築に手間がかかる。

※前提としてSealed Secrets Controller構築は完了していることとする

1. 開発環境にて、マニュフェストファイル(Secret.yaml)を作成
2. 開発環境にて、kubesealコマンドと公開鍵を用いてマニュフェストファイル(Secret.yaml)を暗号化
3. 開発環境にて、暗号化したマニュフェストファイル(SealedSecret.yaml)をGitHubにPush
4. デプロイ環境にて、GitHub上の暗号化されたマニュフェストファイル(SealedSecret.yaml)をClone
5. デプロイ環境にて、暗号化したマニュフェストファイル(SealedSecret.yaml)からSealedSecretをデプロイ
6. Sealed Secrets Controllerにて、秘密鍵を用いてSealedSecretから自動でSecretをデプロイ
7. PodからSecretをマウント

参考
https://github.com/bitnami-labs/sealed-secrets

3.Kubernetes External Secretsを利用する方法

メンテナンス期に移行するというアナウンスに伴い、非推奨となっており、
後述するExternal Secrets Operator(ESO)への移行を推奨しているため省略。

4.External Secrets Operatorを利用する方法

External Secrets Operatorとは、Secret Managerなどの外部Providerに保存された機密データを取得し、
Secretとして利用するためのソリューション。
GKEにExternal Secrets Operator Controllerを構築し、外部Providerに保存した機密データを利用することで、手動での暗号化や復号、鍵の管理も不要となる。

・Secret Mangerを利用するため、鍵管理が不要。
・手動での暗号化や復号作業が不要。

・管理するマニュフェストファイルが2つとなる。
・コントロールプレーンへExternal Secrets Operatorのインストールが必要であり、初期構築に手間がかかる。
・比較的新しい技術のため、情報が少ない。

※前提として以下の作業が完了していることとします

• ・Secret ManagerでKey作成
• ・Google CloudのService Account(GSA)作成
• ・KubernetesのService Account(KSA)作成
• ・GSAとKSAの紐づけ
• ・External Secrets Operator構築

1. 開発環境にて、マニュフェストファイル(ClusterSecretStore.yaml※1、ExternalSecret.yaml※2)作成
2. 開発環境にて、マニュフェストファイル(ClusterSecretStore.yaml、ExternalSecret.yaml)をGitHubにPush
3. デプロイ環境にて、GitHub上のマニュフェストファイル(ClusterSecretStore.yaml、ExternalSecret.yaml)をClone
4. デプロイ環境にて、マニュフェストファイル(ClusterSecretStore.yaml、ExternalSecret.yaml)から、ClusterSecretStore、ExternalSecretをデプロイ
5. External Secrets Operator Controllerにて、ClusterSecretStoreを用いて、Secret Managerにアクセス※3
6. External Secrets Operator Controllerにて、ExternalSecretの定義に従って、自動でSecretをデプロイ
7. PodからSecretをマウント

※1 ClusterSecretStoreとは、外部Provider(Secret Manager)への接続情報を指定するリソース
※2 ExternalSecretは外部Providerの機密データをどのようにSecret(リソース名、Secret Keyなど)として定義するかを指定するリソース
※3 内部的には事前に作成したKSAとGSAを利用してSecret Managerにアクセス

参考
https://github.com/external-secrets/kubernetes-external-secrets

5.Secretのマニュフェストファイルを作成しない方法

マニュフェストファイルを利用せず、コマンド直打ちでSecretを作成する。

・マニュフェストファイルの管理が不要。

・機密データを別途管理する必要があり、運用管理が煩雑となる可能性がある。

今回、GKEのSecret管理方法を5つ紹介させていただきました。
他にもアプリケーションから直接Secret ManagerのAPIを実行するという案もありましたが、
アーキテクチャが複雑となる、CI/CDとの相性が悪い、という理由から除外しました。

私個人としては、運用管理のしやすさ、強固なセキュリティ、という観点から、
「4.External Secrets Operatorを利用する方法」を推したいと思っております。

セキュリティと利便性はトレードオフのため、最適解を導きだすのは困難かと思いますが、
少しでもみなさまのお役に立てれば幸いです。

最後までご覧いただきありがとうございました！！

参考
https://kubernetes.io/ja/docs/concepts/configuration/secret
https://qiita.com/tmonoi/items/31cfa4313226b44232c0
https://github.com/shyiko/kubesec
https://tech.uzabase.com/entry/2020/03/10/171733
https://github.com/bitnami-labs/sealed-secrets
https://zenn.dev/champon1020/articles/bf3cfd302e0e6a
https://github.com/external-secrets/kubernetes-external-secrets/issues/864
https://github.com/external-secrets/kubernetes-external-secrets
https://zenn.dev/nameless_gyoza/articles/external-secrets-operator
https://external-secrets.io/v0.6.0-rc1