自動的に作成されるファイアウォール ルール

このページでは、Google Kubernetes Engine（GKE）が Google Cloud で自動的に作成する上り（内向き）許可の 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 アドレスに送信できるようにします。たとえば、このルールで許可されるトラフィックには次のものがあります。

  • kubelet などのシステム デーモンから、クラスタのノードと Pod の IP アドレス宛先に送信されるパケット。
  • hostNetwork:true の Pod で実行されているソフトウェアから、クラスタのノードと Pod の IP アドレスの宛先に送信されるパケット。
 ノード IP アドレス範囲、またはこのノード IP アドレス範囲のスーパーセット。
  • 自動モードの VPC ネットワークの場合、GKE は 10.128.0.0/9 CIDR を使用します。これは、この範囲には、自動的に作成されたサブネットワークの、現在と将来のすべてのサブネット プライマリ IPv4 アドレス範囲が含まれるためです。
  • カスタムモードの VPC ネットワークの場合、GKE はクラスタのサブネットのプライマリ IPv4 アドレス範囲を使用します。
クラスタのサブネットのプライマリ IPv4 範囲を拡張する場合、GKE は、このファイアウォール ルールのソース IPv4 範囲を更新しません。クラスタのサブネットのプライマリ IPv4 範囲を拡張する場合は、必要な上り（内向き）ファイアウォール ルールを手動で作成する必要があります。		 ノードタグ 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 間のトラフィックを許可します。

subnetIpv6CidrBlock に同じ IP アドレス範囲が割り振られています。

 ノードタグ 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 に設定されている場合に、外部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 LoadBalancer の仮想 IP アドレス TCP: 10256
k8s-[loadbalancer-hash]-http-hc externalTrafficPolicy が Local に設定されている場合、外部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 ノードタグ spec.healthCheckNodePort によって定義される TCP ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。

詳細については、ヘルスチェック ポートをご覧ください。
k8s-[cluster-id]-node-hc externalTrafficPolicy が Cluster に設定されている場合、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 ノードタグ TCP: 10256
[loadbalancer-hash]-hc externalTrafficPolicy が Local に設定されている場合、内部パススルー ネットワーク ロードバランサ サービスのヘルスチェックを許可します。
  • 130.211.0.0/22
  • 35.191.0.0/16
  • 209.85.152.0/22
  • 209.85.204.0/22
 ノードタグ spec.healthCheckNodePort によって定義される TCP ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。

詳細については、ヘルスチェック ポートをご覧ください。
k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] 次のいずれかが有効になっている場合、上り（内向き）トラフィックが Service に到達することを許可します。
  • GKE のサブセット化
  • バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ。
    		•  ソースは 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 のヘルスチェックを許可します。
  • GKE のサブセット化
  • バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ。
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 LoadBalancer の仮想 IP アドレス spec.healthCheckNodePort によって定義される TCP ポート。spec.healthCheckNodePort を省略した場合のデフォルトは TCP ポート番号 10256 です。

    詳細については、ヘルスチェック ポートをご覧ください。
    k8s2-[cluster-id]-l4-shared-hc-fw externalTrafficPolicy が Cluster に設定され、次のいずれかが有効になっている場合、Service のヘルスチェックを許可します。
  • GKE のサブセット化
  • バックエンド サービスベースの外部パススルー ネットワーク ロードバランサ。
    		•
    • 130.211.0.0/22
    • 35.191.0.0/16
    • 209.85.152.0/22
    • 209.85.204.0/22
    		 ノードタグ 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 ファイアウォール ルールを作成します。

    名前 目的 ソース ターゲット（宛先を定義） プロトコルとポート
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    ネットワーク エンドポイント グループ（NEG）のヘルスチェックを許可します。

    このルールは、最初の Gateway リソースの作成時に Gateway コントローラによって作成されます。Gateway リソースがさらに作成されたときに、Gateway コントローラがこのルールを更新する可能性があります。

    		 ノードタグ TCP: すべてのコンテナ ターゲット ポート（NEG の場合）

    GKE Ingress のファイアウォール ルール

    GKE は、Ingress リソースの作成時に、次の上り（内向き）ファイアウォール ルールを作成します。

    名前 目的 ソース ターゲット（宛先を定義） プロトコルとポート
    k8s-fw-l7-[random-hash]

    NodePort Service サービスまたはネットワーク エンドポイント グループ（NEG）のヘルスチェックを許可します。

    このルールは、最初の Ingress リソースが作成されたときに Ingress コントローラによって作成されます。このルールは、さらに Ingress リソースが作成されたときに Ingress コントローラによって更新される可能性があります。

    		 GKE v1.17.13-gke.2600 以降の場合:
    • 130.211.0.0/22
    • 35.191.0.0/16
    • ユーザー定義のプロキシ専用サブネットの範囲（内部アプリケーション ロードバランサの場合）
    		 ノードタグ 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 ファイアウォール ルールで使用されるものと同じターゲットタグに設定します。

    次のステップ