プロジェクト間のネットワーク ポリシーを作成する

このページでは、Google Distributed Cloud（GDC）エアギャップでプロジェクト間のトラフィック ネットワーク ポリシーを構成する手順について説明します。

プロジェクト間のトラフィックとは、異なるプロジェクト Namespace のサービスとワークロード間の通信を指しますが、同じ組織内に存在します。

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

デフォルトでは、これらのポリシーはすべてのゾーンにグローバルに適用されます。GDC ユニバースのグローバル リソースの詳細については、マルチゾーンの概要をご覧ください。

単一ゾーン内でプロジェクト間のトラフィックの適用が必要な場合は、単一ゾーンのワークロード レベルのプロジェクト間ポリシーを作成するをご覧ください。

始める前に

クロス プロジェクト トラフィック ネットワーク ポリシーを構成するには、次のものが必要です。

  • 必要な ID とアクセスロール。特定のプロジェクトのポリシーを管理するには、project-networkpolicy-admin ロールが必要です。すべてのゾーンにまたがるポリシーを管理する必要があるマルチゾーン環境では、global-project-networkpolicy-admin ロールが必要です。詳細については、事前定義ロールとアクセスを準備するをご覧ください。
  • 既存のプロジェクト。詳細については、プロジェクトを作成するをご覧ください。

プロジェクト間のポリシーを作成する

上り（内向き）または下り（外向き）のプロジェクト間トラフィック ポリシーを定義して、プロジェクト間の通信を管理できます。

内向きのクロス プロジェクト ポリシーを作成する

プロジェクトのワークロードまたはサービスが、組織内の別のプロジェクトの他のワークロードからの接続を許可するには、他のプロジェクトのワークロードのインバウンド トラフィックを許可するように上り（内向き）ファイアウォール ルールを構成する必要があります。

このポリシーは、組織内のすべてのゾーンに適用されます。

次の手順に沿って、新しいファイアウォール ルールを作成し、別のプロジェクトのワークロードからの上り（内向き）トラフィックを許可します。

コンソール

  1. 構成するプロジェクトの GDC コンソールで、ナビゲーション メニューの [ネットワーキング] > [ファイアウォール] に移動して、[ファイアウォール] ページを開きます。
  2. アクションバーの [作成] をクリックして、新しいファイアウォール ルールの作成を開始します。

  3. [ファイアウォール ルールの詳細] ページで、次の情報を入力します。

    1. [名前] フィールドに、ファイアウォール ルールの有効な名前を入力します。
    2. [トラフィックの方向] セクションで、[上り（内向き）] を選択して、他のプロジェクトのワークロードからの上り（内向き）トラフィックを許可します。
    3. [ターゲット] セクションで、次のいずれかのオプションを選択します。
      • すべてのユーザー ワークロード: 構成しているプロジェクトのワークロードへの接続を許可します。
      • Service: このファイアウォール ルールが、構成しているプロジェクト内の特定のサービスをターゲットにしていることを示します。
    4. ターゲットがプロジェクト サービスの場合は、[サービス] プルダウン メニューの利用可能なサービスのリストからサービスの名前を選択します。
    5. [From] セクションで、次のいずれかのオプションを選択します。
      • すべてのプロジェクト: 同じ組織のすべてのプロジェクトのワークロードからの接続を許可します。
      • 別のプロジェクトとすべてのユーザー ワークロード: 同じ組織の別のプロジェクトのワークロードからの接続を許可します。
    6. 別のプロジェクトからのみワークロードを転送する場合は、[プロジェクト ID] プルダウン メニューのプロジェクトのリストから、アクセス可能なプロジェクトを選択します。
    7. ターゲットがすべてのユーザー ワークロードである場合は、[プロトコルとポート] セクションで次のいずれかのオプションを選択します。
      • すべて許可: 任意のプロトコルまたはポートを使用した接続を許可します。
      • 指定したプロトコルとポート: 上り（内向き）ファイアウォール ルールの対応するフィールドで指定したプロトコルとポートのみを使用する接続を許可します。

  4. [ファイアウォール ルールの詳細] ページで、[作成] をクリックします。

これで、同じ組織内の他のプロジェクトのワークロードからの接続が許可されました。ファイアウォール ルールを作成すると、[ファイアウォール] ページの表にルールが表示されます。

API

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

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

GLOBAL_API_SERVER は、グローバル API サーバーの kubeconfig パスに置き換えます。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインをご覧ください。

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

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

