Anleitung: GKE Enterprise sichern

---

GKE Enterprise bietet eine einheitliche Plattform für den Aufbau und die Bereitstellung sicherer Dienste mit integrierten Sicherheitsfunktionen auf jeder Ebene, die separat oder zusammen arbeiten können, um Sicherheitsprobleme zu vermeiden. In dieser Anleitung lernen Sie einige der leistungsstarken Sicherheitsfunktionen von GKE Enterprise mithilfe des Anthos-Beispiel-Deployments in Google Cloud kennen. Mit dem Anthos-Beispiel-Deployment wird eine praxisorientierte GKE Enterprise-Umgebung mit einem GKE-Cluster, Service Mesh und einer Bank of GKE Enterprise-Anwendung mit mehreren Mikrodiensten bereitgestellt.

Hinweis: Wenn Sie mit GKE Enterprise und dem Anthos-Beispiel-Deployment noch nicht vertraut sind, wechseln Sie vor der Ausführung dieser Anleitung zu GKE Enterprise entdecken, um das Deployment zu installieren, und lernen Sie die Features und Konzepte von GKE Enterprise über unsere Beispielanwendung kennen.

Lernziele

In dieser Anleitung lernen Sie einige der Sicherheitsfunktionen von GKE mithilfe der folgenden Aufgaben kennen:

• Gegenseitige TLS (mTLS) in Ihrem Service Mesh durch Config Sync, um eine sichere Ende-zu-Ende-Kommunikation zu gewährleisten

• Sicherheitsmechanismen einrichten, um sicherzustellen, dass Pods mit privilegierten Containern nicht versehentlich mithilfe von Policy Controller bereitgestellt werden.

Kosten

Für die Bereitstellung der Bank of Anthos-Anwendung fallen für GKE Enterprise in Google Cloud „Pay as you go“-Gebühren gemäß unserer Preisseite an, sofern Sie nicht bereits ein Abo erworben haben.

Sie sind auch für andere Google Cloud-Kosten verantwortlich, die während der Ausführung der Bank of Anthos-Anwendung entstehen, z. B. Gebühren für Compute Engine-VMs und Load-Balancer.

Wir empfehlen, nach Abschluss der Anleitung ein Clean-up durchzuführen, um weitere Kosten zu vermeiden.

Hinweise

Diese Anleitung ist ein Nachtrag zur Anleitung Anthos kennenlernen. Bevor Sie mit der Anleitung beginnen, folgen Sie der Anleitung auf dieser Seite, um Ihr Projekt einzurichten und das Anthos-Beispiel-Deployment zu installieren.

Cloud Shell-Umgebung einrichten

In dieser Anleitung verwenden Sie die Cloud Shell-Befehlszeile und den Editor, um Änderungen an der Clusterkonfiguration vorzunehmen.

Zum Initialisieren der Shell-Umgebung für diese Anleitung enthält das Anthos-Beispiel-Deployment ein Skript, das Folgendes ausführt:

• Installiert alle fehlenden Befehlszeilentools, um interaktiv mit dem Deployment zu arbeiten und Änderungen daran zu prüfen:

  • kubectl
  • kubectx
  • istioctl
  • nomos

• Legt den Kubernetes-Kontext für anthos-sample-cluster1 fest

• Klont das Repository, das Config Sync zum Synchronisieren von Konfigurationsänderungen mit Ihrem Cluster verwendet. Änderungen, die Sie per Commit übertragen und an das vorgelagerte Repository übertragen haben, werden von Config Sync mit Ihrer Infrastruktur synchronisiert. Dies ist die empfohlene Vorgehensweise, um Änderungen an der Infrastruktur anzuwenden.

So richten Sie Ihre Umgebung ein:

1. Sie benötigen eine aktive Cloud Shell-Sitzung. Sie können Cloud Shell starten, indem Sie in der Google Cloud Console in Ihrem Anleitungsprojekt auf Cloud Shell aktivieren klicken.

2. Erstellen Sie ein Arbeitsverzeichnis:

   mkdir tutorial
   cd tutorial
   

3. Laden Sie das Initialisierungsskript herunter:

   curl -sLO https://github.com/GoogleCloudPlatform/anthos-sample-deployment/releases/latest/download/init-anthos-sample-deployment.env
   

