etcdの「素っ裸」をどう覆うか：KMS連携によるKubernetes Secretの死角を突く
Kubernetesの設計思想において、Secretリソースは「便利だが危険な存在」だ。デフォルトではBase64エンコードされただけの文字列としてetcdに鎮座している。これに気づいた攻撃者は、クラスタの管理者権限を奪取した瞬間、バックアップファイルやetcdのダンプからクレデンシャルを丸裸にする。
多くのアーキテクトがここで満足する。だが、本質的な防御はここから始まる。今回は、Encryption at Restの背後にあるプロトコル仕様と、実戦的なKMS連携の深淵について語ろう。
1. 静的暗号化のレイヤー：なぜ「透過的」である必要があるのか
KubernetesのEncryption at Restは、API Serverがetcdへ書き込む直前に暗号化を行う仕組みだ。ここで重要なのは、アプリケーション（Pod）側は暗号化を意識する必要がないという「透過性」にある。
しかし、セキュリティの現場において「透過的」という言葉は、「監査のブラックボックス化」というリスクと背中合わせだ。
KMSプロバイダーの通信仕様とプロトコル欠陥
KMS連携では、API ServerはgRPC経由でKMSプラグインと通信する。ここで攻撃者が狙うのは、Unixドメインソケット経由の通信における認証の欠如や、鍵管理サーバーへのリクエストを横取りするサイドチャネル攻撃だ。
特に意識すべきは、暗号化アルゴリズムの選定である。aescbcはもはや過去の遺物に近い。現在、我々が採用すべきは aesgcm（AES-GCM）だ。GCMモードは認証付き暗号であり、データが改ざんされていないことを数学的に保証する。単なる秘匿化ではなく、「完全性」を担保せざるを得ない現代のアーキテクチャでは、これが最低限の防衛ラインとなる。
2. 実装：KMSプロバイダー設定の勘所
以下は、AWS KMSを用いた設定例だ。単に動くものを作るのではなく、鍵のローテーションと監査ログを意識した構造にする。
EncryptionConfigurationのテンプレート
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- kms:
# KMSのARNを直接指定。IAMロールでAPI Serverに権限を付与しておく
name: my-kms-provider
endpoint: unix:///var/run/kms-plugin.sock
cachesize: 100
# 鍵の寿命を管理するため、タイムアウトは厳密に設定する
timeout: 3s
- identity: {} # セキュリティ的には非推奨だが、移行時のフォールバックとして残す場合は注意
泥臭いインシデントハンドリングの知見
現場で最も多いトラブルは「KMSの権限剥奪による復号不能」だ。API Serverが起動時にKMSへ接続できなければ、既存のSecretは全てゴミと化す。
- 解決策: KMSのIAMポリシーには
kms:Decryptとkms:Encryptだけでなく、kms:DescribeKeyの権限も必須だ。これがないとメタデータが取得できず、API Serverはフリーズする。
3. 次世代の脅威：耐量子暗号（PQC）への備え
今、我々が設計するシステムは、5年後、10年後の暗号解析技術に耐えうる必要がある。現在利用しているAES-256は量子コンピュータに対して比較的耐性があると言われているが、問題は「鍵配送プロトコル」にある。
KMSとの通信に利用されるTLSハンドシェイクが、量子アルゴリズム（Shorのアルゴリズム等）によって破られる可能性を考慮しなければならない。将来的なロードマップとして、KMSプロバイダーとの通信経路にKyberなどの耐量子アルゴリズムを導入する準備を、今からアーキテクチャの片隅に置いておくべきだ。
4. プロンプトインジェクションと「コードとしての秘密」
最近のインフラ管理では、生成AIがCI/CDパイプラインを操作し、Secretを動的に生成・注入することが増えている。ここで恐ろしいのは、AIが誤ってSecretの値をデバッグログに吐き出したり、プロンプトインジェクションによってKMSの復号関数を呼び出させたりするリスクだ。
ガードレイルの設計論:
- 出力フィルタリング: API Serverから返されるレスポンスに、特定の正規表現（Secretパターン）が含まれていないか監視するサイドカーを配置する。
- 最小権限のサンドボックス: AIが操作するCI/CD環境には、KMSのDecrypt権限を与えてはならない。常に「書き込み専用」の鍵と「読み取り専用」の鍵を物理的に分離する。
結びに：セキュリティは「状態」ではなく「プロセス」である
KubernetesにおけるSecretの暗号化は、設定して終わりではない。etcd内のデータを定期的に再暗号化（re-encryption）し、鍵のローテーションを自動化し、KMSの監査ログから不審な「復号リクエストのスパイク」を検知し続ける。
この泥臭い運用の継続こそが、ハッカーの執念を削ぐ唯一の武器となる。システムを構成する一つ一つの設定値に、攻撃者の視点という「悪意」を宿せ。それが、最高峰の防衛技術を極める第一歩だ。
コメント