【入門編】 Kubernetesのetcd暗号化と通信のTLS化 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

Kubernetesの「心臓」を守り抜け！etcdの暗号化とTLS化で防ぐ、最悪のシナリオ

こんにちは。現場の最前線でセキュリティと向き合っているエンジニアです。

今日は、Kubernetes（K8s）という強力なシステムの「心臓部」である etcd についてお話しします。Kubernetesを家だと例えるなら、etcd はその家の「全財産のリストと金庫の鍵のありか」が書かれた、家の設計図そのものです。

もし泥棒（攻撃者）がこの設計図を盗み見ることができたらどうなるでしょうか？あなたの家がどこにあり、どの窓が空いていて、どんな宝物がどこにあるのか、すべて筒抜けになってしまいます。

今回は、そんな最悪の事態を防ぐための「金庫の強化（暗号化）」と「正しい来客の確認（TLS通信）」について、一緒に一歩ずつ学んでいきましょう！

—

1. etcdって何者？なぜ狙われるの？

etcd は、Kubernetesクラスタのすべての状態を保存している「分散キーバリューストア」です。

どのPodが動いているか？
どんなSecret（パスワードやAPIキー）が保存されているか？
誰がどんな権限を持っているか？

これらすべての情報が etcd に記録されています。攻撃者がクラスタに侵入した際、真っ先に狙うのはこの etcd です。ここを掌握すれば、クラスタ内のすべての権限を乗っ取ったも同然だからです。

2. 第一の守り：通信の「TLS化」で盗聴を防ぐ

まず大切なのは、API Serverと etcd の間の会話を「暗号化」することです。

もしこの通信が暗号化されていないと、ネットワークを盗聴している悪い人に、やり取りの内容をすべて読み取られてしまいます。例えるなら、「大切な手紙を、中身が透けて見える封筒に入れて送っている状態」です。

これを防ぐのがTLS（Transport Layer Security）です。お互いに「証明書」を見せ合って、正しい相手であることを確認し、会話の内容を暗号化します。

設定のポイント

etcd を起動する際の引数で、証明書（cert）と秘密鍵（key）、そして認証局（ca）を指定します。

# etcd起動時の設定例
etcd --name infra0 \
  --cert-file=/etc/kubernetes/pki/etcd/server.crt \    # サーバー証明書
  --key-file=/etc/kubernetes/pki/etcd/server.key \      # サーバー秘密鍵
  --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt \   # 信頼する認証局の証明書
  --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt \  # ピア（仲間）通信用証明書
  --peer-key-file=/etc/kubernetes/pki/etcd/peer.key \    # ピア通信用秘密鍵
  --client-cert-auth=true                                # クライアントに証明書を要求する設定

--client-cert-auth=true にすることで、「身分証（証明書）を見せない奴とは話をしない！」という厳しいガードが完成します。

—

3. 第二の守り：保存データの「暗号化」で中身を隠す

通信を暗号化しても、もし誰かがサーバー本体に物理的に侵入して etcd のディスクデータ（スナップショット）を盗み出したらどうでしょう？そのデータの中身を覗けば、保存されているSecret（パスワード等）がそのまま見えてしまいます。

これを防ぐのが「保存データの暗号化（Encryption at Rest）」です。

どうやって守るの？

Kubernetesでは、EncryptionConfiguration というリソースを使って、データを保存する際に「鍵」をかけて暗号化します。

以下は、EncryptionConfiguration のサンプルです。

# encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets # Secretを暗号化対象に指定
    providers:
      - aescbc: # AES-CBCアルゴリズムを使用して暗号化
          keys:
            - name: key1
              secret: <ここにbase64エンコードした32バイトの鍵を入力>
      - identity: {} # 暗号化できない場合はそのまま（デバッグ用などに使用）

この設定ファイルをAPI Serverの起動オプションで指定します。

# API Server起動時のオプション
--encryption-provider-config=/etc/kubernetes/pki/encryption-config.yaml

この設定を入れると、etcd の中身を泥棒が盗んでも、そこには「意味不明な暗号の羅列」しか残っていません。まさに、「金庫の中にさらに頑丈な箱を入れて、そこに鍵をかけた状態」です。

—

現場のエンジニアからのアドバイス

「セキュリティ設定は面倒くさい」と感じるかもしれません。でも、一度でも不正アクセスによる情報漏洩を経験すると、その苦労は「不可欠な備え」だったと痛感します。

1. 証明書の有効期限を忘れないこと：自動更新の仕組み（cert-manager など）を検討してください。
2. 鍵の管理を厳重に：encryption-config.yaml 内の鍵をGitにコミットして公開してしまうのは、金庫の鍵を玄関先に置くのと同じです。絶対にやめましょう。

セキュリティは「一度設定して終わり」のゴールがあるものではなく、日々の積み重ねです。今日、一つでも設定を見直せたあなたは、すでに立派なセキュリティエンジニアの第一歩を踏み出しています。

これからも一緒に、安全なシステム作りを楽しんでいきましょう！