4. Fügen Sie das Initialisierungsskript in Ihre Cloud Shell-Umgebung ein:

   source init-anthos-sample-deployment.env
   

   Ausgabe:

   /google/google-cloud-sdk/bin/gcloud
   /google/google-cloud-sdk/bin/kubectl
   Your active configuration is: [cloudshell-13605]
   export PROJECT as anthos-launch-demo-1
   export KUBECONFIG as ~/.kube/anthos-launch-demo-1.anthos-trial-gcp.config
   Fetching cluster endpoint and auth data.
   kubeconfig entry generated for anthos-sample-cluster1.
   Copying gs://config-management-release/released/latest/linux_amd64/nomos...
   \ [1 files][ 40.9 MiB/ 40.9 MiB]
   Operation completed over 1 objects/40.9 MiB.
   Installed nomos into ~/bin.
   Cloned ACM config repo: ./anthos-sample-deployment-config-repo
   

5. Wechseln Sie in das Konfigurations-Repository und verwenden Sie es als Arbeitsverzeichnis für den Rest dieser Anleitung:

   cd anthos-sample-deployment-config-repo
   

mTLS in Ihrem Dienst-Mesh erzwingen

In Hinblick auf die globale Expansion hat Ihr CIO erzwungen, dass alle Nutzerdaten bei der Übertragung verschlüsselt werden müssen, um sensible Informationen gemäß den regionalen Datenschutzgesetzen zu schützen.

Ist Ihr Traffic derzeit sicher?

1. Rufen Sie die Seite Cloud Service Mesh in Ihrem Projekt auf, in dem Sie das Anthos-Beispiel-Deployment bereitgestellt haben:

   Zur Seite „Cloud Service Mesh“

2. Klicken Sie in der Liste der Dienste auf transactionhistory. Wie Sie in GKE Enterprise entdecken gesehen haben, werden auf der Seite mit den Dienstdetails alle Telemetriedaten für diesen Dienst angezeigt.

3. Wählen Sie auf der Seite transactionhistory im Menü transactionhistory die Option transactionhistory aus. Hier können Sie die eingehende und ausgehende Verbindungen für den Dienst sehen. Ein entsperrtes Schloss-Symbol bedeutet, dass Traffic an diesem Port erkannt wurde, der kein gegenseitiges TLS (mTLS) verwendet.

mTLS ist ein Sicherheitsprotokoll, das garantiert, dass der Traffic zwischen beiden Diensten sicher und vertrauenswürdig ist. Jeder Dienst akzeptiert nur verschlüsselten Traffic von authentifizierten Diensten. Wie Sie sehen, zeigt Cloud Service Mesh deutlich, dass in Ihrem Mesh unverschlüsselter Traffic vorhanden ist. In Cloud Service Mesh werden unterschiedliche Farben verwendet, um anzugeben, ob der unverschlüsselte Traffic eine Mischung aus Klartext und mTLS (orange) oder nur Klartext (rot) enthält.

Mit GKE Enterprise sind es nur noch wenige Schritte, bis Sie die Vorgaben einhalten. Anstatt Änderungen auf Quellcodeebene vorzunehmen, Ihre Anwendung in dieser Situation neu zu erstellen und noch einmal bereitzustellen, können Sie die neue Verschlüsselungsrichtlinie mithilfe von Config Sync deklarativ durch Konfiguration anwenden, um Ihre neue Konfiguration automatisch aus einem zentralen Git-Repository bereitzustellen.

In diesem Abschnitt tun Sie Folgendes:

1. Sie passen die Richtlinienkonfiguration in Ihrem Git-Repository an, um zu erzwingen, dass Dienste verschlüsselte Kommunikation über mTLS verwenden.

2. Sie nutzen Config Sync, um die Richtlinienänderung automatisch aus dem Repository zu übernehmen und die Cloud Service Mesh-Richtlinie anzupassen.

3. Sie prüfen, ob die Richtlinienänderung auf Ihrem Cluster erfolgt ist, der für die Synchronisierung mit dem Repository konfiguriert ist.

Config Sync-Einrichtung bestätigen

