このページでは、Google Kubernetes Engine（GKE）が Google Cloud で自動的に作成する上り（内向き）許可の VPC ファイアウォール ルールについて説明します。
適用されるファイアウォールと下り（外向き）ファイアウォール
GKE によって作成された上り（内向き）許可ファイアウォール ルールは、クラスタ内のノードに適用される唯一のファイアウォール ルールではありません。上り（内向き）と下り（外向き）に適用されるファイアウォール ルールの完全なセットは、階層型ファイアウォール ポリシー、グローバル ネットワーク ファイアウォール ポリシー、リージョン ネットワーク ファイアウォール ポリシー、その他の VPC ファイアウォール ルールのルールから定義されます。
組織のネットワーク管理者とセキュリティ エンジニアと協力して、クラスタ、ワークロード、サービスの構成を計画、設計します。また、ファイアウォールのポリシーとルールの評価順序を理解して、優先されるファイアウォール ルールを把握します。
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 の作成時に、次の上り（内向き）ファイアウォール ルールを作成します。
| 名前 | 目的 | 送信元 | ターゲット（宛先を定義） | プロトコルとポート |
|---|---|---|---|---|
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 ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。
詳細については、ヘルスチェック ポートをご覧ください。 |
k8s-[cluster-id]-node-hc |
externalTrafficPolicy が Cluster に設定されている場合、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
ノードタグ | TCP: 10256 |
[loadbalancer-hash]-hc |
externalTrafficPolicy が Local に設定されている場合に、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。 |
|
ノードタグ | spec.healthCheckNodePort によって定義される TCP ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。
詳細については、ヘルスチェック ポートをご覧ください。 |
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 ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。
詳細については、ヘルスチェック ポートをご覧ください。 |
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
共有 VPC にあるクラスタが共有 VPC ネットワークを使用している場合、Ingress コントローラはホスト プロジェクトでサービス プロジェクトの 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 を使用するプロジェクトにファイアウォール ルールを作成する方法について学習する。