GKEの通信とファイアウォール

案件でGKE周りの通信とFirewall Ruleについて整理する機会があったので、備忘録としてまとめます。

概要

やりたいこと

• GKE上にPodを立て、GCLB経由でインターネット越しにアクセスさせるごくごくシンプルな内容です。
• ユーザからGCLBまではHTTPS、GCLBからPodまではHTTPで通信します。GCLBからPod間の通信にはNEG（Network Endpoint Group） を利用します。NEGについては後述します。
• コントロールプレーンへのアクセス方法はいくつかありますが、自身のローカル環境は固定IPじゃない中でインターネット越しにセキュアにアクセスさせるため、今回はDNSベースのアクセスを利用します。こちらも後述します。
• 本記事の内容を一枚絵にすると以下の通りです。
  

3種類の通信

• 本構成では通信を大きく3種類に分けられます。

  1. 業務通信（ユーザからPodまでのHTTP系通信およびGCLBからのヘルスチェック）
  2. GKE管理系通信
  3. コントロールプレーン通信（kubectlコマンドを実行するための通信）

• 以降では各通信ごとに整理します。

業務通信

構成

• AWSと異なり、Google Cloudの外部GCLBのフロントエンドはVPC内には存在しません。一方でバックエンドは、ユーザVPC内に作成したProxy専用サブネットに配置されます。
• GCLBからクラスタ内PodへのアクセスにはNEGを利用します。簡単に言うと、NEGはGKEクラスタ内のPodをGoogle Cloud上で直接ターゲットとして扱えるようにする技術です。通常、GCLBからワーカーノードまでの通信はGoogle Cloudの世界で管理されますが、Podまでの通信はKubernetesの世界になります。NEGを使うことで、GCLBからPodまでの通信を直接ターゲット指定できるようになります。なお、NEGはゾーン単位で作成されます。

通信

• ユーザ→GCLB間：HTTPS:443
• GCLB→Pod間：NEGによりHTTP:3000
• GCLBのヘルスチェックは以下のIPレンジから行われます：
  • 35.191.0.0/16
  • 130.211.0.0/22

ファイアウォール

• 業務通信では、プロキシ専用サブネットからのHTTP系通信とヘルスチェック通信をFirewall Ruleで許可する必要があります。Network Firewallはワーカーノードをターゲットとしたルールになります。Google CloudではネットワークTagを使って制御するのが一般的です。
  参考：Firewallルールの設定
• ユーザ→GCLB間のHTTPS通信はVPC外の通信のため、Firewall Ruleでの許可設定は不要です。
• GKEクラスタ内Pod間通信はKubernetesの世界で制御されます。この通信はGKE作成時にデフォルトでFirewallで許可されており、業務通信として追加で許可する必要はありません。Pod間の制御はNetworkPolicyなどで行えるみたいですが、本記事では割愛します。

GKE管理系通信

• GKE管理系通信はクラスタ作成時にFirewall Ruleが自動で設定されるため、自分で設定する必要はありません。
• 自動で許可される通信は主に以下の4種類です。
  参考：自動的に作成されるファイアウォール ルール

ルール	概要	許可/拒否	備考
all	Pod→ワーカノード間通信	許可	-
vms	ワーカーノード間通信	許可	-
inkubelet	Pod→kubelet通信	許可	クラスタ1.23.6以降
exkubelet	Pod以外からkubelet通信を拒否	拒否	クラスタ1.23.6以降

• ワーカノード→コントロールプレーン間通信はプライベートエンドポイントが使用されます。通信制御はGoogle Cloud側で管理されるため、ユーザ側で設定する必要はありません。

コントロールプレーン通信

• kubectlコマンドをコントロールプレーンに対して実行するには通信経路が必要です。
• DNSベースのアクセスを使うと、インターネット越しでもセキュアにkubectlを利用できます。
  • コントロールプレーンのパブリックエンドポイントを作成する必要はありません。
  • ユーザはGoogle管理のGKE Frontend Proxyを経由してkubectlを実行します。
  • IAMによるアクセス制御が行われるため、セキュアに通信できます。
  • ローカル端末やCloud Shellからkubectlを利用可能です。
    参考：新しいDNSベースのGKEコントロールプレーンアクセス

まとめ

• 個人的に気になるポイントはNEG周りのFirewall Ruleです。GCLB→Pod間通信を抽象化するのがNEGの目的なので、そうであればFirewallルールもPodに対して制御したほうがコンセプトに忠実です。ただ、実際はネットワークTagでワーカーノードに対して制御する必要があるため、このあたりは少し気になるところです。