1. Der nomos-Befehl ist ein Befehlszeilentool, mit dem Sie mit dem Config Management Operator interagieren und andere nützliche Config Sync-Aufgaben über Ihren lokalen Computer oder Cloud Shell ausführen können. Um zu prüfen, ob Config Sync korrekt auf Ihrem Cluster installiert und konfiguriert ist, führen Sie nomos status aus:

   nomos status
   

   Ausgabe:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       abef0b01            master        Healthy
   

   Die Ausgabe bestätigt, dass Config Sync so konfiguriert ist, dass Ihr Cluster mit dem Master-Zweig Ihres Konfigurations-Repositorys synchronisiert wird. Das Sternchen in der ersten Spalte gibt an, dass der aktuelle Kontext auf anthos-sample-cluster1 gesetzt ist. Wenn Sie dies nicht sehen, ändern Sie den aktuellen Kontext auf anthos-sample-cluster1:

   kubectl config use-context anthos-sample-cluster1
   

   Ausgabe:

   Switched to context "anthos-sample-cluster1".
   

2. Prüfen Sie, ob Sie sich im master-Zweig befinden:

   git checkout master
   

   Ausgabe:

   Already on 'master'
   Your branch is up to date with 'origin/master'.
   

3. Prüfen Sie Ihr vorgelagertes Konfigurations-Repository:

   git remote -v
   

   Ausgabe:

   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (fetch)
   origin  https://source.developers.google.com/.../anthos-sample-deployment-config-repo (push)
   

4. Prüfen Sie, ob Sie sich noch im Verzeichnis anthos-sample-deployment-config-repo befinden, und führen Sie den folgenden Befehl aus, um die Git-Einrichtung zu prüfen: Diese Hilfsfunktion wird vom Initialisierungsskript in Ihre Umgebung eingebunden und führt git config-Befehle aus, um die vorhandenen user.email- und user.name-Werte Ihrer Git-Konfiguration zu prüfen. Wenn diese Werte nicht konfiguriert sind, legt die Funktion Standardwerte auf Repository-Ebene anhand des derzeit aktiven Google Cloud-Kontos fest.

   init_git
   

   Ausgabe (Beispiel):

   Configured local git user.email to [e-mail]
   Configured local git user.name to user
   

Sie können nun Änderungen an den Richtlinien im Repository speichern. Wenn Sie diese Commits in Ihr vorgelagertes Repository (Ursprung) übertragen, sorgt Config Sync dafür, dass die Änderungen auf den Cluster angewendet werden, für den Sie es konfiguriert haben.

Richtlinie zum Verschlüsseln des gesamten Diensttraffics aktualisieren

Die Konfiguration für Cloud Service Mesh wird mithilfe von YAML-Dateien deklarativ angegeben. Um den gesamten Diensttraffic zu verschlüsseln, müssen Sie sowohl die YAML-Datei mit den Traffictypen ändern, die von den Diensten angenommen werden können und die YAML-Datei, die den Typ des Traffics angibt, den Dienste an bestimmte Ziele senden.

1. Die erste YAML-Datei, die Sie sich vornehmen müssen, ist namespaces/istio-system/peer-authentication.yaml. Dabei handelt es sich um eine Authentifizierungsrichtlinie auf Mesh-Ebene, die angibt, welche Traffictypen alle Dienste in Ihrem Mesh-Netzwerk standardmäßig akzeptieren.

   cat namespaces/istio-system/peer-authentication.yaml
   

   Ausgabe:

   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: PERMISSIVE
   

   Wie Sie sehen, ist der PeerAuthentication-mTLS-Modus PERMISSIVE. Dies bedeutet, dass Dienste sowohl Klartext- als auch mTLS-Traffic akzeptieren.

2. Ändern Sie namespaces/istio-system/peer-authentication.yaml so, dass nur verschlüsselte Kommunikation zwischen Diensten zulässig ist. Dazu setzen Sie den mTLS-Modus auf STRICT:

   cat <<EOF> namespaces/istio-system/peer-authentication.yaml
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "default"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

