ネットワーク ポリシー

プロジェクト Namespace レベルで仮想マシン(VM)ワークロードのネットワーク ポリシーを設定するには、ProjectNetworkPolicy リソース(Google Distributed Cloud Air-Gapped(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 プロジェクトのワークロードからの接続と、同じフローの戻りトラフィックを許可します。PROJECT_2 内の送信元から PROJECT_1 の VM にアクセスする場合にも、このポリシーを使用できます。次のコマンドを実行して、ポリシーを適用します。

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_1PROJECT_2 との間で開始された接続が許可されました。

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

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

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

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

組織間のトラフィック

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

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

異なる組織間で上り(内向き)トラフィックを許可するには、組織の外部クライアントからプロジェクトへのトラフィックを許可する ProjectNetworkPolicy を適用する必要があります(SSH を使用して VM に接続するなど)。

返信トラフィックには対応する下り(外向き)ポリシーは必要ありません。戻りトラフィックは暗黙的に許可されます。

VM が存在する組織外のソースから PROJECT_1 の VM にアクセスする場合は、次のポリシーを適用する必要があります。送信元 IP アドレスを含む CIDR を取得して使用する必要があります。CIDRnetwork/len 表記にする必要があります。たとえば、192.0.2.0/21 は有効です。

  1. kubectl の例に沿って、Ingress ProjectNetworkPolicy を構成して適用します。PROJECT_1 のすべてのユーザー ワークロードにポリシーを適用します。これにより、組織外にある CIDR 内のすべてのホストへの上り(内向き)トラフィックが許可されます。

  2. ProjectNetworkPolicy 構成を適用します。

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

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

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

セキュリティと接続で説明したように、特定のプロジェクトでデータ漏洩を許可すると、ワークロードからデータが転送される可能性があります。外向きのデータ転送を許可するトラフィックは、プロジェクトに割り当てられた既知の IP アドレスを使用する送信元ネットワーク アドレス変換(NAT)です。セキュリティと接続には、プロジェクト ネットワーク ポリシー(ProjectNetworkPolicy)の適用に関する詳細も記載されています。

返信トラフィックには対応する上り(内向き)ポリシーは必要ありません。戻りトラフィックは暗黙的に許可されます。

カスタマイズした上り(内向き)ポリシーを有効にします。

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

  2. 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
    
  3. 完了したら、ステータスに検証エラーが表示されていることを確認します。

  4. 管理者ユーザーにデータ流出防止を無効にするよう依頼します。これにより、構成が有効になり、他のすべての下り(外向き)が防止されます。

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

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

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

    変数定義
    MANAGEMENT_API_SERVERManagement API サーバーの kubeconfig パス。
    PROJECT_1GDC プロジェクトの名前。
    CIDR許可された宛先のクラスレス ドメイン間ルーティング(CIDR)ブロック。
    NAMEリンク先に関連付けられた名前。

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