【ITニュース解説】Separate etcd peer and client trust before scaling the cluster

etcdは、Kubernetesのような大規模なITシステムを支える、非常に重要な「データの保存庫」であり「司令塔」の役割を果たす。例えるなら、システム全体の設計図や設定情報、現在の状態といった、なくてはならない重要なデータを確実に保存し、必要に応じて他の部分に共有する中枢神経のような存在だ。etcdがなければ、システム全体が正常に機能しなくなるため、そのセキュリティは極めて重要である。

このetcdには、大きく分けて二種類の通信があることを理解することが、セキュリティを考える上で最初のステップとなる。一つは「ピア」と呼ばれる、複数のetcdインスタンス同士が互いに情報を同期し、全体で一貫した状態を保つための内部的な通信だ。etcdは通常、可用性を高めるために複数のインスタンス（メンバー）で構成されるため、これらのメンバー間の連携が不可欠である。もう一つは「クライアント」と呼ばれる、Kubernetesのコンポーネントや運用ツールといった外部のアプリケーションがetcdに情報を読み書きするための通信である。

これらの二つの通信は、それぞれ目的も性質も異なるため、セキュリティの確保方法も区別して考える必要がある。記事では、ピアとクライアントの「信頼関係」を明確に分離することの重要性を強調している。et具体的には、通信の安全性を確保するために「TLS（Transport Layer Security）」という技術が使われる。TLSは通信を暗号化するだけでなく、相手が本当に信頼できる相手であるかを確認するための「証明書」を利用した認証機能も提供する。この証明書を、ピア用とクライアント用で明確に分けるべきだという点がポイントだ。

もしピアとクライアントで同じ証明書を使い回してしまうと、セキュリティ上の大きなリスクとなる。例えば、クライアント向けの証明書が何らかの理由で漏洩したり、悪意のある攻撃者に悪用されたりした場合、その証明書を持った攻撃者がetcdクラスタの正規メンバーであるかのように振る舞い、システム全体を乗っ取ってしまう危険性があるからだ。このため、ピア用の証明書とクライアント用の証明書は、別々の「認証局（CA）」によって発行されるか、あるいは同じCAが発行する場合でも、証明書に記載される情報（例えば「SANs：Subject Alternative Names」と呼ばれる、その証明書がどの名前やIPアドレスに対して有効であるかを示す情報や、発行ポリシー）によって、その用途が明確に区別されるべきだ。ピア証明書にはetcdメンバーの到達可能な名前やIPアドレスを含める必要がある一方で、クライアント証明書は特定のアプリケーションやオペレーターの身元を示すものである。もし発行システムが両方の証明書を区別なく発行できると、意図しない形でピア証明書が発行され、悪用される可能性も生まれる。

また、etcdのピア間の通信をTLSで暗号化せず、「プレーンテキスト（平文）」で行う設定も可能だが、これは非常に危険である。設定が簡単になるという一時的なメリットと引き換えに、ピア間のネットワークがそのまま信頼できる境界の一部となってしまう。つまり、もしそのネットワークにアクセスできる人がいれば、誰でもetcdの通信内容を盗み見たり、偽の情報を送りつけたりして、クラスタの状態を自由に操作できてしまう可能性があるのだ。ネットワークを「セグメンテーション（分離）」していても、その前提が崩れると一瞬にして危険に晒される。常にピア間の通信もTLSで保護し、相互に認証するように設定し、その双方向性が正しく機能していることを検証すべきだ。

さらに、セキュリティを考える上で重要なのが「認証」と「承認」という二つの異なる概念の理解だ。「認証」とは「あなたが誰であるか」を確認するプロセスである。例えば、有効なクライアント証明書を提示することで、「私はこのKubernetesサービスです」とetcdに名乗るのが認証だ。一方、「承認」とは「あなたが何ができるか」を決定するプロセスである。etcdは、認証された「このKubernetesサービス」が、具体的にどの情報を読み取って良いのか、書き込んで良いのか、削除して良いのかを、別途定義されたルールに基づいて判断する。例えば、バックアップ用のツールはetcdの情報を読み取る権限だけあれば十分であり、決して情報を削除する権限を持つべきではない。もしバックアップツールに削除権限を与えてしまうと、誤操作や悪意ある攻撃によって重要なデータが失われる可能性がある。したがって、アプリケーションやサービスごとに異なるクライアント証明書を発行し、それぞれに必要最小限の適切な権限（承認）を与えることが不可欠だ。

etcdクラスタを構築し、稼働させた後も継続的な監査と管理が求められる。デプロイされたetcdの各メンバーが、設計通りの証明書設定になっているかを定期的に確認することが重要だ。例えば、クラスタ内のいずれか一つのメンバーだけが古い証明書を使っていたり、ピア認証が有効になっていなかったりすると、他のメンバーがどんなに正しく設定されていても、そこがクラスタ全体のセキュリティ上の弱点となってしまう。設定ミスがないかを確認するために、例えばクライアント証明書を使ってピア用のエンドポイントに接続を試みたり、逆にピア用の証明書を使って通常のクライアント用のエンドポイントに接続を試みたりするテストも有効である。これらは通常、失敗するべきであり、もし成功してしまう場合は設定に根本的な問題がある。

また、証明書には有効期限があるため、いずれ更新（「ローテーション」）が必要になる。このローテーションも、事前にしっかりと計画しておくことが極めて重要だ。ピア証明書とクライアント証明書では、更新のタイミングや手順が異なる場合があるため、それぞれに合わせた計画が必要となる。安全に更新を行うためには、古い証明書と新しい証明書が一時的に共存する期間を設けたり、万が一問題が発生した場合に元の状態に戻せる手順（ロールバックパス）を考慮したりする必要がある。現在どの証明書が使われており、いつ古いものが使えなくなるのかを常に記録し、適切に管理していくことが、etcdを安全かつ安定して運用するための鍵となる。

etcdは、これらのセキュリティ経路を分離するための豊富な設定オプションを提供している。これらの設定を適切に利用し、証明書の発行、設定、ネットワークアクセス、そして承認といった運用全体にわたって一貫したセキュリティポリシーを適用することが、システムの堅牢性を高め、大規模な環境での安定した運用を実現するために不可欠である。