このページは Cloud Translation API によって翻訳されました。

ネットワークポリシー

プロジェクト Namespace レベルで仮想マシン（VM）ワークロードのネットワークポリシーを設定するには、ProjectNetworkPolicy リソース（Google Distributed Cloud エアギャップアプライアンス（GDC）のマルチクラスタネットワークポリシー）を使用します。これにより、プロジェクト内、プロジェクト間、外部 IP アドレスへの通信を許可するポリシーを定義できます。

プロジェクト内のトラフィックの場合、GDC はデフォルトで、事前定義されたプロジェクトネットワークポリシー（プロジェクト内ポリシー）を各プロジェクトに適用します。同じ組織内のプロジェクト間でトラフィックを有効にして制御するには、プロジェクト間のポリシーを定義します。複数のポリシーが存在する場合、GDC は各プロジェクトのルールを加算的に結合します。GDC では、ルールが 1 つでも一致すればトラフィックが許可されます。

権限とアクセス権をリクエストする

このページに記載されているタスクを実行するには、プロジェクトの NetworkPolicy 管理者のロールが必要です。プロジェクトの IAM 管理者に、VM が存在するプロジェクトの Namespace でプロジェクトの NetworkPolicy 管理者（project-networkpolicy-admin）ロールを付与するよう依頼します。

プロジェクト内のトラフィック

デフォルトでは、プロジェクト Namespace の VM ワークロードは、VM が同じプロジェクト内の異なるクラスタに属していても、外部にサービスを公開することなく相互に通信できます。

上り（内向き）プロジェクト内トラフィックネットワークポリシー

プロジェクトを作成すると、プロジェクト内の通信を許可するために、Management API サーバーにデフォルトのベース ProjectNetworkPolicy が作成されます。このポリシーにより、同じプロジェクト内の他のワークロードからの上り（内向き）トラフィックが許可されます。削除できますが、削除するとプロジェクト内とコンテナワークロードの両方の通信が拒否されるため、注意が必要です。

プロジェクト内の下り（外向き）トラフィックネットワークポリシー

デフォルトでは、下り（外向き）について対応する必要はありません。これは、下り（外向き）ポリシーがない場合、すべてのトラフィックが許可されるためです。ただし、単一のポリシーを設定すると、そのポリシーで指定されたトラフィックのみが許可されます。

データ漏洩防止を無効にして、外部リソースへのアクセスを防止するなど、プロジェクトに下り（外向き）ProjectNetworkPolicy を適用する場合は、必要なポリシーを使用してプロジェクト内の下り（外向き）を許可します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

プロジェクト間（組織内）トラフィック

異なるプロジェクト名前空間の VM ワークロード（同じ組織内）は、クロスプロジェクトネットワークポリシーを適用することで相互に通信できます。

上り（内向き）のプロジェクト間トラフィックネットワークポリシー

プロジェクトワークロードが別のプロジェクトの他のワークロードからの接続を許可するには、他のプロジェクトワークロードが上り（内向き）できるように上り（内向き）ポリシーを構成する必要があります。

次のポリシーでは、PROJECT_1 プロジェクトのワークロードが PROJECT_2 プロジェクトのワークロードからの接続と、同じフローの戻りトラフィックを許可します。次のコマンドを実行して、ポリシーを適用します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-ingress-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

上記のコマンドでは、PROJECT_2 から PROJECT_1 へのアクセスは許可されますが、PROJECT_1 から PROJECT_2 への接続は許可されません。後者の場合は、PROJECT_2 プロジェクトに相互ポリシーが必要です。次のコマンドを実行して、相互ポリシーを適用します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-ingress-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

これで、PROJECT_1 と PROJECT_2 との間で開始された接続が許可されました。

変数には次の定義を使用します。

変数	定義
`MANAGEMENT_API_SERVER`	Management API サーバーの `kubeconfig` パス。
`PROJECT_1`	例の PROJECT_1 に対応する GDC プロジェクトの名前。
`PROJECT_2`	例の PROJECT_2 に対応する GDC プロジェクトの名前。

下り（外向き）のクロスプロジェクトトラフィックネットワークポリシー

1 つのプロジェクト PROJECT_1 のワークロードに上り（内向き）のクロスプロジェクトトラフィックポリシーを付与して、別のプロジェクト PROJECT_2 のワークロードからの接続を許可すると、同じフローの戻りトラフィックも付与されます。したがって、下り（外向き）のプロジェクト間トラフィックネットワークポリシーは必要ありません。

