Wenn Sie eine Netzwerkrichtlinie für VM-Arbeitslasten (virtuelle Maschinen) auf Projektebene festlegen möchten, verwenden Sie die ProjectNetworkPolicy
-Ressource, eine Multi-Cluster-Netzwerkrichtlinie für Google Distributed Cloud Air-Gapped (GDC). Damit können Sie Richtlinien definieren, die die Kommunikation innerhalb von Projekten, zwischen Projekten und mit externen IP-Adressen ermöglichen.
Für Traffic innerhalb eines Projekts wendet GDC standardmäßig eine vordefinierte Projektnetzwerkrichtlinie, die intra-project policy, auf jedes Projekt an. Wenn Sie Traffic zwischen Projekten innerhalb derselben Organisation aktivieren und steuern möchten, definieren Sie projektübergreifende Richtlinien. Wenn mehrere Richtlinien vorhanden sind, werden die Regeln für jedes Projekt additiv kombiniert. GDC lässt Traffic auch zu, wenn mindestens eine der Regeln übereinstimmt.
Berechtigung und Zugriff anfordern
Zum Ausführen der auf dieser Seite aufgeführten Aufgaben benötigen Sie die Rolle „Project NetworkPolicy Admin“. Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen die Rolle „Project NetworkPolicy Admin“ (project-networkpolicy-admin
) im Namespace des Projekts zuzuweisen, in dem sich die VM befindet.
Traffic innerhalb eines Projekts
Standardmäßig können VM-Arbeitslasten in einem Projekt-Namespace miteinander kommunizieren, ohne Dienste nach außen freizugeben, auch wenn die VMs Teil verschiedener Cluster innerhalb desselben Projekts sind.
Netzwerkrichtlinie für eingehenden Intra-Projekt-Traffic
Wenn Sie ein Projekt erstellen, wird auf dem Management API-Server eine Standardbasis-ProjectNetworkPolicy
erstellt, um die Kommunikation innerhalb des Projekts zu ermöglichen. Diese Richtlinie lässt eingehenden Traffic von anderen Arbeitslasten im selben Projekt zu. Sie können sie entfernen, sollten dabei aber vorsichtig sein, da dadurch sowohl die Kommunikation innerhalb des Projekts als auch die Kommunikation von Containerarbeitslasten abgelehnt wird.
Netzwerkrichtlinie für ausgehenden Intra-Projekt-Traffic
Standardmäßig müssen Sie keine Maßnahmen in Bezug auf den Egress ergreifen. Das liegt daran, dass ohne eine Richtlinie für ausgehenden Traffic der gesamte Traffic zulässig ist. Wenn Sie jedoch eine einzelne Richtlinie festlegen, ist nur der in der Richtlinie angegebene Traffic zulässig.
Wenn Sie Data Exfiltration Prevention deaktivieren und eine ProjectNetworkPolicy
für ausgehenden Traffic auf das Projekt anwenden, z. B. um den Zugriff auf eine externe Ressource zu verhindern, verwenden Sie eine erforderliche Richtlinie, um ausgehenden Traffic innerhalb des Projekts zuzulassen:
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
Projektübergreifender Traffic (innerhalb der Organisation)
VM-Arbeitslasten aus verschiedenen Projektnamespaces aber innerhalb derselben Organisation können miteinander kommunizieren, indem Sie eine projektübergreifende Netzwerkrichtlinie anwenden.
Netzwerkrichtlinie für projektübergreifenden eingehenden Traffic
Damit Projektarbeitslasten Verbindungen von anderen Arbeitslasten in einem anderen Projekt zulassen, müssen Sie eine Ingress-Richtlinie konfigurieren, damit die anderen Projektarbeitslasten Daten übertragen können.
Die folgende Richtlinie ermöglicht es Arbeitslasten im Projekt PROJECT_1
, Verbindungen von Arbeitslasten im Projekt PROJECT_2
sowie den Rückverkehr für dieselben Flows zuzulassen. Wenn Sie von einer Quelle innerhalb von PROJECT_2
auf Ihre VM in PROJECT_1
zugreifen möchten, können Sie diese Richtlinie ebenfalls verwenden.
Führen Sie den folgenden Befehl aus, um die Richtlinie anzuwenden:
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
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 PROJECT_2
-Projekt. Führen Sie den folgenden Befehl aus, um die Gegenseitigkeitsrichtlinie anzuwenden:
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
Sie haben jetzt Verbindungen zugelassen, die von PROJECT_1
und PROJECT_2
initiiert werden.
Verwenden Sie die folgenden Definitionen für Ihre Variablen.
Variable | Definition |
---|---|
MANAGEMENT_API_SERVER | Der Pfad des Management API-Servers kubeconfig . |
PROJECT_1 | Der Name eines GDC-Projekts, das PROJECT_1 im Beispiel entspricht. |
PROJECT_2 | Der Name eines GDC-Projekts, das PROJECT_2 im Beispiel entspricht. |
Netzwerkrichtlinie für projektübergreifenden ausgehenden Traffic
Wenn Sie eine projektübergreifende Ingress-Traffic-Richtlinie gewähren, um Arbeitslasten in einem Projekt (PROJECT_1
) zu aktivieren, damit Verbindungen von Arbeitslasten in einem anderen Projekt (PROJECT_2
) zugelassen werden, wird auch der Rückgabe-Traffic für dieselben Flows gewährt. Daher benötigen Sie keine Netzwerkrichtlinie für ausgehenden projektübergreifenden Traffic.
Organisationsübergreifender Traffic
Wenn Sie eine VM-Arbeitslast mit einem Ziel außerhalb Ihres Projekts verbinden möchten, das sich in einer anderen Organisation befindet, ist eine ausdrückliche Genehmigung erforderlich. Diese Genehmigung ist auf die Verhinderung von Datenexfiltration zurückzuführen, die von GDC standardmäßig aktiviert wird und verhindert, dass ein Projekt ausgehenden Traffic zu Arbeitslasten außerhalb der Organisation hat, in der sich das Projekt befindet. In diesem Abschnitt finden Sie eine Anleitung zum Hinzufügen einer bestimmten Egress-Richtlinie und zum Aktivieren des Daten-Exfiltrationsschutzes.
Netzwerkrichtlinie für organisationsübergreifenden Ingress-Traffic
Damit eingehender Traffic über verschiedene Organisationen hinweg zugelassen wird, muss eine ProjectNetworkPolicy
angewendet werden, die Traffic von organisationsfremden Clients zu Ihrem Projekt zulässt, z. B. eine Verbindung zur VM über SSH.
Für den Antworttraffic ist keine entsprechende Egress-Richtlinie erforderlich. Rückkehr-Traffic ist implizit zulässig.
Wenn Sie von einer Quelle außerhalb der Organisation, in der sich die VM befindet, auf Ihre VM in der PROJECT_1
zugreifen möchten, müssen Sie die folgende Richtlinie anwenden. Sie müssen die CIDR
mit Ihrer Quell-IP-Adresse abrufen und verwenden. Der CIDR
sollte in der network/len
-Notation angegeben werden.
192.0.2.0/21
ist beispielsweise ein gültiger Wert.
Konfigurieren und wenden Sie Ihr Ingress-
ProjectNetworkPolicy
an. Folgen Sie dabei dem Beispiel fürkubectl
. Wenden Sie die Richtlinie auf alle Nutzerarbeitslasten inPROJECT_1
an. Sie lässt eingehenden Traffic zu allen Hosts inCIDR
zu, die sich außerhalb der Organisation befinden.Wenden Sie Ihre
ProjectNetworkPolicy
-Konfiguration an: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
Netzwerkrichtlinie für organisationsübergreifenden ausgehenden Traffic
Wenn Sie die Datenübertragung an Dienste außerhalb der Organisation aktivieren möchten, passen Sie die Netzwerkrichtlinie Ihres Projekts, ProjectNetworkPolicy
, an. Da die Funktion zur Verhinderung von Daten-Exfiltration standardmäßig aktiviert ist, wird für Ihre benutzerdefinierte Egress-ProjectNetworkPolicy
im Statusfeld ein Validierungsfehler angezeigt und die Datenebene ignoriert sie. Dieser Vorgang ist so vorgesehen.
Wie unter Sicherheit und Konnektivität beschrieben, können Arbeitslasten Daten übertragen, wenn Sie die Datenexfiltration für ein bestimmtes Projekt zulassen. Der Traffic, den Sie für die ausgehende Datenübertragung zulassen, ist eine Quellnetzwerkadressübersetzung (NAT) mit einer bekannten IP-Adresse, die für das Projekt zugewiesen ist.
Unter Sicherheit und Konnektivität finden Sie auch Details zur Durchsetzung von Projektnetzwerkrichtlinien (ProjectNetworkPolicy
).
Für den Antworttraffic ist keine entsprechende Ingress-Richtlinie erforderlich. Rückkehr-Traffic ist implizit zulässig.
So aktivieren Sie Ihre benutzerdefinierte Richtlinie für ausgehenden Traffic:
Konfigurieren und wenden Sie Ihren eigenen benutzerdefinierten Egress
ProjectNetworkPolicy
an. Folgen Sie dabei demkubectl
-Beispiel. Wenden Sie die Richtlinie auf alle Nutzerarbeitslasten inPROJECT_1
an. Sie erlaubt ausgehenden Traffic zu allen Hosts inCIDR
, die sich außerhalb der Organisation befinden. Ihr erster Versuch führt zu einem erforderlichen Statusfehler, was beabsichtigt ist.Wenden Sie Ihre
ProjectNetworkPolicy
-Konfiguration an: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
Wenn Sie fertig sind, prüfen Sie, ob in Ihrem Status ein Validierungsfehler angezeigt wird.
Bitten Sie den Administratornutzer, die Funktion zur Verhinderung von Daten-Exfiltration zu deaktivieren. Dadurch wird Ihre Konfiguration aktiviert, während alle anderen Ausgänge verhindert werden.
Prüfen Sie die gerade erstellte
ProjectNetworkPolicy
und vergewissern Sie sich, dass der Fehler im Feld „Validierungsstatus“ behoben wurde und der StatusReady
True
ist. Das bedeutet, dass Ihre Richtlinie in Kraft ist:kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml
Ersetzen Sie die Variablen anhand der folgenden Definitionen.
Variable Definition MANAGEMENT_API_SERVER
Der kubeconfig-Pfad des Management API-Servers. PROJECT_1
Der Name des GDC-Projekts. CIDR
Der CIDR-Block (Classless Inter-Domain Routing) des zulässigen Ziels. NAME
Ein Name, der dem Ziel zugeordnet ist. Nachdem Sie diese Richtlinie angewendet haben und sofern Sie keine anderen Richtlinien für ausgehenden Traffic definiert haben, wird der gesamte andere ausgehende Traffic für
PROJECT_1
abgelehnt.