クラスタの信頼性

このページでは、コントロール プレーンとノードがリクエストを認証する方法など、Google Kubernetes Engine(GKE)クラスタの信頼について説明します。

クラスタ間の通信

クラスタには、Kubernetes のコンポーネント間で通信するための数多くの接続があります。

コントロール プレーンからノード

コントロール プレーンはコンテナを管理するためにノードと通信します。コントロール プレーンがノード(たとえば、kubectl ログ)にリクエストを送信すると、そのリクエストは SSH トンネルで送信されます。このリクエストは TLS で保護され、認証、整合性、暗号化が実現されます。ノードがコントロール プレーン(たとえば kubelet から API サーバー)にリクエストを送信すると、そのリクエストは相互 TLS を使用して認証され、暗号化されます。

新しく作成されたクラスタおよび更新されたクラスタはすべて、コントロール プレーンとノード間の通信に TLS 1.3 を使用します。TLS 1.2 は、コントロール プレーンとノード間の通信に対応する最小バージョンです。

ノード間

ノードは、特定のワークロードの一環として別のノードと通信することがあります。ノードが別のノードにリクエストを送信すると、そのリクエストは認証されます。そして、その接続が Google により管理される物理的な境界を超える場合、リクエストは暗号化されます。Kubernetes コンポーネントはノード間通信を必要としません。詳しくは、転送データの暗号化のホワイトペーパーをご覧ください。

Pod 間

Pod は、特定のワークロードの一環として別の Pod と通信することがあります。Pod が別の Pod に送信したリクエストは、認証も暗号化もされません。Kubernetes コンポーネントでは、ポッド間の通信は必要ありません。Pod 間トラフィックはネットワーク ポリシーで制限でき、Istio などのサービス メッシュを使用して暗号化するか、アプリケーション レイヤ暗号化を実装できます。

etcd 間

etcd のインスタンスは、状態を最新に保つために別の etcd のインスタンスと通信することがあります。etcd のインスタンスが別のインスタンスにリクエストを送信すると、そのリクエストは相互 TLS を使用して認証され、暗号化されます。トラフィックが、ファイアウォールで保護された GKE 所有のネットワークを離れることはありません。

コントロール プレーンから etcd

この通信は全体がローカルホスト上で行われるので、認証も暗号化もされません。

信頼のルート

GKE の構成は次のとおりです。

  • クラスタルート認証局(CA)は、API サーバーと kubelet のクライアント証明書を検証するために使用されます。つまり、コントロール プレーンとノードは同じ信頼のルートになります。クラスタ ノードプール内の kubelet のすべてがこの CA から、certificates.k8s.io API を使用して証明書署名リクエストを送信することにより証明書をリクエストできます。
  • 別のクラスタ毎の etcd CA が、etcd の証明書を検証するために使用されます。

API サーバーと kubelet

API サーバーと kubelet は信頼に関してクラスタルート CA に依存しています。GKE では、コントロール プレーンの API 証明書がクラスタルート CA によって署名されます。各クラスタがそれぞれの CA を実行するため、あるクラスタの CA の信頼が損なわれても、他のクラスタ CA は影響を受けません。

Google 内部サービスが管理するこの CA のルートキーは、エクスポートできません。このサービスが証明書署名リクエストを、各 GKE クラスタの kubelet からの同リクエストも含めて受け入れます。クラスタ内の API サーバーが信頼を損なっても、CA は信頼を損なわないため、他のクラスタは影響を受けません。

クラスタ内の各ノードには共有シークレットが作成時に挿入されるので、それを使用して証明書署名リクエストをクラスタルート CA に送信して kubelet クライアント証明書を取得できます。そしてこれらの証明書は、kubelet がそのリクエストを API サーバーに対して認証するために使用します。この共有 Secret は、メタデータ隠 conが有効になっていなければ、Pod によって到達可能です。

API サーバーと kubelet の証明書は 5 年間有効ですが、認証情報のローテーションを行うことにより早く手動でローテーションできます。

etcd

GKE では、etcd は信頼に関してクラスタごとの etcd CA に依存しています。

etcd CA のルートキーは、コントロール プレーンが実行されている各仮想マシン(VM)のメタデータに配布されます。コントロール プレーン VM で実行されるコード、あるいはこれらの VM のメタデータの計算にアクセスするコードが、この CA として証明書に署名できます。クラスタ内の etcd の信頼が損なわれも、CA はクラスタ間で共有されないため、他のクラスタは影響を受けません。

etcd の証明書は 5 年間有効です。

証明書をローテーションする

クラスタの API サーバーと kubelet の証明書すべてをローテーションするには、認証情報のローテーションを行います。etcd 証明書のローテーションをトリガーする方法はありません。これは GKE で管理されています。

次のステップ