PROJECT_1 と PROJECT_2 との間の接続が許可されるようになりました。

外向き（下り）のクロス プロジェクト ポリシーを作成する

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

たとえば、PROJECT_1 から PROJECT_2 へのトラフィックを許可するポリシーを作成し、データ引き出し保護が無効になっている場合は、PROJECT_2 に上り（内向き）ポリシーを作成し、PROJECT_1 に下り（外向き）ポリシーを作成する必要があります。ただし、返信パケットはポリシーの適用から除外されるため、追加のポリシーは必要ありません。

次の手順に沿って、新しいファイアウォール ルールを作成し、プロジェクト内のワークロードからのアウトバウンド トラフィックを許可します。

  1. 構成するプロジェクトの GDC コンソールで、ナビゲーション メニューの [ネットワーキング] > [ファイアウォール] に移動して、[ファイアウォール] ページを開きます。
  2. アクションバーの [作成] をクリックして、新しいファイアウォール ルールの作成を開始します。

  3. [ファイアウォール ルールの詳細] ページで、次の情報を入力します。

    1. [名前] フィールドに、ファイアウォール ルールの有効な名前を入力します。
    2. [トラフィックの方向] セクションで、[下り（外向き）] を選択して、このファイアウォール ルールがアウトバウンド トラフィックを制御していることを示します。
    3. [ターゲット] セクションで、次のいずれかのオプションを選択します。
      • すべてのユーザー ワークロード: 構成しているプロジェクトのワークロードからの接続を許可します。
      • Service: このファイアウォール ルールが、構成しているプロジェクト内の特定のサービスをターゲットにしていることを示します。
    4. ターゲットがプロジェクト サービスの場合は、[サービス] プルダウン メニューの利用可能なサービスのリストからサービスの名前を選択します。
    5. [宛先] セクションで、次のいずれかのオプションを選択します。
      • すべてのプロジェクト: 同じ組織のすべてのプロジェクトのワークロードへの接続を許可します。
      • [別のプロジェクト] と [すべてのユーザー ワークロード] を選択すると、同じ組織の別のプロジェクトのワークロードへの接続が許可されます。
    6. ワークロードを別のプロジェクトにのみ転送する場合は、[プロジェクト ID] プルダウン メニューのプロジェクトのリストから、アクセス可能なプロジェクトを選択します。
    7. ターゲットがすべてのユーザー ワークロードである場合は、[プロトコルとポート] セクションで次のいずれかのオプションを選択します。
      • すべて許可: 任意のプロトコルまたはポートを使用した接続を許可します。
      • 指定したプロトコルとポート: 下り（外向き）ファイアウォール ルールの対応するフィールドで指定したプロトコルとポートのみを使用する接続を許可します。

  4. [ファイアウォール ルールの詳細] ページで、[作成] をクリックします。

これで、同じ組織内の他のプロジェクトのワークロードへの接続が許可されました。ファイアウォール ルールを作成すると、[ファイアウォール] ページの表にルールが表示されます。

ワークロード レベルのクロス プロジェクト ポリシーを作成する

ワークロード単位のネットワーク ポリシーを使用すると、プロジェクト間の個々のワークロード間の通信をきめ細かく制御できます。この粒度により、ネットワーク アクセスをより厳密に制御できるため、セキュリティとリソースの使用率が向上します。

内向きワークロード レベルのクロス プロジェクト ポリシーを作成する

  • 上り（内向き）ワークロード レベルのクロス プロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
 namespace: PROJECT_1
 name: allow-cross-project-inbound-traffic-from-target-to-subject
spec:
 policyType: Ingress
 subject:
   subjectType: UserWorkload
   workloadSelector:
     matchLabels:
       SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
 ingress:
 - from:
   - projectSelector:
       projects:
         matchNames:
         - PROJECT_2
       workloads:
         matchLabels:
           TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを受信するプロジェクトの名前。
    • PROJECT_2: トラフィックの送信元プロジェクトの名前。
    • SUBJECT_LABEL_KEY: ソース ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元となるワークロードを指定します。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィック ソースになります。
    • TARGET_LABEL_KEY: 宛先ワークロードの選択に使用されるラベルのキー。
    • TARGET_LABEL_VALUE: TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるワークロードを指定します。

