【テクニカル・上級編】 Kubernetesのシークレット管理と外部鍵管理サービス(KMS)の統合 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

Kubernetes Secretの「幻想」を破壊する：etcd平文保存のリスクとKMS統合による鉄壁のアーキテクチャ

Kubernetes（K8s）のインフラを構築する際、多くのエンジニアが「Secretオブジェクトを使っているから安全だ」という甘美な幻想に浸っている。だが、現実は冷酷だ。デフォルトの構成において、Secretは単にBase64エンコードされた文字列としてetcdに保存されているに過ぎない。

これは暗号化ではない。ただの「難読化」であり、攻撃者にとってのハードルは無に等しい。一度でもetcdのバックアップファイルや、etcdへの直接アクセス権を奪取すれば、そこにある機密情報は全て「鍵なし」で手に入る。

今回は、セキュリティアーキテクトとして、この脆弱な現状を打破し、KMS（Key Management Service）を統合した「Encryption at Rest（保存時暗号化）」の深淵を紐解いていく。

1. 脆弱性の根本：なぜ「デフォルト」は敗北するのか

etcdは分散キーバリューストアであり、K8sの「脳」だ。ここに保存されるデータは、基本的に平文のままディスクに書き込まれる。

攻撃者がetcdのデータディレクトリへ物理的または論理的にアクセスできた場合、あるいはcluster-admin権限を持つアカウントを侵害された場合、彼らは以下のようなコマンドで全てをさらう。

# etcdへの直接クエリによるシークレットの抽出例
ETCDCTL_API=3 etcdctl get /registry/secrets/ --prefix --keys-only

この瞬間、APIトークン、データベースのパスワード、TLS秘密鍵などが、何の復号プロセスも経ることなく攻撃者の手元に渡る。我々レッドチームがペネトレーションテストを行う際、クライアントのK8s環境でこの「平文保存」設定を見つけるのは、宝探しで最初に見つける「チュートリアルレベルの報酬」に過ぎない。

2. KMSを用いた防御層の設計：Encryption at Restの真髄

これを防ぐための唯一の防衛策が、EncryptionConfigurationによる保存時暗号化だ。ここで重要なのは、鍵の管理をK8sの外部（クラウドプロバイダーのKMSなど）に委ねることである。

KMS統合のアーキテクチャ

KMSを統合すると、プロセスは以下のようになる。
1. APIサーバーがSecretを受け取る。
2. APIサーバーは、KMSプロバイダー（KMSプラグイン）を呼び出す。
3. KMS側で生成されたデータ暗号化鍵（DEK）を使用して、Secretを暗号化する。
4. 暗号化されたBlobがetcdに保存される。

これにより、たとえetcdのダンプファイルを盗まれても、KMSへのアクセス権限がない限り、そのデータはただのバイナリゴミに過ぎない。

3. 実装のステップ：EncryptionConfigurationの定義

以下に、AWS KMSを想定した設定ファイルのサンプルを示す。このファイルはK8sのAPIサーバー起動時（--encryption-provider-config）に読み込ませる必要がある。

# encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      # KMSプラグインを介した暗号化設定
      - kms:
          name: aws-kms-provider
          endpoint: unix:///var/run/kmsplugin/socket.sock # KMSプラグインのソケット
          cachesize: 100
          timeout: 3s
      # 復号時に古い鍵も使用できるようにするためのフォールバック設定
      - identity: {}

注意すべき「プロトコルの罠」

KMSプラグインとAPIサーバー間の通信はgRPCで行われる。ここで疎かになりがちなのが、Unix Domain Socketのパーミッション設定だ。もし、ノード上のコンテナがこのソケットにアクセスできるような設定ミスがあれば、攻撃者はKMSを「オラクル」として利用し、任意の暗号文を復号させる中間者攻撃を仕掛ける可能性がある。

4. セキュリティアーキテクトへの問い：耐量子時代への備え

現在、我々が依存しているAES-256などの対称鍵暗号は、将来的な耐量子計算機（QCR）の登場によって崩壊する可能性がある。

KMSを選定する際、単に「クラウドだから安心」と考えるのは危うい。将来的な「Harvest Now, Decrypt Later（今盗んで、後で解読する）」攻撃を考慮し、KMSが提供する鍵のローテーションポリシー、および将来的な耐量子暗号（PQC）への移行パスが確保されているサービスを選択することが、チーフホワイトハッカーとしての最低限の責務だ。

5. 監査の観点：ログの「不可視化」を防ぐ

最後に、どれだけ堅牢な暗号化を施しても、監査ログがなければ攻撃の予兆を検知できない。KMSの利用状況は、クラウド側の監査ログ（CloudTrail等）とAPIサーバーの監査ログの両方で相関分析を行う必要がある。

KMSへのDecryptリクエストが異常な頻度で発生していないか？
許可されていないIPレンジからの復号要求はないか？

これらは単なる設定の問題ではなく、監視とアラート（ガードレイル）の設計の問題である。

まとめ

KubernetesのSecret管理は、単なる機能の実装ではない。それは「信頼の境界線」をどこに引くかという、政治的かつ技術的な決断だ。etcdという平文の海に、KMSという堅牢な要塞を構築し、鍵そのもののライフサイクルを厳格に管理する。

サイバー攻撃者は常に「最も弱いリンク」を狙う。あなたのクラスタのリンクは、暗号化されていないetcdではないだろうか？今すぐその設定を確認し、アーキテクチャをアップデートすることを強く推奨する。