概要

このページでは、Google Distributed Cloud（GDC）エアギャップのプロジェクト ネットワーク ポリシーの概要について説明します。

プロジェクト ネットワーク ポリシーは、上り（内向き）ルールまたは下り（外向き）ルールを定義します。Kubernetes ネットワーク ポリシーとは異なり、ポリシーに指定できるポリシータイプは 1 つだけです。ポリシー内の各ルールは、Allow（デフォルト）または Deny のいずれかのアクションで構成できます。

プロジェクト内のトラフィックの場合、GDC は、事前定義されたプロジェクト ネットワーク ポリシー（デフォルトのプロジェクト内ポリシー）を各プロジェクトに適用します。

プロジェクト内のサービスとワークロードは、デフォルトで外部のサービスとワークロードから分離されています。ただし、異なるプロジェクトの名前空間に属し、同じ組織内にあるサービスとワークロードは、プロジェクト間のトラフィック ネットワーク ポリシーを適用することで相互に通信できます。

同様に、サービスとワークロードを別の組織のプロジェクト外の宛先に接続するには、明示的な承認が必要です。組織外のトラフィックを許可するには、データ引き出し防止を無効にする必要があります。

上り（内向き）と下り（外向き）のファイアウォール ルールは、プロジェクト ネットワーク ポリシーの主要なコンポーネントであり、ネットワークの内外で許可または拒否されるトラフィックの種類を決定します。GDC でプロジェクトの名前空間にファイアウォール ルールを設定するには、GDC コンソールを使用します。

セキュリティと接続

デフォルトでは、プロジェクト内のサービスとワークロードはそのプロジェクト内で分離されています。ネットワーク ポリシーを構成しないと、外部サービスやワークロードと通信できません。

GDC でプロジェクトの名前空間にネットワーク ポリシーを設定するには、ProjectNetworkPolicy リソースを使用します。このリソースを使用すると、プロジェクト内、プロジェクト間、外部 IP アドレスへの通信、外部 IP アドレスからの通信を許可するポリシーを定義できます。また、プロジェクトからワークロードを転送できるのは、プロジェクトのデータ引き出し防止を無効にする場合のみです。

GDC プロジェクト ネットワーク ポリシーは追加可能です。ワークロードに適用される違反措置は、そのワークロードに適用されるすべてのポリシーの結合に対するトラフィック フローの any 一致です。複数のポリシーが存在する場合、各ポリシーのルールが追加的に結合され、少なくとも 1 つのルールに一致するトラフィックが許可されます。

明示的な Deny ルールは、Allow ルールよりも完全に優先されます。トラフィック フローが Deny ルールと一致する場合、別のルールまたはデフォルトのプラットフォーム ポリシーで許可されている場合でも、そのトラフィック フローはドロップされます。

さらに、ワークロードを選択する単一のポリシーを適用すると、指定していないすべてのトラフィックが拒否されます（デフォルト拒否モード）。したがって、ワークロードをサブジェクトとして選択する 1 つ以上のポリシーを適用すると、明示的に許可された（明示的に拒否されていない）トラフィックのみが許可されます。

プロジェクトに割り当てた既知の IP アドレスを使用すると、組織からの送信トラフィックに対して送信元ネットワーク アドレス変換（NAT）が実行されます。

デフォルトのプロジェクト内ポリシー

プロジェクトを作成すると、GDC はプロジェクトの名前空間に base-policy-allow-intra-project-traffic という名前のグローバル プロジェクト ネットワーク ポリシーを自動的に作成します。このデフォルト ポリシーは次の処理を行います。

  • プロジェクト内のすべてのユーザー ワークロードをサブジェクトとして選択します。
  • 同じプロジェクト内のすべてのワークロードから、すべてのポートで、これらのワークロードへのインバウンド トラフィックを許可します。
  • 他のプロジェクトや組織外からのインバウンド トラフィックを許可しません。

GDC は、プロジェクトの作成時にデフォルト ポリシーを 1 回だけ作成します。ポリシーを変更または削除しても、GDC はポリシーを復元しません。GDC は、g-base-policy-allow-intra-project-traffic という名前のネットワーク ポリシーとして、プロジェクト内の各クラスタにポリシーを伝播します。ポリシーの status.zones[].replicaStatus.propagatedName フィールドにこの名前が表示されます。

