こんにちは！インフラやセキュリティの世界へようこそ。
Kubernetes（クバネティス）を使ったシステム開発やインフラ運用、毎日本当にお疲れ様です。
今回は、Kubernetesの心臓部であり、すべての秘密が集まる場所である 「etcd（エトシード）」 のセキュリティ、特に 「保存時暗号化（Encryption at Rest）」 と 「外部KMS（Key Management Service）統合」 について、一緒に一歩ずつ紐解いていきましょう。
小難しいセキュリティ用語が出てくると、思わずブラウザを閉じたくなる気持ち、痛いほどよく分かります。でも大丈夫です。身近な防犯の仕組みに例えながら、初心者の方にも分かりやすく、かつ現場で即戦力になる知識をお伝えしていきますね。
—
1. なぜ「etcdの暗号化」が必要なの？（身近な防犯に例えてみましょう）
皆さんは、自宅の合鍵をどこに置いていますか？まさか、玄関の植木鉢の下に「ご自由にお取りください」と言わばかりに置いていたりしませんよね。もしそんなことをしたら、泥棒に入ってくださいと言っているようなものです。
Kubernetesの世界でも、これと全く同じことが起き得ます。
Kubernetesでは、パスワードやAPIトークン、データベースの接続情報といった機密データを Secret というリソースで管理します。アプリケーションはこの Secret を読み込んで動くため、非常に重要なデータが詰まっています。
この Secret をはじめとするすべてのクラスターステータス情報を保存しているデータベースが、etcd です。
攻撃者はどうやって狙ってくる？
もし、何らかの脆弱性や設定ミスをつかれて、攻撃者に Kubernetes のノードに侵入されたり、バックアップファイルが保存されているストレージ（S3バケットなど）を丸ごと盗み見られたりしたとしましょう。
もし、etcdの中身が「すっぴん（平文）」のまま保存されていたらどうなるでしょうか？
攻撃者は、盗んだファイルをテキストエディタで開くだけで、あなたのシステムのパスワードやAPIキーをすべて丸裸にして手に入れてしまいます。これは、玄関の鍵を開けっぱなしにして、リビングの真ん中に宝箱を置いておくようなものです。
だからこそ、「たとえデータベースのファイル自体が盗まれても、中身が金庫に入っていて開けられない状態」 にしておく必要があります。これが、今回学ぶ Encryption at Rest（保存時暗号化） なんです。
—
2. etcdの暗号化の仕組みと、KMS（鍵管理サービス）の役割
「じゃあ、暗号化のパスワード（暗号鍵）をetcdの近くにメモしておけばいいや！」……と思ってしまったそこのあなた、それは泥棒の家の前に「金庫の鍵はこちらです」と看板を立てるようなものです。暗号鍵は、データ本体とは別の安全な場所で管理しなければ意味がありません。
ここで登場するのが KMS（Key Management Service：鍵管理サービス） です。
AWSなら AWS KMS、GCPなら Cloud KMS と呼ばれる、暗号の鍵専門の「超頑丈な金庫番」がクラウド各社に用意されています。
データの守られ方の流れ
1. あなたが kubectl create secret generic で機密データを登録します。
2. Kubernetesはこのデータをetcdに書き込もうとしますが、その直前に「EncryptionConfiguration」というルールに従って、データを暗号化します。
3. この時、暗号化に使う「鍵」そのものを自分で管理するのではなく、外部の KMS に「暗号化するから鍵を貸して！」と頼みます。
4. KMSから受け取った鍵でデータをガチガチに暗号化し、暗号化された状態でetcdに保存します。
これなら、万が一etcdのファイルが盗まれても、鍵を持っているKMSにアクセスされない限り、中身を解読することは絶対にできません。
—
3. 実践！EncryptionConfigurationの設定ファイルを書く
それでは、実際に Kubernetes（kube-apiserver）に対して「etcdに保存するデータを暗号化してね」と指示するための設定ファイルを見ていきましょう。
実務では、以下のような YAML 形式の EncryptionConfiguration ファイルを作成し、コントロールプレーンのマスターノードに配置します。
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets # 暗号化の対象とするリソース（今回はSecretを指定）
providers:
- identity: {} # まず最初に、何も暗号化しない「平文」の読み込みを許可（過去データ救済のため）
- aescbc:
keys:
- name: key1
# 32バイトのランダムな文字列をbase64エンコードしたものを指定します
# ※実運用では必ずopenssl等で生成した強固な値を使いましょう！
secret: c2VjcmV0LWtleS1mb3ItZXRjZC1lbmNyeXB0aW9uLWV4YW1wbGU=
- resources:
- configmaps # 必要に応じてConfigMapなども対象にできます
providers:
- identity: {}設定のポイント（現場の泥臭い注意点）
identity: {}を先頭に書く理由:
すでに平文で保存されている古い Secret がクラスタ内に残っている状態で、いきなり暗号化を厳格に強制すると、Kubernetesが「読めない！」とパニックを起こしてシステムが停止（ダウンタイム発生）します。そのため、最初は平文も読めるようにしつつ、新しく書き込むデータから暗号化するように、順番（プロバイダーのリスト順）に気を配るのがプロの技です。
- 鍵の管理:
上記のサンプルコードでは設定ファイル内に直接秘密鍵（secret）を書いていますが、これでは結局設定ファイルが盗まれたときに意味がありません。そのため、本番環境ではこの静的な鍵ではなく、次項で説明する 外部KMSプロバイダー と連携させます。
—
4. 発展：外部KMS（AWS KMSなど）と統合する
より強固なセキュリティを求める実務の現場では、先ほどの静的な鍵ではなく、AWS KMS や GCP KMS などの外部サービスと連携させます。
AWS KMS を使う場合の EncryptionConfiguration の設定例は以下のようになります。
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- kms:
name: myAwsKmsProvider
endpoint: unix:///var/run/kms-plugin.sock # KMSプラグインとの通信用ソケット
cachesize: 100
timeout: 3s
- identity: {} # フォールバック用ここで「KMSプラグイン」という裏方が登場します
Kubernetesの kube-apiserver は直接 AWS KMS と会話することができません。そのため、ノード上で KMSプラグイン（デーモンなど） という小さな通訳プログラムを動かし、kube-apiserver からの依頼を AWS KMS の言葉に翻訳してやり取りしてもらうアーキテクチャをとります。
1. kube-apiserver が KMSプラグインにデータを渡す
2. プラグインが AWS KMS のAPIを叩いて暗号化・復号を行う
この仕組みを構築することで、暗号鍵のローテーション（定期的な鍵の取り替え）やアクセス監査ログの取得などを、クラウド側の強固なガバナンス機能に丸投げして安全に運用できるようになります。
—
5. まとめ：一歩ずつ、確実に安全なインフラへ
今回は、etcdの保存時暗号化とKMS統合について、防犯の例えを交えながら解説しました。
- etcdの暗号化は、家の金庫のようなもの。平文のままにしておくのは、玄関の鍵を開けっ放しにするのと同じ。
- 暗号鍵は本体とは別の場所（KMS）で管理するのが鉄則。
- 移行時は、システムの停止（ダウンタイム）を防ぐために
identityプロバイダーを挟むなど、順序立った手順が重要。
セキュリティ対策は、一度にすべてを完璧にやろうとすると息切れしてしまいます。「まずは機密データがどこに保存されているかを知る」「そして、暗号化の機能を正しく設定する」。その一歩一歩の積み重ねが、あなたを信頼されるインフラエンジニア、そして堅牢なシステムを作り上げる守護者に育ててくれます。
焦らず、楽しみながら、安全なクラウド・インフラストラクチャを一緒に築いていきましょう！それではまた次回の記事でお会いしましょう。
コメント