このページでは、コントロール プレーンとノードがリクエストを認証する方法など、Google Kubernetes Engine（GKE）クラスタにおける信頼性について説明します。
クラスタ間の通信
クラスタには、Kubernetes のコンポーネント間で通信するための数多くの接続があります。
- コントロール プレーンからノード
コントロール プレーンはコンテナを管理するためにノードと通信します。コントロール プレーンがノードに
kubectl logsなどのリクエストを送信すると、そのリクエストは Konnectivity プロキシ トンネルを介して送信されます。コントロール プレーンによって送信されるリクエストは TLS で保護され、認証、整合性、暗号化が提供されます。ノードがコントロール プレーンにリクエストを送信すると（たとえば kubelet から API サーバー）、そのリクエストは相互 TLS を使用して認証され、暗号化されます。新しく作成されたクラスタおよび更新されたクラスタはすべて、コントロール プレーンとノード間の通信に TLS 1.3 を使用します。TLS 1.2 は、コントロール プレーンとノード間の通信に対応する最小バージョンです。
- ノード間
ノードは、Google Cloud 本番環境ネットワーク内での接続が認証され、暗号化される Compute Engine VM です。詳細については、転送データの暗号化に関するホワイトペーパーで VM 間の説明に関するセクションをご覧ください。
- Pod 間
Pod が別の Pod にリクエストを送信しても、そのトラフィックはデフォルトでは認証されません。GKE は、ネットワーク レイヤで異なるノードの Pod 間のトラフィックを暗号化します。同じノードの Pod 間のトラフィックは、デフォルトでは暗号化されません。ネットワーク レイヤの暗号化の詳細については、Google Cloud の仮想ネットワーク暗号化と認証をご覧ください。
Pod 間のトラフィックは NetworkPolicy で制限できます。Cloud Service Mesh などのサービス メッシュを使用すると、同じノード上のトラフィックを含むすべての Pod 間トラフィックを暗号化できます。また、別の方法でアプリケーション レイヤでの暗号化を行うことも可能です。
- etcd 間
etcd のインスタンスは、状態を最新に保つために別の etcd のインスタンスと通信することがあります。etcd のインスタンスが別のインスタンスにリクエストを送信すると、そのリクエストは相互 TLS を使用して認証され、暗号化されます。トラフィックが、ファイアウォールで保護された GKE 所有のネットワークを離れることはありません。
- コントロール プレーンから etcd
この通信は相互 TLS で暗号化されます。
ルート オブ トラスト
GKE の構成は次のとおりです。
- クラスタルート認証局（CA）は、API サーバーと kubelet のクライアント証明書を検証するために使用されます。つまり、コントロール プレーンとノードは同じ信頼のルートになります。クラスタ ノードプール内の kubelet のすべてがこの CA から、
certificates.k8s.ioAPI を使用して証明書署名リクエストを送信することにより証明書をリクエストできます。クラスタルート CA の存続期間で説明されているように、ルート CA の存続期間は限られています。 - 別のクラスタ毎の etcd CA が、etcd の証明書を検証するために使用されます。
API サーバーと kubelet
API サーバーと kubelet は、信頼に関してクラスタルート CA に依存しています。GKE では、コントロール プレーンの API 証明書がクラスタルート CA によって署名されます。各クラスタがそれぞれの CA を実行するため、あるクラスタの CA の信頼が損なわれても、他のクラスタ CA は影響を受けません。
内部サービスが管理するこの CA のルートキーは、エクスポートできません。このサービスが証明書署名リクエストを、各 GKE クラスタの kubelet からの同リクエストも含めて受け入れます。クラスタ内の API サーバーが信頼を損なっても、CA は信頼を損なわないため、他のクラスタは影響を受けません。
クラスタ内の各ノードには共有シークレットが作成時に挿入されるので、それを使用して証明書署名リクエストをクラスタルート CA に送信して kubelet クライアント証明書を取得できます。そしてこれらの証明書は、kubelet がそのリクエストを API サーバーに対して認証するために使用します。この共有シークレットには、シールドされた GKE ノードまたはGKE 用 Workload Identity 連携を有効にしない限り、ノード上の Pod から到達可能です。
クラスタルート CA の存続期間
クラスタルート CA の存続期間は限られているので、その後は期限切れの CA によって署名された証明書がすべて無効になります。認証情報の存続期間を確認するの手順に沿って、クラスタの CA のおおよその存続期限を確認します。
既存のルート CA が期限切れになる前に、認証情報を手動でローテーションする必要があります。CA が期限切れになり、認証情報をローテーションしないと、クラスタが復元不能な状態になる可能性があります。GKE には、復元できないクラスタを試して防ぐための次のメカニズムがあります。
- クラスタが CA の期限切れの 7 日前に
DEGRADED状態になる GKE は、CA の有効期限が切れる 30 日前に認証情報の自動ローテーションを試みます。この自動ローテーションでは、メンテナンスの時間枠は無視され、GKE が新しい認証情報を使用するノードを再作成すると、停止が発生する可能性があります。ローカル環境の kubectl などの外部クライアントは、新しい認証情報を使用するように更新するまで機能しません。
ローテーションを行う方法については、クラスタ認証情報をローテーションするをご覧ください。
etcd
etcd は GKE における信頼に関して、別個のクラスタごとの etcd CA に依存しています。
etcd CA のルートキーは、コントロール プレーンが実行されている各仮想マシン（VM）のメタデータに配布されます。コントロール プレーン VM で実行されるコード、あるいはこれらの VM のメタデータの計算にアクセスするコードが、この CA として証明書に署名できます。クラスタ内の etcd の信頼が損なわれも、CA はクラスタ間で共有されないため、他のクラスタは影響を受けません。
etcd の証明書は 5 年間有効です。
証明書をローテーションする
クラスタの API サーバーと kubelet の証明書すべてをローテーションするには、認証情報のローテーションを行います。etcd 証明書のローテーションをトリガーする方法はありません。これは GKE で管理されています。