デフォルト ポリシーを表示するには、次のコマンドを実行します。

kubectl --kubeconfig GLOBAL_API_SERVER get projectnetworkpolicy \
    base-policy-allow-intra-project-traffic -n PROJECT -o yaml

次のように置き換えます。

コマンドが NotFound エラーを返した場合、デフォルトのポリシーは削除されています。再度追加するには、上り（内向き）プロジェクト内ポリシーを作成するをご覧ください。

デフォルト ポリシーは、作成したポリシーと次のように組み合わされます。

  • 上り（内向き）: デフォルトのポリシーが存在するかどうかにかかわらず、ワークロードはデフォルトで他のプロジェクトや組織外から分離されます。作成した上り（内向き）ポリシーにより、他のプロジェクトや外部 CIDR ブロックなどの許可されたソースが追加されます。デフォルト ポリシーが存在する場合、独自の Ingress ポリシーでプロジェクト内ルールを繰り返す必要はありません。
  • ワークロード レベルのプロジェクト内上り（内向き）: デフォルト ポリシーが存在する間、プロジェクト内のすべてのワークロードはすべてのポートで相互に通信できます。Allow アクションを使用するワークロード レベルのプロジェクト内上り（内向き）ポリシーは、デフォルト ポリシーを削除または変更するまで、このトラフィックを制限しません。中断を回避するには、デフォルト ポリシーを削除する前に、ワークロード レベルのポリシーを適用し、準備ができていることを確認します。デフォルト ポリシーを維持しながら特定のプロジェクト内トラフィックをブロックするには、明示的な拒否ルール（プレビュー機能）を使用します。詳細については、上り（内向き）ワークロード レベルのプロジェクト内ポリシーを作成するをご覧ください。
  • 下り（外向き）: プロジェクトには、デフォルトで下り（外向き）ポリシーがありません。アウトバウンド トラフィックは組織内で制限されませんが、データ引き出し防止（デフォルトで有効）により、組織外へのトラフィックがブロックされます。下り（外向き）ポリシーは、プロジェクトのデータ引き出し防止を無効にした後にのみ有効になります。データ引き出し防止が有効になっている間、ゾーン API サーバーは下り（外向き）ポリシーを拒否し、グローバル下り（外向き）ポリシーは準備完了になりません。

グローバル プロジェクト ネットワーク ポリシー

グローバル プロジェクト ネットワーク ポリシーを作成できます。グローバル プロジェクト ネットワーク ポリシーのスコープは、GDC ユニバース全体に及びます。各 GDC ユニバースは、相互接続され、コントロール プレーンを共有するリージョンに編成された複数の GDC ゾーンで構成できます。たとえば、それぞれ 3 つのゾーンを持つ 2 つのリージョンで構成されるユニバースは、us-virginia1-a、us-virginia1-b、us-virginia1-c、eu-ams1-a、eu-ams1-b、eu-ams1-c のようになります。

ゾーン プロジェクト ネットワーク ポリシーのスコープは、作成時に指定されたゾーンに制限されます。各ゾーンは独立した障害ドメインです。ゾーンは、ローカル コントロール プレーンを使用するインフラストラクチャ、サービス、API、ツールを管理します。

GDC ユニバースのグローバル リソースの詳細については、マルチゾーンの概要をご覧ください。

グローバル プロジェクト ネットワーク ポリシーは、Networking Kubernetes Resource Model（KRM）API を使用して作成できます。API バージョン networking.global.gdc.goog を使用してグローバル リソースを作成します。

ゾーン プロジェクト ネットワーク ポリシーは、KRM API または GDC コンソールを使用して作成できます。API バージョン networking.gdc.goog を使用して、ゾーンリソースを作成します。

すべて許可のネットワーク ポリシー

すべて許可のネットワーク ポリシーを作成して、プロジェクトに広範なデフォルトのアクセスルールを確立できます。