下り（外向き）ワークロード レベルのプロジェクト間ポリシーを作成する

  • 下り（外向き）ワークロード レベルのクロス プロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを送信するプロジェクトの名前。
    • PROJECT_2: トラフィックを受信するプロジェクトの名前。
    • SUBJECT_LABEL_KEY: ソース ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元となるワークロードを指定します。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィック ソースになります。
    • TARGET_LABEL_KEY: 宛先ワークロードの選択に使用されるラベルのキー。
    • TARGET_LABEL_VALUE: TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるワークロードを指定します。

単一ゾーンのワークロード レベルのプロジェクト間ポリシーを作成する

ワークロード単位のネットワーク ポリシーは、単一のゾーンに沿って PNP を適用できます。特定のラベルを単一ゾーン内のワークロードに追加すると、そのゾーンのプロジェクト内または異なるプロジェクト内の個々のワークロード間の通信を制御できます。

単一ゾーンのワークロード レベルのプロジェクト間ポリシーを作成する

  1. 単一ゾーンの Ingress ワークロード レベルのクロス プロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを受信するプロジェクトの名前。
    • PROJECT_2: トラフィックの送信元プロジェクトの名前。
    • SUBJECT_LABEL_KEY: ソース ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元となるワークロードを指定します。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィック ソースになります。
    • TARGET_LABEL_KEY: 宛先ワークロードの選択に使用されるラベルのキー。
    • TARGET_LABEL_VALUE: TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるワークロードを指定します。
    • ZONE_SUBJECT_LABEL_KEY: ソースゾーンの選択に使用されるラベルのキー。例: zone、または region。
    • ZONE_SUBJECT_LABEL_VALUE: ZONE_SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元ゾーンを指定します。たとえば、ZONE_SUBJECT_LABEL_KEY が zone で、ZONE_SUBJECT_LABEL_VALUE が us-central1-a の場合、ラベル zone: us-central1-a のワークロードがトラフィック ソースになります。
    • ZONE_TARGET_LABEL_KEY: 宛先ゾーンの選択に使用されるラベルのキー。
    • ZONE_TARGET_LABEL_VALUE: ZONE_TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるゾーンを指定します。

単一ゾーンの下り（外向き）ワークロード レベルのプロジェクト間ポリシーを作成する

  • 単一ゾーンの下り（外向き）ワークロード レベルのクロス プロジェクト ポリシーを作成するには、次のカスタム リソースを作成して適用します。

    kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
spec:
  policyType: Egress
  subject:
    subjectType: UserWorkload
    workloadSelector:
      matchLabels:
        SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
        ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT_2
        workloads:
          matchLabels:
            TARGET_LABEL_KEY: TARGET_LABEL_VALUE
            ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
EOF

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

    • GLOBAL_API_SERVER: グローバル API サーバーの kubeconfig パス。詳細については、グローバル API サーバーとゾーン API サーバーをご覧ください。API サーバーの kubeconfig ファイルをまだ生成していない場合は、ログインで詳細を確認してください。
    • PROJECT_1: トラフィックを送信するプロジェクトの名前。
    • PROJECT_2: トラフィックを受信するプロジェクトの名前。
    • SUBJECT_LABEL_KEY: ソース ワークロードの選択に使用されるラベルのキー。例: app、tier、または role
    • SUBJECT_LABEL_VALUE: SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元となるワークロードを指定します。たとえば、SUBJECT_LABEL_KEY が app で、SUBJECT_LABEL_VALUE が backend の場合、ラベル app: backend のワークロードがトラフィック ソースになります。
    • TARGET_LABEL_KEY: 宛先ワークロードの選択に使用されるラベルのキー。
    • TARGET_LABEL_VALUE: TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるワークロードを指定します。
    • ZONE_SUBJECT_LABEL_KEY: ソースゾーンの選択に使用されるラベルのキー。例: zone、または region。
    • ZONE_SUBJECT_LABEL_VALUE: ZONE_SUBJECT_LABEL_KEY に関連付けられた値。許可されたトラフィックの送信元ゾーンを指定します。たとえば、ZONE_SUBJECT_LABEL_KEY が zone で、ZONE_SUBJECT_LABEL_VALUE が us-central1-a の場合、ラベル zone: us-central1-a のワークロードがトラフィック ソースになります。
    • ZONE_TARGET_LABEL_KEY: 宛先ゾーンの選択に使用されるラベルのキー。
    • ZONE_TARGET_LABEL_VALUE: ZONE_TARGET_LABEL_KEY に関連付けられた値。許可されたトラフィックの宛先となるゾーンを指定します。