KubernetesのSecretは「裸」同然だ。KMS連携でその脆弱性を埋める技術論
いいか、エンジニア諸君。Kubernetesを使っているチームから相談を受けるとき、決まって聞く質問がある。「Secretリソースは安全に管理しているか？」と。すると大抵、彼らは「はい、KubernetesのSecretオブジェクトを使っています」と自信満々に答える。
だが、現実は残酷だ。デフォルトのKubernetes設定において、SecretはBase64エンコードされただけの平文としてetcdに保存されているに過ぎない。これは「鍵をかけずに金庫を砂場に埋めている」のと同じだ。誰かがetcdへのアクセス権を奪った瞬間、あるいはバックアップファイルが流出した瞬間に、君たちのDBパスワードも、APIトークンも、証明書の秘密鍵もすべて丸裸になる。
今日は、この「セキュリティの盲点」を完全に塞ぐための、KMS（Key Management Service）を用いた「Encryption at Rest（保存時の暗号化）」について、現場の知見を叩き込む。
—
1. 攻撃者が狙う「etcd」の脆弱性
攻撃者は、アプリケーションの脆弱性（RCEやSQLi）だけを狙っているわけじゃない。彼らが最も好むのは、「設定ミス」という名の宝の山だ。
もし君たちのクラスタで、権限昇格を許すようなPodが一つでも侵害されたらどうなるか？ 攻撃者はkubectlコマンドを叩き、あるいは直接etcdのダンプを試みる。Base64をデコードするのに1秒もかからない。これが、私たちが「Secretは暗号化されていて当たり前」というアーキテクチャを強要する理由だ。
—
2. KMSを用いたEncryption at Restの実装
Kubernetesは、EncryptionConfigurationというリソースを使って、データをetcdに書き込む前に外部の鍵管理サービス（AWS KMS, Google Cloud KMS, Azure Key Vaultなど）で暗号化する仕組みを持っている。
今回は、最も汎用的なAWS KMSを例に、EncryptionConfigurationの定義ファイルを見ていこう。
実装：EncryptionConfiguration の設定例
この設定ファイルを、Kubernetesコントロールプレーン（kube-apiserver）から読み込める場所に配置する必要がある。
encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
# AWS KMSを使用する設定
- kms:
name: aws-kms-provider
# KMSのキーARNを指定（IAMポリシーでアクセス権限付与が必要）
key: arn:aws:kms:ap-northeast-1:123456789012:key/your-key-uuid
# キャッシュの設定（パフォーマンスとセキュリティのバランス）
cacheSize: 100
# 復号できなくなった時のためのフォールバック設定
- identity: {}
必須のインフラ設定（IAMポリシー）
kube-apiserverが動作しているEC2インスタンスやノードには、KMSを利用するためのIAMロールが必須だ。
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“kms:Encrypt”,
“kms:Decrypt”,
“kms:DescribeKey”
],
“Resource”: “arn:aws:kms:ap-northeast-1:123456789012:key/your-key-uuid”
}
]
}
—
3. なぜ「設定するだけ」では足りないのか？（現場の教訓）
設定ファイルを置いたら終わりだと思っているなら、それは甘い。以下の3点を必ず確認してくれ。
1. 既存データの再暗号化: EncryptionConfigurationを適用しても、既にetcdにある既存のSecretは自動的に暗号化されない。以下のコマンドを叩いて、強制的に再書き込みを行うのが鉄則だ。
kubectl get secrets –all-namespaces -o json | kubectl replace -f –
2. キーのローテーション: KMSのキーは定期的にローテーションすべきだ。KMS側でローテーションを有効にすれば、古いデータも復号できるようにKMSが裏で制御してくれる。
3. 監査ログの有効化: AWS CloudTrailなどで、KMSのDecrypt操作がいつ、誰（どのノード）から行われたか監視しろ。異常なアクセスがあれば、それはインシデントの予兆だ。
—
4. 最後に：セキュリティは「継続的な防衛」である
今回紹介したKMS連携は、あくまで「ストレージ保護」という一つの層に過ぎない。しかし、この層があるだけで、攻撃者が得る情報の価値は劇的に下がる。
エンジニアとして覚えておいてほしい。セキュリティとは「100%完璧な防御」を目指すことではない。「攻撃にかかるコストを最大化し、彼らが諦めて去っていく環境を作る」ことだ。
コードを書くときも、インフラを構築するときも、「もし、ここが突破されたら何が漏れるか？」と自問自答し続けること。その泥臭い思考こそが、君たちを一流のエンジニアにする。
明日の朝、君たちのクラスタが暗号化されているか、確認してくれ。それが、プロの仕事だ。
コメント