次のタイプのすべて許可ネットワーク ポリシーを構成できます。

  • すべて許可のネットワーク ポリシー: 他のプロジェクトや外部 IP を含む、任意の送信元との間のトラフィックを許可します。
  • allow-all-external ネットワーク ポリシー: 組織外の IP アドレスとの間のトラフィックを許可します。
  • allow-all-projects ネットワーク ポリシー: 組織内のすべてのプロジェクトとの間のトラフィックを許可します。

詳細については、すべてのトラフィックを許可するネットワーク ポリシーを作成するをご覧ください。

明示的な拒否ネットワーク ポリシー

プロジェクト ネットワーク ポリシーで明示的な拒否ルールを構成して、指定したプロジェクトまたは CIDR ブロック間の接続を制限できます。

拒否ルールの主な機能と制約は次のとおりです。

  • 優先順位: 拒否ルールは、許可ルール（基本プラットフォーム ポリシーを含む）よりも絶対的に優先されます。
  • 下り（外向き）安全ルール: 重要なインフラストラクチャ トラフィックが誤ってブロックされないように、下り（外向き）拒否ルールでは、システム名前空間とプロジェクト以外の名前空間が自動的に除外されます。
  • ピアの制限: 安全な構成を確保するため、上り（内向き）拒否ルールでは from フィールドにソースピアを明示的に指定する必要があります。また、下り（外向き）拒否ルールでは to フィールドに宛先ピアを明示的に指定する必要があります。ピアフィールドを空のままにして、すべての送信元または宛先を選択することはできません。ピア フィールドを空のままにすることはできません。ポリシーは拒否されます。
  • DEP で下り（外向き）拒否なし: プロジェクトでデータ引き出し防止（DEP）が有効になっている場合、下り（外向き）拒否ルールを構成することはできません。

詳細については、明示的な拒否ネットワーク ポリシーを作成するをご覧ください。

ワークロード レベルのネットワーク ポリシー

ワークロード レベルのネットワーク ポリシーを作成して、プロジェクト内の個々の VM と Pod に対してきめ細かいアクセス制御を定義できます。これらのポリシーは、ワークロードのファイアウォールのように機能し、ラベルに基づいてトラフィック フローを制御して、セキュリティを強化し、アプリケーションを分離します。このきめ細かさにより、プロジェクト内およびプロジェクト間で相互に通信できるワークロードをより厳密に制御できます。

ワークロード レベルのネットワーク ポリシーには、単一のゾーンに沿って PNP を適用する機能もあります。

詳細については、ワークロード レベルのプロジェクト内ポリシーを作成するとワークロード レベルのプロジェクト間ポリシーを作成するをご覧ください。

ポリシーの構造と検証

ProjectNetworkPolicy リソースでは、ワークロード ラベルセレクタが数レベル深くネストされています。次の上り（内向き）ポリシーは、各セレクタの正しい場所を示しています。

apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-frontend-to-backend
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    userWorkloadSelector:
      labelSelector:
        workloads:
          matchLabels:
            app: backend
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PEER_PROJECT
        workloadSelector:
          labelSelector:
            workloads:
              matchLabels:
                app: frontend
    ports:
    - protocol: TCP
      port: 8080

次のように置き換えます。

  • PROJECT: プロジェクトの名前。
  • PEER_PROJECT: クライアント ワークロードを含むプロジェクトの名前。

このポリシーにより、PEER_PROJECT で app: frontend というラベルが付いたワークロードが、TCP ポート 8080 でプロジェクト内の app: backend というラベルが付いたワークロードに接続できるようになります。

ポリシーを作成する際は、次のルールに従ってください。

  • spec.policyType は常に明示的に Ingress または Egress に設定します。Ingress ポリシーには from ピアを持つ ingress ルールのみを含めることができ、Egress ポリシーには to ピアを持つ egress ルールのみを含めることができます。policyType を省略すると、ポリシーはデフォルトで Ingress になり、API サーバーは egress ルールのみを含むポリシーを拒否します。
  • ラベルでサブジェクト ワークロードを選択するには、spec.subject.userWorkloadSelector.labelSelector.workloads を使用します。userWorkloadSelector を省略すると、ポリシーはプロジェクト内のすべてのユーザー ワークロードに適用されます。
  • ラベルセレクタを spec.subject の直下に配置しないでください。デフォルトでは、kubectl は spec.subject.matchLabels などのフィールドを strict decoding error: unknown field メッセージで拒否します。
  • ラベルでピア ワークロードを選択するには、from エントリまたは to エントリで projectSelector.workloadSelector.labelSelector.workloads を使用します。
  • サブジェクト ワークロードまたはピア ワークロードが VM の場合は、ラベルキーの先頭に user-label.gpc.gke.io/ を付けます。たとえば、user-label.gpc.gke.io/app: backend を使用します。
  • 自動的に作成されたデフォルトのプロジェクト内ポリシーと一部の既存のポリシーでは、非推奨の spec.subject.workloadSelector フィールドが使用されます。このフィールドは、ラベルセレクタを直接受け取ります。新しいポリシーでは userWorkloadSelector を使用します。

