Diese Seite wurde von der Cloud Translation API übersetzt.

Anleitung: GKE Enterprise sichern

GKE Enterprise bietet eine einheitliche Plattform zum Erstellen und Bereitstellen von sicheren Diensten mit integrierten Sicherheitsfunktionen auf jeder Ebene, die separat und zusammenwirken, um einen umfassenden Schutz vor Sicherheitsproblemen zu bieten. In dieser Anleitung werden einige der leistungsstarken Sicherheitsfeatures von GKE Enterprise mithilfe des Anthos-Beispiel-Deployments in Google Cloud vorgestellt. Das Anthos-Beispiel-Deployment stellt eine echte GKE Enterprise-Umgebung mit einem GKE-Cluster, Service Mesh und einer Bank of GKE Enterprise-Anwendung mit mehreren Mikrodiensten bereit.

Lernziele

In dieser Anleitung werden Sie durch die folgenden Aufgaben in einige der Sicherheitsfeatures von GKE Enterprise eingeführt:

Erzwingen Sie mit Config Sync die gegenseitige TLS (mTLS) in Ihrem Service Mesh, um für eine sichere Ende-zu-Ende-Kommunikation zu sorgen.
Richten Sie einen Sicherheitsvorkehrung ein, der dafür sorgt, dass Pods mit privilegierten Containern nicht versehentlich mit Policy Controller bereitgestellt werden.

Kosten

Für die Bereitstellung der Bank of Anthos-Anwendung fallen „Pay as you go“-Gebühren für GKE Enterprise in Google Cloud an, wie auf unserer Preisseite aufgeführt, es sei denn, Sie haben bereits ein Abo erworben.

Außerdem müssen Sie für andere Google Cloud-Kosten verantwortlich sein, die beim Ausführen der Bank of Anthos-Anwendung anfallen, 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:
Legt den Kubernetes-Kontext für anthos-sample-cluster1 fest
Es klont das Repository, das Config Sync zum Synchronisieren Ihrer Konfigurationsänderungen mit Ihrem Cluster verwendet. Änderungen, die Sie per Commit durchführen und in das Upstream-Repository übertragen, werden durch Config Sync mit Ihrer Infrastruktur synchronisiert. Dies ist die empfohlene Vorgehensweise, um Änderungen an der Infrastruktur anzuwenden.

So richten Sie Ihre Umgebung ein:

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.
Erstellen Sie ein Arbeitsverzeichnis:
```
mkdir tutorial
cd tutorial
```

Laden Sie das Initialisierungsskript herunter:

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

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

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?

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

Zur Seite "Anthos Service Mesh"
Klicken Sie in der Liste der Dienste auf transactionhistory. Wie Sie unter GKE Enterprise kennenlernen gesehen haben, enthält die Seite mit den Dienstdetails alle für diesen Dienst verfügbaren Telemetriedaten.
Wählen Sie auf der Seite transactionhistory im Menü Navigation die Option Verbundene Dienste 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 Anthos Service Mesh deutlich, dass in Ihrem Mesh unverschlüsselter Traffic vorhanden ist. In Anthos 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 Sie in wenigen Schritten von der Compliance entfernt. Anstatt Änderungen auf Quellcodeebene vorzunehmen und die Anwendung neu zu erstellen und noch einmal bereitzustellen, können Sie die neue Verschlüsselungsrichtlinie deklarativ über die Konfiguration anwenden. Dazu verwenden Sie Config Sync, um die neue Konfiguration automatisch über ein zentrales Git-Repository bereitzustellen.

In diesem Abschnitt tun Sie Folgendes:

Sie passen die Richtlinienkonfiguration in Ihrem Git-Repository an, um zu erzwingen, dass Dienste verschlüsselte Kommunikation über mTLS verwenden.
Config Sync kann die Richtlinienänderung automatisch aus dem Repository übernehmen und die Anthos Service Mesh-Richtlinie anpassen.
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