3. Sehen Sie sich als Nächstes die Zielregel in namespaces/istio-system/destination-rule.yaml an. Damit werden Regeln zum Senden von Traffic an die angegebenen Ziele angegeben, einschließlich der Frage, ob der Traffic verschlüsselt ist. Der TLSmode lautet DISABLE. Das bedeutet, dass Traffic als Klartext an alle übereinstimmenden Hosts gesendet wird.

   cat namespaces/istio-system/destination-rule.yaml
   

   Ausgabe:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

4. Ändern Sie namespaces/istio-system/destination-rule.yaml so, dass Istio eine Trafficrichtlinie festlegt, die TLS für alle übereinstimmenden Hosts im Cluster mit dem TLS-Modus ISTIO_MUTUAL aktiviert:

   cat <<EOF> namespaces/istio-system/destination-rule.yaml
   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     annotations:
       meshsecurityinsights.googleapis.com/generated: "1561996419000000000"
     name: default
     namespace: istio-system
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

Änderungen per Push in das Repository übertragen

Sie sind fast bereit, Ihre Konfigurationsänderungen zu übertragen. Wir empfehlen Ihnen jedoch, ein paar Prüfungen durchzuführen, bevor Sie mit dem Commit der Updates fortfahren.

1. Führen Sie nomos vet aus, um sicherzustellen, dass Ihre Konfiguration gültig ist:

   nomos vet
   

   Keine Ausgabe bedeutet, dass keine Validierungsfehler aufgetreten sind.

2. Sobald Sie Ihre Änderungen per Push übertragen, übernimmt Config Sync sie und wendet sie auf Ihr System an. Um unerwartete Ergebnisse zu vermeiden, sollten Sie prüfen, ob sich der aktuelle Live-Status Ihrer Konfiguration seit der Bearbeitung geändert hat. Prüfen Sie mit kubectl, ob destinationrule angibt, dass mTLS für den Cluster deaktiviert ist:

   kubectl get destinationrule default -n istio-system -o yaml
   

   Ausgabe:

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   ...
   spec:
     host: '*.local'
     trafficPolicy:
       tls:
         mode: DISABLE
   

3. Führen Sie nun ein Commit und das Hochladen der Änderungen in das vorgelagerte Repository durch. Der folgende Befehl verwendet eine Hilfsfunktion mit dem Namen watchmtls, die vom Skript init in Ihre Umgebung übergeben wurde. Diese Hilfsfunktion führt eine Kombination aus nomos status und dem kubectl-Befehl aus, den Sie zuvor ausprobiert haben. Es prüft den Cluster auf Veränderungen, bis Sie Ctrl+C gedrückt halten, um ihn zu beenden. Beobachten Sie die Anzeige, bis Sie sehen, dass die Änderungen auf dem Cluster angewendet und synchronisiert werden.

   git commit -am "enable mtls"
   git push origin master && watchmtls
   

   Sie können die Änderungen auch auf den Cloud Service Mesh-Seiten unter GKE Enterprise aufrufen.

   Zur Seite „Cloud Service Mesh“

   Es sollte jetzt das rote Schlosssymbol Entsperrt angezeigt werden. Das Schlosssymbol wird orange (gemischt) angezeigt und nicht grün (vollständig verschlüsselter Traffic), da wir standardmäßig in der letzten Stunde mit einer Mischung aus mTLS und Klartext suchen. Wenn Sie die Seite nach einer Stunde noch einmal prüfen, sollten Sie ein grünes Schloss sehen, das anzeigt, dass Sie den gesamten Diensttraffic erfolgreich verschlüsselt haben.

Mit "Policy Controller" Sicherheitsmechanismen einrichten

Ihr Sicherheitsteam ist besorgt über potenzielle Root-Angriffe, die auftreten können, wenn Pods mit privilegierten Containern ausgeführt werden (Container mit Root-Zugriff). Während die aktuelle Konfiguration keine privilegierten Container bereitstellt, sollten Sie so viele Bedrohungsvektoren wie möglich schützen, die die Leistung beeinträchtigen oder sogar Kundendaten beeinträchtigen.

Trotz der Sorgfalt des Teams besteht weiterhin das Risiko, dass Sie im Rahmen zukünftiger Konfigurationsaktualisierungen durch den Continuous Delivery-Prozess anfällig für Root-Angriffe sind. Sie beschließen, einen Sicherheitsmechanismus einzurichten, der Schutz vor dieser Gefahr ermöglicht.