組織間のトラフィック

VM ワークロードを、別の組織に存在するプロジェクト外の宛先に接続するには、明示的な承認が必要です。この承認は、GDC がデフォルトで有効にするデータ引き出し防止機能によるものです。この機能により、プロジェクトが属する組織外のワークロードへの下り（外向き）がプロジェクトで禁止されます。このセクションでは、特定の下り（外向き）ポリシーを追加してデータ漏洩を有効にする手順について説明します。

上り（内向き）の組織間トラフィックネットワークポリシー

組織間の下り（外向き）ネットワークポリシーを構成した場合は、上り（内向き）を付与する必要はありません。組織外のワークロードからの下り（外向き）トラフィックは、ロードバランサ（LB）を通過します。この下り（外向き）トラフィックは、プロジェクトに割り振った IP アドレスを使用する送信元ネットワークアドレス変換（NAT）です。

組織間の下り（外向き）トラフィックネットワークポリシー

組織外のサービスへの下り（外向き）を有効にするには、プロジェクトネットワークポリシー ProjectNetworkPolicy をカスタマイズします。ただし、データ漏洩防止はデフォルトで有効になっているため、カスタマイズされた下り（外向き）ProjectNetworkPolicy のステータスフィールドに検証エラーが表示され、データプレーンはそれを無視します。これは仕様です。

特定のプロジェクトでデータ漏洩を許可すると、ワークロードは下り（外向き）できます。下り（外向き）を許可するトラフィックは、プロジェクトに割り当てられた既知の IP アドレスを使用する送信元ネットワークアドレス変換（NAT）です。

次の手順では、カスタマイズした下り（外向き）ポリシーを有効にする方法を説明します。

独自のカスタマイズされた上り（内向き） ProjectNetworkPolicy を構成して適用します。kubectl CLI の例をご覧ください。PROJECT_1 のすべてのユーザーワークロードにポリシーを適用します。これにより、組織外にある CIDR 内のすべてのホストへの下り（外向き）トラフィックが許可されます。最初の試行では、必要なステータスエラーが発生します。これは想定どおりです。

ProjectNetworkPolicy 構成を適用します。

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-egress-traffic-to-NAME
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
 egress:
  - to:
    - ipBlock:
        cidr: CIDR
EOF

完了したら、ステータスに検証エラーが表示されていることを確認します。

重要: プロジェクトの組織外の宛先への下り（外向き）トラフィックのうち、下り（外向き）ProjectNetworkPolicy 構成で明示的に許可されているトラフィックのみが下り（外向き）を許可されます。他の下り（外向き）トラフィックは拒否されます。したがって、要件でこのようなポリシーが義務付けられている場合にのみ、カスタマイズされた上り（内向き）ProjectNetworkPolicy を適用してください。
管理者ユーザーにデータ流出防止を無効にするよう依頼します。これにより、構成が有効になり、他のすべての下り（外向き）が防止されます。

重要: 1 つ以上の有効な ProjectNetworkPolicy を定義せずにデータ引き出し防止を無効にすると、すべての下り（外向き）トラフィックがプロジェクトの組織外の宛先に許可されます。カスタマイズされた上り（内向き）ProjectNetworkPolicy を構成するステップ 1 を完了する前に、この機能を無効にしないでください。

作成した ProjectNetworkPolicy を確認し、検証ステータスフィールドのエラーが消え、ステータス Ready が True になっていることを確認します。これは、ポリシーが有効であることを示しています。

kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy
allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml

次の定義を使用して、変数を置き換えます。

変数	定義
`MANAGEMENT_API_SERVER`	Management API サーバーの `kubeconfig` ファイル。
`PROJECT_1`	GDC プロジェクトの名前。
`CIDR`	許可された宛先のクラスレスドメイン間ルーティング（CIDR）ブロック。
`NAME`	リンク先に関連付けられた名前。

このポリシーを適用し、他の下り（外向き）ポリシーを定義していない場合、PROJECT_1 の他のすべての下り（外向き）トラフィックは拒否されます。

ネットワーク ポリシー コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

権限とアクセス権をリクエストする

プロジェクト内のトラフィック

上り（内向き）プロジェクト内トラフィック ネットワーク ポリシー

プロジェクト内の下り（外向き）トラフィック ネットワーク ポリシー

プロジェクト間（組織内）トラフィック

上り（内向き）のプロジェクト間トラフィック ネットワーク ポリシー

下り（外向き）のクロス プロジェクト トラフィック ネットワーク ポリシー