【テクニカル・上級編】 etcdの保存時暗号化(Encryption at Rest)とKMS統合 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

etcdの「Encryption at Rest」は、なぜデフォルトで有効になっていないのか？

Kubernetesの心臓部である etcd。ここにはクラスタの全状態、そして最も重要な Secret オブジェクトが平文で保存されている。インフラエンジニアの多くが「クラウドプロバイダーのディスク暗号化（AES-256）」を免罪符にしているが、それは攻撃者がディスクを物理的に持ち出した場合の防衛策に過ぎない。

メモリダンプや etcdctl によるスナップショットの流出、あるいはコンテナ内からの不適切な権限昇格が発生した際、ディスクレベルの暗号化は無力だ。本稿では、etcd の保存時暗号化（Encryption at Rest）を外部KMSと統合し、現代の脅威モデルに対抗するための「防衛の深度」を解説する。

—

攻撃者の視点：どこが狙われているのか

攻撃者が etcd を狙う際、彼らは単にデータを盗むだけではない。彼らは「シード」を探している。
例えば、誤って ConfigMap に埋め込まれたAPIトークンや、Secret に格納されたDBの接続文字列。これらは攻撃者がネットワークの横展開（Lateral Movement）を行うための踏み台となる。

特に、etcd は通信プロトコルとして gRPC を採用しているが、この内部でやり取りされるデータ自体が暗号化されていても、鍵管理をノード内部（ローカルファイル）で行っていれば、それは「鍵付きの金庫を、鍵を挿したまま放置している」のと同じだ。我々アーキテクトが目指すべきは、鍵のライフサイクルをKubernetesの外側に追い出すことである。

—

KMS統合による保護の実装

EncryptionConfiguration を作成し、kube-apiserver に読み込ませることで、etcd に書き込まれる直前にデータが暗号化される。ここでは aescbc や kms プロバイダーを用いるが、本番環境では必ず外部KMS（AWS KMS等）を利用すべきだ。

以下は、AWS KMSを用いた設定例である。

# /etc/kubernetes/kms-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
    - secrets
    providers:
    - kms:
        # AWS KMSのARNを指定。IAMロールによる認証が推奨される
        name: aws-kms-provider
        key: arn:aws:kms:ap-northeast-1:123456789012:key/uuid-xxxx-xxxx
        # キャッシュの有効期限。短すぎるとAPIサーバーの負荷増大、長すぎると鍵無効化への反映遅延
        cachesize: 100
        # 暗号化通信のタイムアウト（ミリ秒）
        timeout: 3s
    # デフォルトの暗号化方式（KMS失敗時のフェイルセーフ設定など）
    - identity: {}

現場で陥る「罠」

この設定を行った後、重要なのが 「既存データの再暗号化」 だ。この設定を追加しても、既に etcd に存在する古い Secret は暗号化されない。

# 既存のすべてのシークレットを強制的に書き換え、暗号化を適用する
kubectl get secrets --all-namespaces -o json | kubectl replace -f -

—

防衛の深度：耐量子暗号とメモリ保護の未来

我々が今見据えるべきは、古典的な暗号アルゴリズム（RSA/AES）が量子コンピューターによって解読される未来だ。etcd の暗号化において、現在使用している aescbc や aesgcm は将来的に脅威にさらされる可能性がある。

現時点でのアーキテクトとしての防衛策は以下の通りだ。

1. 鍵の自動ローテーション: KMS側で鍵を90日単位でローテーションし、旧鍵での復号を制限する。
2. メモリ内保護: kube-apiserver のメモリダンプを防ぐため、ホストOSレベルで kernel.yama.ptrace_scope を適切に設定し、不要なプロセスのメモリ読み取りを制限する。
3. ガードレイル: 生成AIを組み込んだCI/CDパイプライン上で、Secret が平文でコードリポジトリにコミットされないよう、静的解析ツール（gitleaks 等）を pre-commit フックに組み込む。

—

結論：セキュリティは「設定」ではなく「運用」である

KMS統合はあくまで、攻撃コストを劇的に引き上げるための手段に過ぎない。真の要塞化とは、etcd の設定を完璧にすることに加え、audit policy を強化し、誰がいつ Secret にアクセスしようとしたかをSIEMでリアルタイムに監視し続けることにある。

「暗号化したから安全だ」という思考停止こそが、脆弱性の温床となる。我々プロフェッショナルは、暗号化というレイヤーを「信頼の境界線」として定義し、その内側と外側で常にゼロトラストな通信を維持しなければならない。

次回のトピックでは、etcd と kube-apiserver 間の相互TLS（mTLS）の検証と、証明書が漏洩した際の即時無効化メカニズムについて掘り下げる予定だ。現場の泥臭いインシデント事例を交えながら、より深いレイヤーへと潜っていこう。