Sicherheitsmaßnahmen anwenden

Guardrails sind automatisierte administrative Steuerelemente, mit denen Richtlinien erzwungen werden können, um Ihre Umgebung zu schützen. Policy Controller bietet Unterstützung für das Definieren und Durchsetzen benutzerdefinierter Regeln, die nicht durch native Kubernetes-Objekte abgedeckt werden. Mit dem Policy Controller werden Prüfungen, Audits und Durchsetzungsmechanismen geprüft, die den speziellen Sicherheits-, behördlichen und organisatorischen Anforderungen Ihrer Organisation entsprechen.

Policy Controller verwenden

Policy Controller basiert auf einer Open-Source-Richtlinien-Engine namens Gatekeeper, die jedes Mal zum Erzwingen von Richtlinien verwendet wird, wenn eine Ressource im Cluster erstellt, aktualisiert oder gelöscht wird. Diese Richtlinien werden mithilfe von Einschränkungen aus der Vorlagenbibliothek "Policy Controller" oder anderen Gatekeeper-Einschränkungsvorlagen definiert.

Für das Anthos-Beispiel-Deployment in Google Cloud ist Policy Controller bereits installiert und die Vorlagenbibliothek "Policy Controller" ist aktiviert. Sie können diese Vorgehensweise bei der Implementierung Ihres Sicherheitsmechanismus nutzen, indem Sie eine vorhandene Einschränkung für privilegierte Container aus der Bibliothek verwenden.

Richtlinieneinschränkung für privilegierte Container anwenden

Zur Behebung des Problems Ihres Sicherheitsteams wenden Sie die Einschränkung K8sPSPPrivilegedContainer an. Durch diese Einschränkung wird verhindert, dass Pods mit privilegierten Containern ausgeführt werden.

1. Erstellen Sie im Cloud Shell-Terminal eine neue constraint.yaml-Datei mit dem Text aus der Bibliothekseinschränkung:

   cat <<EOF> ~/tutorial/anthos-sample-deployment-config-repo/cluster/constraint.yaml
   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: K8sPSPPrivilegedContainer
   metadata:
     name: psp-privileged-container
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pod"]
       excludedNamespaces: ["kube-system"]
   EOF
   

2. Prüfen Sie mit nomos vet, ob die aktualisierte Konfiguration gültig ist, bevor Sie sie anwenden.

   nomos vet
   

   Der Befehl wird ohne Rückmeldung zurückgegeben, solange keine Fehler vorliegen.

3. Übernehmen Sie die Änderungen per Commit und übertragen Sie sie, um die Richtlinie anzuwenden. Sie können nomos status mit dem Befehl watch verwenden, um zu prüfen, ob die Änderungen auf den Cluster angewendet werden. Drücken Sie Ctrl+C, um den Wiedergabebefehl zu beenden, wenn Sie fertig sind.

   git add .
   git commit -m "add policy constraint for privileged containers"
   git push && watch nomos status
   

   Ausgabe:

   Connecting to clusters...
   Current   Context                  Sync Status  Last Synced Token   Sync Branch   Resource Status
   -------   -------                  -----------  -----------------   -----------   ---------------
   *         anthos-sample-cluster1   SYNCED       f2898e92            master        Healthy
   

Richtlinie testen

Nachdem Sie die Richtlinie angewendet haben, können Sie sie testen, indem Sie versuchen, einen Pod mit einem privilegierten Container auszuführen.

1. Erstellen Sie im Cloud Shell-Terminal mit dem folgenden Befehl eine neue Datei im Verzeichnis der Anleitung, nginx-privileged.yaml, mit den Inhalten von diese Beispielspezifikation:

   cat <<EOF> ~/tutorial/nginx-privileged.yaml
   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-privileged-disallowed
     labels:
       app: nginx-privileged
   spec:
     containers:
     - name: nginx
       image: nginx
       securityContext:
         privileged: true
   EOF
   