Der Befehl nomos ist ein Befehlszeilentool, mit dem Sie mit dem Config Management-Operator interagieren und andere nützliche Config Sync-Aufgaben von Ihrem lokalen Computer oder von Cloud Shell aus ausführen können. Führen Sie nomos status aus, um zu prüfen, ob Config Sync auf Ihrem Cluster ordnungsgemäß installiert und konfiguriert ist:
```
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 für die Synchronisierung Ihres Clusters mit dem Master-Branch Ihres Konfigurations-Repositorys konfiguriert ist. 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".
```

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'.

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)

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 user@example.com
Configured local git user.name to user
```

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

Richtlinie zum Verschlüsseln des gesamten Diensttraffics aktualisieren

Die Konfiguration für Anthos 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.

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.

Ä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

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
```

Ä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.

Führen Sie nomos vet aus, um sicherzustellen, dass Ihre Konfiguration gültig ist:
```
nomos vet
```
Keine Ausgabe bedeutet, dass keine Validierungsfehler aufgetreten sind.
Sobald Sie Ihre Änderungen übertragen haben, werden sie von Config Sync übernommen und auf Ihr System angewendet. 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
```
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
```
Die Änderungen werden auch auf den Anthos Service Mesh-Seiten in GKE Enterprise angezeigt.

Zur Seite "Anthos 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.

Sicherheitsmechanismen anwenden

Guardrails sind automatisierte administrative Steuerelemente, mit denen Richtlinien erzwungen werden können, um Ihre Umgebung zu schützen. Policy Controller unterstützt das Definieren und Erzwingen benutzerdefinierter Regeln, die nicht von nativen Kubernetes-Objekten abgedeckt werden. Policy Controller prüft, prüft und erzwingt Sicherheitsvorkehrungen, die Sie anwenden, die den besonderen Anforderungen Ihrer Organisation in puncto Sicherheit, Compliance und Governance entsprechen.

Policy Controller verwenden

Policy Controller basiert auf einer Open-Source-Richtlinien-Engine namens Gatekeeper, mit der jedes Mal Richtlinien erzwungen werden, 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.

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

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.

Ü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.

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

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 zum Einrichten von Schutzmaßnahmen mit Policy Controller anwenden können, ist ein leistungsstarkes Konzept, da es die Governance Ihrer Cluster standardisiert, vereinheitlicht und zentralisiert, um Ihre Richtlinien nach der Bereitstellung durch aktives Monitoring der Umgebung zu erzwingen.

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

Während dieser Anleitung Ihnen gezeigt wurde, wie Sie mit einigen Sicherheitsfunktionen von GKE Enterprise arbeiten, gibt es in GKE Enterprise noch viel mehr 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 Ressourcen bereinigen, die Sie in Google Cloud erstellt haben, damit diese kein Kontingent verbrauchen und Ihnen in Zukunft nicht in Rechnung gestellt werden.

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)

Kosten lassen sich am einfachsten vermeiden, wenn Sie das für diese 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.

Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
Zur Seite „Ressourcen verwalten“
Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Bereitstellung löschen (Option 2)

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

Wechseln Sie in das Verzeichnis, in dem die Installationsskripts gehostet werden:
```
cd bank-of-anthos/iac/tf-anthos-gke
```
Löschen Sie das Beispiel und den Cluster:
```
terraform destroy
```
Geben Sie die Projekt-ID ein, wenn Sie dazu aufgefordert werden.

Wenn Sie die Bereitstellung noch einmal planen, prüfen Sie, ob alle Anforderungen erfüllt sind, wie im Abschnitt Vorbereitung beschrieben.

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 technischen Übersicht.
In unserem Einrichtungsleitfaden erfahren Sie, wie Sie GKE Enterprise in einer echten Produktionsumgebung einrichten.
Weitere Informationen zu Anthos Service Mesh finden Sie in der Anthos Service Mesh-Dokumentation.
Weitere Informationen zum Policy Controller finden Sie in der Policy Controller-Richtlinie.
Weitere Informationen zur deklarativen, zentralisierten Konfigurations- und Richtlinienverwaltung finden Sie in der Dokumentation zu Config Sync und in der Dokumentation zu Policy Controller.