etcdという「パンドラの箱」：Kubernetes Secretsの静的データ保護とKMSによる要塞化
KubernetesにおけるSecretsは、開発者にとって「魔法の小箱」のように見えるかもしれない。しかし、攻撃者の視点から見れば、それは「素通しのデータストア」に過ぎない。
多くのエンジニアが犯す最大の過ちの一つは、Kubernetesのデフォルト設定を「安全」だと盲信することだ。実のところ、デフォルトのetcd構成では、SecretsはBase64でエンコードされているだけで、暗号化すらされていない。これは、鍵を玄関マットの下に隠しているのと同じくらい無防備な状態だ。
1. なぜ「Base64」は暗号化ではないのか
初歩的な話だが、念のため言っておく。base64 -d は復号ではなく、ただの変換だ。etcdのバックアップファイルや、コントロールプレーンへの読み取り権限（RBACの穴）を奪った攻撃者は、たった数秒であなたのAPIキー、データベースのパスワード、TLS秘密鍵を平文として手に入れる。
攻撃者の視点に立てば、Kubernetesクラスタへの侵入はゴールではなく、ここからが「権限昇格」と「水平展開」のフェーズだ。APIサーバーへのアクセス権を奪い、kubectl get secrets -A -o yaml を叩く。このコマンド一つで、システム全体のクラウンジュエルが手に入る。この脆弱性の根本原因は、データの「静止状態（at-rest）」における保護層が欠落していることにある。
2. Encryption at Rest: KMSによる「防衛の多層化」
この惨状を防ぐための切り札が、Kubernetesの EncryptionConfiguration だ。これを適切に設定することで、etcdに書き込まれる前にデータを暗号化し、読み出す際に復号するアーキテクチャを実現できる。
特に、クラウドプロバイダーが提供するKMS（Key Management Service）を統合するのは、現代のクラウドネイティブな防衛の「ゴールドスタンダード」だ。
設定例：EncryptionConfigurationの構成
以下のサンプルは、APIサーバーがetcdにデータを書き込む際の暗号化設定だ。
# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets # Secretsのみを対象にするのが一般的だが、ConfigMapも必要に応じて追加
providers:
- kms:
name: my-kms-provider
endpoint: unix:///var/run/kms-plugin.sock # KMSプラグインとの通信ソケット
cachesize: 100
timeout: 3s
- identity: {} # 万が一KMSがダウンした際、平文で保存することを防ぐため、最後にidentityを置かないことが重要ここでのポイント：
identity: {}は、実戦環境では意図的に除外する。もしKMSとの疎通が取れない場合、平文で保存されるリスクを許容するよりも、書き込みを失敗させる（Fail-Closed）設計にするのが専門家の流儀だ。- KMSのローテーション戦略は、暗号化のライフサイクル管理において不可欠である。暗号化鍵のバージョン管理を疎かにすると、キーローテーションの瞬間に過去のデータが読み出せなくなる。
3. メモリと通信プロトコルの盲点
アーキテクトが考慮すべきは、etcd上のデータだけではない。APIサーバーのメモリ内に保持される平文データも、実は攻撃対象になり得る。
メモリダンプ解析や、gcore を用いたプロセスメモリの抽出を行えば、暗号化されたetcdからロードされた直後の平文Secretsを抜き取ることが可能だ。さらに、コンテナ間通信において mTLS（Service Mesh等による）を強制していない場合、Sidecarプロキシをバイパスした通信傍受のリスクも残る。
これに対する防御層（ガードレイル）として、最近では以下のような監査手法を導入している。
- Runtime Security Monitoring:
Falcoなどを使い、/etc/kubernetes/encryption-config.yamlへの不審な書き込みや、APIサーバープロセスのメモリへの不正アクセスをリアルタイムで検知・封じ込める。 - External Secret Operator (ESO): Secretsをetcdに置くこと自体を避け、HashiCorp Vaultなどの外部シークレット管理システムから、メモリ上でのみマウントする手法。これが最も堅牢だ。
4. 未来への備え：耐量子暗号への移行
将来的な脅威として、量子コンピュータによるRSA/AES暗号の解読リスク（Shorのアルゴリズム等）がある。現在、KMSで利用しているAES-256も、長期的には脅威にさらされる可能性がある。
我々のようなセキュリティエンジニアは、今すぐ「暗号化アルゴリズムのアジリティ」を確保しておくべきだ。KMSのプロバイダーが耐量子アルゴリズム（PQC: Post-Quantum Cryptography）に対応した際、インフラコードを大きく書き換えることなく、プロバイダー設定のスイッチ一つで移行できるような疎結合なアーキテクチャ設計を推奨する。
最後に：監査官としてのアドバイス
「設定したから終わり」ではない。EncryptionConfiguration が正しく機能しているかを確認するには、実際にetcdのデータファイルを直接覗く必要がある。
# etcdctlを使って暗号化を確認するコマンド例
# k8s.io/kubernetes/pkg/master/reconcilers/lease.go などの構成に基づき、直接etcdをクエリする
ETCDCTL_API=3 etcdctl \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
get /registry/secrets/default/my-secret | hexdump -C出力結果に k8s:enc:aescbc:v1 のようなプレフィックスが見えれば、あなたのクラスタは攻撃者にとって「解読不可能」な要塞の一部になったと言える。
セキュリティは、ツールを導入することではない。攻撃者の思考を先回りし、彼らの「侵入コスト」を、彼らが割くべき「リソース」よりも高く設定し続ける、終わりのないチェスゲームなのだ。次は、この暗号化設定を破ろうとする内部脅威について深掘りしようか。
コメント