2. Versuchen Sie, den Pod mit kubectl apply zu starten.

   kubectl apply -f ~/tutorial/nginx-privileged.yaml
   

   Ausgabe:

   Error from server ([denied by psp-privileged-container] Privileged container is not allowed: nginx, securityContext: {"privileged": true}): error when creating "~/nginx-privileged.yaml": admission webhook "validation.gatekeeper.sh" denied the request: [denied by psp-privileged-container] Privileged container is not allowed: nginx, security
   Context: {"privileged": true}
   

   Der Fehler zeigt, dass der Gatekeeper-Admission-Controller, der Ihre Kubernetes-Umgebung prüft, Ihre neue Richtlinie erzwungen hat. Die Ausführung des Pods wurde verhindert, da ein privilegierter Container in der Pod-Spezifikation vorhanden war.

Das Konzept der versionsgesteuerten Richtlinien, die Sie zur Einrichtung von Sicherheitsmechanismen mit Policy Controller anwenden können, ist eine leistungsfähige Maßnahme, da die Governance Ihrer Cluster standardisiert, vereinheitlicht und zentralisiert wird und Ihre Richtlinien über ein aktives Monitoring der Umgebung nach der Bereitstellung erzwungen werden.

Im Gatewaykeeper-Repository finden Sie viele weitere Arten von Richtlinien, die Sie als Sicherheitsmechanismen für Ihre Umgebung verwenden können.

Weitere Informationen zum Deployment

In dieser Anleitung haben Sie gelernt, wie Sie mit einigen GKE Enterprise-Sicherheitsfunktionen arbeiten können. In unserem Deployment gibt es aber noch viel mehr in GKE Enterprise zu sehen und zu tun. Sie können auch eine weitere Anleitung ausprobieren oder das Anthos-Beispiel-Deployment selbst in Google Cloud weiter kennenlernen, bevor Sie im nächsten Abschnitt die Bereinigungsanleitung befolgen.

Bereinigen

Nachdem Sie sich mit der Bank of Anthos-Anwendung vertraut gemacht haben, können Sie die in Google Cloud erstellten Ressourcen bereinigen, damit sie keine Kontingente verbrauchen und Sie dafür nicht künftig zahlen müssen.

• Option 1: Sie können das Projekt löschen. Wenn Sie das Projekt jedoch behalten möchten, können Sie das Deployment mit Option 2 löschen.

• Option 2: Wenn Sie Ihr aktuelles Projekt behalten möchten, können Sie die Beispielanwendung und den Beispielcluster mit terraform destroy löschen.

Projekt löschen (Option 1)

Sie vermeiden weitere Kosten am einfachsten, wenn Sie das für die Anleitung erstellte Projekt löschen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Bereitstellung löschen (Option 2)

Bei diesem Ansatz werden die Bank of Anthos-Anwendung und der Cluster gelöscht, aber nicht das Projekt. Führen Sie die folgenden Befehle in Ihrer Cloud Shell aus:

1. Wechseln Sie in das Verzeichnis, in dem die Installationsscripts gehostet werden:

   cd bank-of-anthos/iac/tf-anthos-gke
   

2. Löschen Sie das Beispiel und den Cluster:

   terraform destroy
   

3. Geben Sie die Projekt-ID ein, wenn Sie dazu aufgefordert werden.

Wenn Sie ein neues Deployment vornehmen möchten, prüfen Sie, ob alle Anforderungen wie im Abschnitt Vorbereitung beschrieben erfüllt sind.

Nächste Schritte

In unserer GKE Enterprise-Dokumentation gibt es noch viel mehr zu entdecken.

Weitere Anleitungen ausprobieren

• Informationen zur Dienstverwaltung mit dem Anthos-Beispiel-Deployment finden Sie unter Dienste mit GKE Enterprise verwalten.

• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center

Weitere Informationen zu GKE Enterprise

• Weitere Informationen zu GKE Enterprise finden Sie in unserer Technische Übersicht.

• Informationen zum Einrichten von GKE Enterprise in einer echten Produktionsumgebung finden Sie in unserer Einrichtungsanleitung.

• Weitere Informationen zu Cloud Service Mesh finden Sie in der Dokumentation zu Cloud Service Mesh.

• Weitere Informationen zum Policy Controller finden Sie in der Policy Controller-Richtlinie.

• Weitere Informationen zur deklarativen, zentralisierten Konfiguration und Richtlinienverwaltung finden Sie in der Config Sync-Dokumentation und in der Dokumentation zu Policy Controller.