ポリシーを適用せずにグローバル API サーバーに対して検証するには、サーバーサイドのドライランを実行します。

kubectl --kubeconfig GLOBAL_API_SERVER apply --dry-run=server \
    --validate=strict -f POLICY_FILE

ドライランでは、不明なフィールドや Ingress ポリシーの egress ルールなど、実際の kubectl apply コマンドと同じスキーマと検証エラーが報告されますが、ポリシーの作成や変更は行われません。ドライランには、ポリシーの適用と同じ権限が必要です。ドライランが成功しても、ポリシーが適用されていることは確認できません。ポリシーを適用したら、準備ができていることを確認します。

グローバル API サーバーが受け入れるフィールドを一覧表示するには、次のコマンドを実行します。

kubectl --kubeconfig GLOBAL_API_SERVER explain projectnetworkpolicy.spec \
    --api-version=networking.global.gdc.goog/v1 --recursive

次のように置き換えます。

  • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。
  • POLICY_FILE: ProjectNetworkPolicy マニフェストのパス。

事前定義ロールとアクセス権を準備する

プロジェクト ネットワーク ポリシーを構成するには、必要な ID とアクセスロールが必要です。

  • プロジェクト ネットワーク ポリシー管理者: グローバル プロジェクト名前空間内のすべてのマルチゾーン PNP リソースに対する書き込み権限があります。IAM 組織管理者に global-project-networkpolicy-admin ロールを付与するよう依頼します。詳細については、事前定義ロールの説明をご覧ください。

IP ブロックを使用してクラスタノードをターゲットにする

ProjectNetworkPolicy リソースの ipBlocks フィールドを使用して、個々のノード IP アドレスまたはノード CIDR の範囲を指定し、Pod と特定のクラスタノード間のトラフィックを制御できます（たとえば、コントロール プレーン ノードからカスタム Webhook Pod への内向きを許可したり、コントロール プレーン ノードへの Pod の外向きを制限したりできます）。手順については、Standard クラスタのプロジェクト内ポリシーを作成するをご覧ください。

スケールに関する考慮事項

特定のノードをターゲットとするプロジェクト ネットワーク ポリシーを構成する場合や、広範な CIDR の範囲を使用する場合、ポリシー構成の選択がスケーラビリティとパフォーマンスに影響する可能性があります。

  • 0.0.0.0/0 の動作: ipBlocks ルールで 0.0.0.0/0 などの広範な CIDR 範囲を使用すると、外部 IP アドレスに加えて、クラスタ内のすべてのノードが一致します。
  • スケール: クラスタ内の各ノードに一意の CIDR ID が割り当てられます。各ワークロード エンドポイント（VM または Pod）には、ネットワーク ルールを格納する内部ポリシー テーブルがあります。大規模なクラスタでは、0.0.0.0/0 などの広範な ipBlocks ルールにより、ノード数に比例してポリシー テーブルの使用量が増加します。これは、システムが一意のノード CIDR ID ごとにエントリを作成する必要があるためです。
  • 警告: ノード数が多い場合や、複雑なポリシーが多数ある場合は、ipBlocks ルールで広すぎる CIDR の範囲を使用しないでください。エンドポイントのポリシー テーブルの上限に達する可能性があります。エンドポイントがこの上限に達すると、新しいネットワーク ポリシーが適用されず、ネットワーク接続が中断されたり、そのワークロードにポリシーが適用されなくなったりする可能性があります。

次のステップ