Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Auf dieser Seite finden Sie eine Anleitung zum Konfigurieren von Netzwerkrichtlinien für projektübergreifenden Traffic in einer Google Distributed Cloud (GDC) Air Gap-Appliance.
Projektübergreifender Traffic bezieht sich auf die Kommunikation zwischen Diensten und Arbeitslasten aus verschiedenen Projektnamespaces, aber innerhalb derselben Organisation.
Dienste und Arbeitslasten in einem Projekt sind standardmäßig von externen Diensten und Arbeitslasten isoliert. Dienste und Arbeitslasten aus verschiedenen Projektnamespaces innerhalb derselben Organisation können jedoch miteinander kommunizieren, indem Sie Netzwerkrichtlinien für projektübergreifenden Traffic anwenden.
Hinweise
Zum Konfigurieren von Netzwerkrichtlinien für Intra-Projekt-Traffic benötigen Sie Folgendes:
Ein vorhandenes Projekt. Weitere Informationen finden Sie unter Projekt erstellen.
Projektübergreifende Traffic-Richtlinie erstellen
Sie können richtlinienübergreifende Traffic-Richtlinien für eingehenden oder ausgehenden Traffic definieren, um die Kommunikation zwischen Projekten zu verwalten.
Firewallregel für eingehenden Traffic für projektübergreifenden Traffic erstellen
Damit Projekt-Workloads oder -Dienste Verbindungen von anderen Workloads in einem anderen Projekt zulassen, müssen Sie eine Firewallregel für eingehenden Traffic konfigurieren, um den eingehenden Traffic anderer Projekt-Workloads zuzulassen.
Führen Sie die folgenden Schritte aus, um eine neue Firewallregel zu erstellen und eingehenden Traffic von Arbeitslasten in einem anderen Projekt zuzulassen:
Console
Rufen Sie in der GDC Console des Projekts, das Sie konfigurieren, im Navigationsmenü Netzwerk>Firewall auf, um die Seite Firewall zu öffnen.
Klicken Sie in der Aktionsleiste auf Erstellen, um eine neue Firewallregel zu erstellen.
Geben Sie auf der Seite Details zur Firewallregel die folgenden Informationen an:
Geben Sie im Feld Name einen gültigen Namen für die Firewallregel ein.
Wählen Sie im Bereich Trafficrichtung die Option Eingehender Traffic aus, um eingehenden Traffic von Arbeitslasten in anderen Projekten zuzulassen.
Wählen Sie im Bereich Ziel eine der folgenden Optionen aus:
Alle Nutzerarbeitslasten:Verbindungen zu den Arbeitslasten des Projekts, das Sie konfigurieren, sind zulässig.
Dienst:Geben Sie an, dass diese Firewallregel auf einen bestimmten Dienst in dem Projekt ausgerichtet ist, das Sie konfigurieren.
Wenn Ihr Ziel ein Projektdienst ist, wählen Sie den Namen des Dienstes aus der Liste der verfügbaren Dienste im Drop-down-Menü Dienst aus.
Wählen Sie im Bereich Von eine der folgenden beiden Optionen aus:
Alle Projekte:Verbindungen von Arbeitslasten in allen Projekten zulassen.
Anderes Projekt und Alle Nutzer-Workloads:Verbindungen von Workloads in einem anderen Projekt sind zulässig.
Wenn Sie Arbeitslasten nur aus einem anderen Projekt übertragen möchten, wählen Sie in der Drop-down-Liste Projekt-ID ein Projekt aus, auf das Sie zugreifen können.
Wenn Ihr Ziel alle Nutzerarbeitslasten sind, wählen Sie im Bereich Protokolle und Ports eine der folgenden Optionen aus:
Alle zulassen:Verbindungen über ein beliebiges Protokoll oder einen beliebigen Port zulassen.
Angegebene Protokolle und Ports:Verbindungen sind nur über die Protokolle und Ports zulässig, die Sie in den entsprechenden Feldern für die Firewallregel für eingehenden Traffic angeben.
Klicken Sie auf der Seite Details zur Firewallregel auf Erstellen.
Sie haben jetzt Verbindungen von anderen Projektarbeitslasten zugelassen. Nachdem Sie die Firewallregel erstellt haben, wird sie in einer Tabelle auf der Seite Firewall angezeigt.
API
Die folgende Richtlinie ermöglicht es Arbeitslasten im Projekt PROJECT_1, Verbindungen von Arbeitslasten im Projekt PROJECT_2 sowie den Rückgabe-Traffic für dieselben Flows zuzulassen. Wenden Sie die Richtlinie an:
Ersetzen Sie API_SERVER durch den kubeconfig-Pfad des API-Servers.
Wenn Sie noch keine kubeconfig-Datei für den API-Server generiert haben, finden Sie weitere Informationen unter Anmelden.
Der vorherige Befehl erlaubt, dass PROJECT_2 zu PROJECT_1 wechselt, aber nicht, dass Verbindungen von PROJECT_1 zu PROJECT_2 initiiert werden. Für Letzteres benötigen Sie eine entsprechende Richtlinie im Projekt PROJECT_2. Wenden Sie die Richtlinie für Gegenseitigkeit an:
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (UTC)."],[],[],null,["# Create cross-project traffic network policies\n\nThis page provides instructions to configure cross-project traffic network policies in Google Distributed Cloud (GDC) air-gapped appliance.\n\nCross-project traffic refers to the communication between services and workloads from different project namespaces but within the same organization.\n\nServices and workloads in a project are isolated from external services and workloads by default. However, services and workloads from different project namespaces and within the same organization can communicate with each other by applying cross-project traffic network policies.\n\nBefore you begin\n----------------\n\nTo configure intra-project traffic network policies, you must have the following:\n\n- The necessary identity and access roles. For more information, see [Prepare predefined roles and access](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/pnp/pnp-overview#prepare-predefined-roles-and-access).\n- An existing project. For more information, see [Create a project](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/create-a-project).\n\nCreate a cross-project traffic policy\n-------------------------------------\n\nYou can define ingress or egress cross-project traffic policies to manage the communication between projects.\n\n### Create an ingress firewall rule for cross-project traffic\n\nFor project workloads or services to allow connections from other workloads in another project, you must configure an ingress firewall rule to allow the inbound traffic of other project workloads.\n\nWork through the following steps to create a new firewall rule and allow inbound traffic from workloads in another project: \n\n### Console\n\n1. Within the GDC console of the project you are configuring, go to **Networking** \\\u003e **Firewall** in the navigation menu to open the **Firewall** page.\n2. Click **Create** in the action bar to begin creating a new firewall rule.\n3. On the **Firewall rule details** page, fill out the following information:\n\n 1. In the **Name** field, enter a valid name for your firewall rule.\n 2. In the **Direction of traffic** section, select **Ingress** to allow inbound traffic from workloads in other projects.\n 3. In the **Target** section, select one of the following options:\n - **All user workloads:** allow connections to the workloads of the project you are configuring.\n - **Service:** indicate that this firewall rule targets a specific service within the project you are configuring.\n 4. If your target is a project service, select the name of the service from the list of available services on the **Service** drop-down menu.\n 5. In the **From** section, select one of the following two options:\n - **All projects:** allow connections from workloads in all the projects.\n - **Another project** and **All user workloads:** allow connections from workloads in another project.\n 6. If you want to transfer workloads only from another project, select a project that you can access from the list of projects on the **Project ID** drop-down menu.\n 7. If your target is all user workloads, select one of the following options in the **Protocols and ports** section:\n - **Allow all:** allow connections using any protocol or port.\n - **Specified protocols and ports:** allow connections using only the protocols and ports that you specify in the corresponding fields for the ingress firewall rule.\n4. On the **Firewall rule details** page, click **Create**.\n\nYou've now permitted connections from other project workloads. After creating the firewall rule, the rule is visible in a table on the **Firewall** page.\n\n### API\n\nThe following policy enables workloads in the \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\nproject to permit connections from workloads in the\n\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e project, as well as the return traffic for\nthe same flows. Apply the policy: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e apply -f - \u003c\u003cEOF\n apiVersion: networking.global.gdc.goog/v1\n kind: ProjectNetworkPolicy\n metadata:\n namespace: \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n name: allow-inbound-traffic-from-\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n spec:\n policyType: Ingress\n subject:\n subjectType: UserWorkload\n ingress:\n - from:\n - projectSelector:\n projects:\n matchNames:\n - \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n EOF\n\nReplace \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e with the API\nserver's kubeconfig path.\nIf you have not yet generated a kubeconfig file for the API server,\nsee [Sign in](/distributed-cloud/hosted/docs/latest/appliance/platform/pa-user/iam/sign-in#cli) for\ndetails.\n\nThe preceding command allows \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e to go to\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e, but doesn't allow connections initiated from\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e to \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e. For\nthe latter, you require a reciprocal policy in the\n\u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e project. Apply\nthe reciprocal policy: \n\n kubectl --kubeconfig \u003cvar translate=\"no\"\u003eAPI_SERVER\u003c/var\u003e apply -f - \u003c\u003cEOF\n apiVersion: networking.global.gdc.goog/v1\n kind: ProjectNetworkPolicy\n metadata:\n namespace: \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e\n name: allow-inbound-traffic-from-\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n spec:\n policyType: Ingress\n subject:\n subjectType: UserWorkload\n ingress:\n - from:\n - projectSelector:\n projects:\n matchNames:\n - \u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e\n EOF\n\nConnections are now permitted to and from\n\u003cvar translate=\"no\"\u003ePROJECT_1\u003c/var\u003e and \u003cvar translate=\"no\"\u003ePROJECT_2\u003c/var\u003e."]]
