Kubernetes Secret とは？機密データを扱う

Kubernetes Secret は、通常の設定とは分離して、pod が env var やファイルとして消費する機密データ - パスワード、token、鍵 - を保存します。

Secret は ConfigMap に似ていますが、機密の値を対象としています。secret を切り出すことで、Kubernetes はそれらをより慎重に扱えます。より厳格なアクセス制御、任意の保存時の暗号化、偶発的な logging の回避などです。しかしデフォルトの Secret は base64 でエンコードされているだけで、暗号化はされていません - 多くの人がつまずく点です。

pod がどう secret を消費するか

ConfigMap と同様、Secret は環境変数または mount されたファイルとして現れます。例えばデータベースのパスワードは、ファイルとして mount するか、それを必要とするコンテナに env var として注入できます。

base64 は暗号化ではない

デフォルトでは Secret の値は base64 でエンコードされますが、これはエンコードであって暗号化ではありません - Secret を読める者は誰でもそれをデコードできます。etcd で保存時の暗号化を有効にし、RBAC を締めて、Secret を本当に秘密にしましょう。

secret を正しく保護する

• RBAC で誰が Secret を読めるかを制限する。
• etcd で保存時の暗号化を有効にする。
• operator を伴う外部 store（Vault、クラウドの secret manager）を検討する。

Secret と ConfigMap の違い

機能的には似ています。違いは意図と扱いです。より厳格な扱いを受けるよう、機密の値は Secret に、非機密の設定は ConfigMap に入れましょう。

CI/CD における secret

pipeline は決して secret を manifest に hardcode すべきではありません。deploy 時に CI プロバイダの secret store やクラウドの secret manager から注入します。理想的には、長命な静的鍵ではなく短命な OIDC 認証情報を介してです。

重要なポイント

• Secret は、ConfigMap とは分離して、pod 用の機密データを保持します。
• デフォルトの Secret は base64 エンコードで、暗号化ではありません - 暗号化と RBAC を有効にしましょう。
• CI/CD は secret を secret store から注入すべきで、決して hardcode してはいけません。

関連ガイド