このページでは、Google Kubernetes Engine（GKE）がデフォルトで Google Cloudに自動的に作成する上り（内向き）許可の VPC ファイアウォール ルールについて説明します。
適用されるファイアウォールと下り（外向き）ファイアウォール
GKE は、Virtual Private Cloud（VPC）ファイアウォール ルールを使用して、Pod とノードへの受信トラフィックと送信トラフィックを制御します。デフォルトでは、GKE は特定のファイアウォール ルールを自動的に作成して管理し、ノードと Pod 間の通信や Kubernetes コントロール プレーンへのトラフィックなど、重要なトラフィックを許可します。GKE はデフォルトで LoadBalancer Service の上り（内向き）許可 VPC ファイアウォール ルールを自動的に作成しますが、この動作を無効にして、ファイアウォール ルールまたはポリシーを手動で管理したり、高度なファイアウォール機能を使用したりできます。
GKE によって作成された上り（内向き）許可ファイアウォール ルールは、クラスタ内のノードに適用される唯一のファイアウォール ルールではありません。上り（内向き）と下り（外向き）に適用されるファイアウォール ルールの完全なセットは、階層型ファイアウォール ポリシー、グローバル ネットワーク ファイアウォール ポリシー、リージョン ネットワーク ファイアウォール ポリシーのルール、その他の VPC ファイアウォール ルールから定義されます。
組織のネットワーク管理者およびセキュリティ エンジニアと協力して、クラスタ、ワークロード、Service の構成を計画、設計します。また、ファイアウォールのポリシーとルールの評価順序を理解し、優先されるファイアウォール ルールを把握します。
GKE は、暗黙的に許可された下り（外向き）優先度が最も低いファイアウォール ルールに依存しているため、上り（内向き）VPC ファイアウォール ルールのみを作成します。
クラスタの VPC ネットワークで下り（外向き）拒否ファイアウォール ルールを構成した場合は、ノード、Pod、クラスタのコントロール プレーン間の通信を許可するために、下り（外向き）許可ルールを作成する必要があります。たとえば、すべてのプロトコルとポート、すべての宛先 IP アドレスに下り（外向き）拒否ファイアウォール ルールを作成した場合は、GKE が自動的に作成する上り（内向き）ルールに加えて、下り（外向き）許可ファイアウォール ルールを作成する必要があります。コントロール プレーン エンドポイントへの接続では常に TCP 宛先ポート 443 が使用されますが、クラスタ内のノードと Pod 間の接続では任意のプロトコルと宛先ポートを使用できます。
次のツールは、どのファイアウォール ルールがトラフィックを許可または拒否するかを判断するうえで役立ちます。
ファイアウォール ルール
GKE ではデフォルトで、次のリソースを作成するときにファイアウォール ルールが自動的に作成されます。
- GKE クラスタ
- GKE Service
- GKE Gateway と HTTPRoute
- GKE Ingress
特に指定しない限り、自動的に作成されるファイアウォール ルールの優先度はすべて 1000 です。これは、ファイアウォール ルールのデフォルト値です。ファイアウォールの動作をより細かく制御する必要がある場合は、より高い優先度のファイアウォール ルールを作成できます。優先度が高いファイアウォール ルールは、自動作成されたファイアウォール ルールより先に適用されます。
GKE クラスタのファイアウォール ルール
GKE は、クラスタの作成時に、次の上り（内向き）ファイアウォール ルールを作成します。
| 名前 | 目的 | ソース | ターゲット（宛先を定義） | プロトコルとポート | 優先度 |
|---|---|---|---|---|---|
gke-[cluster-name]-[cluster-hash]-master |
コントロール プレーンのプライベート エンドポイント接続に VPC ネットワーク ピアリングを使用する Autopilot クラスタと Standard クラスタの場合。コントロール プレーンにクラスタノード上の kubelet と metrics-server へのアクセスを許可します。 | コントロール プレーンの IP アドレス範囲（/28） | ノードタグ | TCP: 443（metrics-server）と TCP: 10250（kubelet） | 1000 |
gke-[cluster-name]-[cluster-hash]-vms
|
Kubernetes ネットワーク モデルに必要なクラスタ内通信に使用されます。ノードで実行されているソフトウェアが、ノードの IP アドレスと一致する送信元のパケットをクラスタ内の宛先 Pod IP アドレスとノード IP アドレスに送信できるようにします。たとえば、このルールで許可されるトラフィックには次のものがあります。
|
ノード IP アドレス範囲、またはこのノード IP アドレス範囲のスーパーセット。
|
ノードタグ | TCP: 1～65535、UDP: 1～65535、ICMP | 1000 |
gke-[cluster-name]-[cluster-hash]-all |
Kubernetes ネットワーク モデルの要件に従って、クラスタ内のすべての Pod 間のトラフィックを許可します。 |
Pod の CIDR 連続していないマルチ Pod CIDR が有効になっているクラスタについては、クラスタで使用されるすべての Pod CIDR ブロック。 |
ノードタグ | TCP、UDP、SCTP、ICMP、ESP、AH | 1000 |
gke-[cluster-hash]-ipv6-all |
デュアル スタック ネットワーク クラスタの場合のみ。クラスタのノードと Pod 間のトラフィックを許可します。 |
|
ノードタグ | TCP、UDP、SCTP、IPv6 用 ICMP、ESP、AH | 1000 |
gke-[cluster-name]-[cluster-hash]-inkubelet |
バージョン 1.23.6 以降を実行している新しい GKE クラスタの内部 Pod CIDR とノード CIDR からポート 10255（Kubelet 読み取り専用ポート）へのアクセスを許可します。1.26.4-gke.500 以降のバージョンを実行しているクラスタは、代わりに Kubelet 認証ポート（10250）を使用します。10250 をブロックするファイアウォール ルールをクラスタに追加しないでください。 |
内部 Pod CIDR とノード CIDR。 |
ノードタグ | TCP: 10255 | 999 |
gke-[cluster-name]-[cluster-hash]-exkubelet |
バージョン 1.23.6 以降を実行している新しい GKE クラスタのポート 10255 への公開アクセスを拒否します。 |
0.0.0.0/0 |
ノードタグ | TCP: 10255 | 1000 |
GKE Service のファイアウォール ルール
GKE は、Service の作成時に、次の上り（内向き）ファイアウォール ルールを作成します。VPC ファイアウォール ルールの作成を管理することで、これらのファイアウォール ルールの一部が作成されないようにできます。
| 名前 | 目的 | ソース | ターゲット（宛先を定義） | プロトコルとポート |
|---|---|---|---|---|
k8s-fw-[loadbalancer-hash] |
上り（内向き）トラフィックが Service に到達することを許可します。 | ソースは spec.loadBalancerSourceRanges です。spec.loadBalancerSourceRanges を省略した場合のデフォルトは 0.0.0.0/0 です。詳しくは、ファイアウォール ルールと送信元 IP アドレスの許可リストをご覧ください。 |
LoadBalancer の仮想 IP アドレス | Service マニフェストで指定したポートに対する TCP と UDP。 |
k8s-[cluster-id]-node-http-hc |
externalTrafficPolicy が Cluster に設定されている場合に、外部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
LoadBalancer の仮想 IP アドレス | TCP: 10256 |
k8s-[loadbalancer-hash]-http-hc |
externalTrafficPolicy が Local に設定されている場合、外部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
ノードタグ | spec.healthCheckNodePort によって定義される TCP ポート。指定しない場合、Kubernetes コントロール プレーンがノードポートの範囲からヘルスチェック ポートを割り当てます。
詳細については、ヘルスチェック ポートをご覧ください。 |
k8s-[cluster-id]-node-hc |
externalTrafficPolicy が Cluster に設定されている場合、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
ノードタグ | TCP: 10256 |
[loadbalancer-hash]-hc |
externalTrafficPolicy が Local に設定されている場合、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
ノードタグ | spec.healthCheckNodePort によって定義される TCP ポート。指定しない場合、Kubernetes コントロール プレーンがノードポートの範囲からヘルスチェック ポートを割り当てます。
詳細については、ヘルスチェック ポートをご覧ください。 |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] |
次のいずれかが有効になっている場合、上り（内向き）トラフィックが Service に到達することを許可します。 |
ソースは spec.loadBalancerSourceRanges です。spec.loadBalancerSourceRanges を省略した場合のデフォルトは 0.0.0.0/0 です。詳しくは、ファイアウォール ルールと送信元 IP アドレスの許可リストをご覧ください。 |
LoadBalancer の仮想 IP アドレス | Service マニフェストで指定したポートに対する TCP と UDP。 |
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw |
externalTrafficPolicy が Local に設定され、次のいずれかが有効になっている場合、Service のヘルスチェックを許可します。 |
|
LoadBalancer の仮想 IP アドレス | spec.healthCheckNodePort によって定義される TCP ポート。指定しない場合、Kubernetes コントロール プレーンがノードポートの範囲からヘルスチェック ポートを割り当てます。
詳細については、ヘルスチェック ポートをご覧ください。 |
k8s2-[cluster-id]-l4-shared-hc-fw |
externalTrafficPolicy が Cluster に設定され、次のいずれかが有効になっている場合、Service のヘルスチェックを許可します。 |
|
ノードタグ | TCP: 10256 |
gke-[cluster-name]-[cluster-hash]-mcsd |
コントロール プレーンにマルチクラスタ サービスのクラスタノード上の kubelet と metrics-server へのアクセスを許可します。このルールの優先度は 900 です。 | ヘルスチェックの IP アドレス | ノードタグ | TCP、UDP、SCTP、ICMP、ESP、AH |
GKE Gateway のファイアウォール ルール
GKE は、Gateway リソースと HTTPRoute リソースを作成するときに、次の Gateway ファイアウォール ルールを作成します。
| 名前 | 目的 | ソース | ターゲット（宛先を定義） | プロトコルとポート |
|---|---|---|---|---|
|
ネットワーク エンドポイント グループ（NEG）のヘルスチェックを許可します。 このルールは、最初の Gateway リソースの作成時に Gateway コントローラによって作成されます。Gateway リソースがさらに作成されたときに、Gateway コントローラがこのルールを更新する可能性があります。 |
|
ノードタグ | TCP: すべてのコンテナ ターゲット ポート（NEG の場合） |
GKE Ingress のファイアウォール ルール
GKE は、Ingress リソースの作成時に、次の上り（内向き）ファイアウォール ルールを作成します。
| 名前 | 目的 | ソース | ターゲット（宛先を定義） | プロトコルとポート |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] |
このルールは、最初の Ingress リソースが作成されたときに Ingress コントローラによって作成されます。このルールは、さらに Ingress リソースが作成されたときに Ingress コントローラによって更新される可能性があります。 |
|
ノードタグ | TCP: 30000～32767、TCP:80（内部アプリケーション ロードバランサの場合）、TCP: すべてのコンテナ ターゲット ポート（NEG の場合） |
VPC ファイアウォール ルールの作成を管理する
デフォルトでは、GKE はすべての LoadBalancer Service に上り（内向き）許可 VPC ファイアウォール ルールを自動的に作成します。LoadBalancer Service のファイアウォール ルールを自分で管理する場合は、VPC ファイアウォール ルールの自動作成を無効にする必要があります。
LoadBalancer Service の VPC ファイアウォール ルールの自動作成を無効にするのは、次の場合に限られます。
ファイアウォール ルールを無効にする方法については、GKE LoadBalancer Service のユーザー管理ファイアウォール ルールをご覧ください。
共有 VPC
Ingress または LoadBalancer Service を使用していて、共有 VPC ネットワークを使用する共有 VPC にクラスタがある場合、サービス プロジェクトの GKE サービス アカウントは、ホスト プロジェクトで上り（内向き）許可ファイアウォール ルールを作成および更新できません。ファイアウォール リソースを作成および管理する権限は、サービス プロジェクトの GKE サービス アカウントに付与できます。詳しくは、共有 VPC をご覧ください。
拡張サブネットに必要なファイアウォール ルール
クラスタのサブネットのプライマリ IPv4 範囲を拡張しても、GKE は gke-[cluster-name]-[cluster-hash]-vms ファイアウォール ルールのソース範囲を自動的に更新しません。クラスタ内のノードは、サブネットのプライマリ IPv4 範囲の拡張部分から IPv4 アドレスを取得できるため、クラスタのノード間の通信を許可するファイアウォール ルールを手動で作成する必要があります。
作成する上り（内向き）ファイアウォール ルールでは、拡張されたプライマリ サブネット IPv4 ソース範囲からの TCP パケットと ICMP パケットを許可し、少なくともクラスタ内のすべてのノードに適用する必要があります。
クラスタのノードにのみ適用される上り（内向き）ファイアウォール ルールを作成するには、ファイアウォール ルールのターゲットを、クラスタで自動的に作成された gke-[cluster-name]-[cluster-hash]-vms ファイアウォール ルールで使用されるものと同じターゲットタグに設定します。
次のステップ
- GKE でのネットワーキングの概要を読む。
- アプリケーションのネットワーク ポリシーの構成について学習する。
- Google Cloudのその他の事前入力されるファイアウォール ルールについて学習する。
- 共有 VPC を使用するプロジェクトにファイアウォール ルールを作成する方法について学習する。