Sicherheit Ihres Clusters erhöhen

Autopilot Standard

---

Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfeatures zur Verfügung. Auf dieser Seite werden Sie durch die Implementierung unserer aktuellen Anleitung zum Härten Ihres Google Kubernetes Engine-Clusters (GKE) geführt.

In diesem Leitfaden werden vor allem wichtige Sicherheitsmaßnahmen behandelt, die eine Aktion des Kunden zum Zeitpunkt der Clustererstellung erfordern. Weniger zentrale Features, sichere Standardeinstellungen sowie Einstellungen, die nach der Erstellung aktiviert werden können, werden weiter unten in diesem Dokument behandelt. Einen allgemeinen Überblick über Sicherheitsthemen finden Sie unter Übersicht über die Sicherheit.

Hinweis: Wenn Sie neue Cluster in GKE erstellen, sind viele dieser Sicherheitsfunktionen standardmäßig aktiviert. Wenn Sie Aktualisierungen für bestehende Cluster ausführen, sollten Sie diesen Leitfaden zur Härtung regelmäßig auf neue Features prüfen und diese aktivieren.

Im Autopilot-Modus erstellte Cluster implementieren standardmäßig viele GKE-Härtungsfeatures.

Viele dieser Empfehlungen sowie andere häufige Fehlkonfigurationen können mithilfe von Sicherheitsintegritäts-Analysen automatisch überprüft werden.

Wenn sich die folgenden Empfehlungen auf eine CIS-GKE-Benchmark-Empfehlung beziehen, wird das angegeben.

Upgrades der GKE-Infrastruktur zeitnah ausführen

CIS-GKE-Benchmark-Empfehlung: 6.5.3. Automatische Knotenupgrades für GKE-Knoten sollten aktiviert sein

Die einfachste Methode zur Verbesserung der Sicherheit besteht darin, immer die neueste Kubernetes-Version zu verwenden. Kubernetes führt häufig neue Sicherheitsfunktionen ein und bietet Sicherheitspatches.

Weitere Informationen zu Sicherheitspatches finden Sie unter GKE-Sicherheitsbulletins.

In Google Kubernetes Engine werden die Steuerungsebenen automatisch repariert und aktualisiert. Durch die automatische Knotenaktualisierung werden auch die Knoten automatisch auf den neuesten Stand gebracht.

Hinweis: Die automatische Knotenaktualisierung ist standardmäßig für Cluster aktiviert, die ab Juni 2019 mit der Google Cloud Console erstellt wurden, und für Cluster, die ab dem 11. November 2019 mit der API erstellt wurden.

Wenn Sie die automatische Aktualisierung des Knotens deaktivieren, sollten Sie nach eigenem Zeitplan monatlich aktualisieren. Für ältere Cluster wird empfohlen, die automatische Knotenaktualisierung zu aktivieren und die GKE-Sicherheitsbulletins für kritische Patches aufmerksam zu verfolgen.

Weitere Informationen finden Sie unter Knoten automatisch aktualisieren.

Netzwerkzugang zu Steuerungsebene und Knoten beschränken

CIS-GKE-Benchmark-Empfehlungen: 6.6.2. VPC-native Cluster werden bevorzugt, 6.6.3. Autorisierte Masternetzwerke sollten aktiviert sein, 6.6.4. Cluster sollten mit aktiviertem privatem Endpunkt und deaktiviertem öffentlichem Zugriff erstellt werden, und 6.6.5. Cluster sollten mit privaten Knoten erstellt werden

Sie sollten die Sichtbarkeit der Steuerungsebene und Knoten Ihres Clusters im Internet beschränken. Diese Einstellungen können nur zum Zeitpunkt der Clustererstellung festgelegt werden.

Standardmäßig haben die Steuerungsebene und Knoten des GKE-Clusters routingfähige Internetadressen, auf die von jeder IP-Adresse aus zugegriffen werden kann.

Informationen zur Steuerungsebene des GKE-Clusters finden Sie unter Private Cluster einrichten. Es gibt drei verschiedene Arten von privaten Clustern, die Schutz auf Netzwerkebene bieten:

• Zugriff auf öffentliche Endpunkte deaktiviert: Dies ist die sicherste Option, da dadurch der gesamte Internetzugriff auf Steuerungsebenen und Knoten verhindert wird. Dieser Schutz ist zu empfehlen, wenn Sie Ihr lokales Netzwerk so konfiguriert haben, dass mit Cloud Interconnect und Cloud VPN eine Verbindung zu Google Cloud hergestellt wird. Diese Technologien verbinden Ihr Unternehmensnetzwerk effizient mit Ihrem Cloud VPC.
• Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke aktiviert (empfohlen): Diese Option bietet eingeschränkten Zugriff auf die Steuerungsebene über von Ihnen definierte Quell-IP-Adressen. Diese Option ist zu empfehlen, wenn Sie keine bestehende VPN-Infrastruktur haben oder Road Warriors bzw. Zweigstellen vorhanden sind, die über das öffentliche Internet statt über das Unternehmens-VPN sowie Cloud Interconnect oder Cloud VPN eine Verbindung herstellen.
• Zugriff auf öffentliche Endpunkte aktiviert; autorisierte Netzwerke deaktiviert: Dies ist die Standardeinstellung. Sie ermöglicht allen Internetnutzern, Netzwerkverbindungen zur Steuerungsebene herzustellen.

Zur Deaktivierung des direkten Internetzugriffs auf Knoten geben Sie beim Erstellen des Clusters die gcloud CLI-Option „--enable-private-nodes“ an.

Damit wird GKE angewiesen, Knoten mit internen IP-Adressen bereitzustellen, d. h., die Knoten sind nicht direkt über das öffentliche Internet erreichbar.

Wir empfehlen für Cluster mindestens autorisierte Netzwerke und private Knoten zu verwenden. Damit wird sichergestellt, dass die Steuerungsebene in folgender Weise erreichbar ist:

• Über die zulässigen CIDRs in autorisierten Netzwerken
• Über Knoten in der VPC des Clusters
• Über interne Google-Produktionsjobs, die Ihre Steuerungsebene verwalten

Dies entspricht den im Folgenden aufgeführten gcloud-Flags bei der Clustererstellung:

• --enable-ip-alias
• --enable-private-nodes
• --enable-master-authorized-networks

Firewallregeln mit geringsten Berechtigungen verwenden

Minimieren Sie das Risiko eines unbeabsichtigten Zugriffs mithilfe des Prinzips der geringsten Berechtigung für Firewallregeln

GKE erstellt Standard-VPC-Firewallregeln, um Systemfunktionen zu aktivieren und gute Sicherheitspraktiken zu erzwingen. Eine vollständige Liste der automatisch erstellten Firewallregeln finden Sie unter Automatisch erstellte Firewallregeln.

GKE erstellt diese Standard-Firewallregeln mit der Priorität 1.000. Wenn Sie freie Firewallregeln mit einer höheren Priorität erstellen, z. B. eine allow-all-Firewallregel für das Debugging, besteht das Risiko eines unbeabsichtigten Clusters.

Wenn Sie Firewallregeln erstellen, verwenden Sie das Prinzip der geringsten Berechtigung, um Zugriff nur für den erforderlichen Zweck zu gewähren. Achten Sie darauf, dass Ihre Firewallregeln nicht mit den GKE-Standardfirewallregeln in Konflikt stehen.

Gruppenauthentifizierung

CIS-GKE-Benchmark-Empfehlung: 6.8.3. Kubernetes-RBAC-Nutzer mit Google Groups für RBAC verwalten

Sie sollten Ihre Nutzer mit Gruppen verwalten. Mithilfe von Gruppen können Identitäten über Ihr Identitätsverwaltungssystem und Ihre Identitätsadministratoren gesteuert werden. Für die Anpassung der Gruppenmitgliedschaft müssen Sie dann nicht mehr Ihre RBAC-Konfiguration aktualisieren, wenn jemand der Gruppe hinzugefügt oder daraus entfernt wird.

Zur Verwaltung von Nutzerberechtigungen mit Google Groups müssen Sie Google Groups for RBAC in Ihrem Cluster aktivieren. Damit können Sie Nutzer mit gleichen Berechtigungen auf einfache Weise verwalten, während Ihre Identitätsadministratoren die Möglichkeit haben, Nutzer zentral und einheitlich zu verwalten.

Eine Anleitung zum Aktivieren von Google Groups for RBAC finden Sie unter Google Groups für RBAC.

Möglichkeiten für Containerknoten

In den folgenden Abschnitten werden mögliche Konfiguration sicherer Knoten beschrieben.

Shielded GKE-Knoten aktivieren

CIS-GKE-Benchmark-Empfehlung: 6.5.5. Shielded GKE-Knoten sollten aktiviert sein

Shielded GKE-Knoten bieten eine starke, nachprüfbare Knotenidentität und -integrität, die die Sicherheit von GKE-Knoten erhöhen. Sie sollten für alle GKE-Cluster aktiviert werden.

Sie können Shielded GKE-Knoten beim Erstellen oder Aktualisieren von Clustern aktivieren. Shielded GKE-Knoten müssen mit Secure Boot aktiviert werden. Secure Boot sollte allerdings nicht verwendet werden, wenn Sie unsignierte Kernelmodule von Drittanbietern benötigen. Eine Anleitung zum Aktivieren von Shielded GKE-Knoten und zum Aktivieren des sicheren Starts mit Shielded GKE-Knoten finden Sie unter Shielded GKE-Knoten verwenden.

Gehärtetes Knoten-Image mit der containerd-Laufzeit auswählen

Das Container-Optimized OS mit containerd-Image (cos_containerd) ist eine Variante des Container-Optimized OS-Image mit containerd als Haupt-Container-Laufzeit, die direkt in Kubernetes eingebunden ist.

containerd ist die zentrale Laufzeitkomponente von Docker. Sie wurde entwickelt, um Kerncontainerfunktionen für das Container Runtime Interface (CRI) von Kubernetes bereitstellen zu können. Sie ist wesentlich weniger komplex als der vollständige Docker-Daemon und bietet so nur eine reduzierte Angriffsfläche.

Informationen zur Verwendung des Images cos_containerd in Ihrem Cluster finden Sie unter Container-Images.

Das cos_containerd-Image ist das bevorzugte Image für GKE, da es speziell für die Ausführung von Containern erstellt, optimiert und gehärtet wurde.

Identitätsföderation von Arbeitslasten für GKE aktivieren

CIS-GKE-Benchmark-Empfehlung: 6.2.2. Dedizierte Google Cloud-Dienstkonten und Workload Identity verwenden

Workload Identity Federation for GKE ist die empfohlene Methode zur Authentifizierung bei Google Cloud APIs.

Workload Identity Federation for GKE macht die Verwendung der Metadatenverbergung überflüssig. Daher sind diese beiden Ansätze nicht kompatibel. Die vertraulichen Metadaten, die durch Metadatenverbergung geschützt werden, werden durch Workload Identity Federation for GKE ebenfalls geschützt.

Isolierung von Arbeitslasten mit GKE Sandbox härten

CIS-GKE-Benchmark-Empfehlung: 6.10.4. Ziehen Sie eventuell GKE Sandbox in Betracht, um die Isolierung von Arbeitslasten zu härten, insbesondere für nicht vertrauenswürdige Arbeitslasten.

Mithilfe einer zusätzlichen Sicherheitsebene verhindert GKE Sandbox, dass der Hostkernel auf Ihren Clusterknoten durch schädlichen Code beeinträchtigt wird.

Sie können Container in einer Sandbox-Umgebung ausführen, um die meisten Container-Escape-Angriffe, auch lokale Privilegienerweiterungsangriffe genannt, zu minimieren. Sicherheitslücken bei Containern in der Vergangenheit finden Sie in den Sicherheitsbulletins. Diese Art von Angriff ermöglicht einem Angreifer Zugriff auf die Host-VM des Containers und somit auf andere Container auf derselben VM. Eine Sandbox wie GKE Sandbox kann die Auswirkungen dieser Angriffe begrenzen.

In Situationen wie diesen sollten Sie das Ausführen von Arbeitslasten in einer Sandbox in Betracht ziehen:

• Die Arbeitslast führt nicht vertrauenswürdigen Code aus.
• Sie möchten die Auswirkungen begrenzen, wenn ein Angreifer einen Container in der Arbeitslast manipuliert.

Informationen zur Verwendung von GKE Sandbox finden Sie unter Isolierung von Arbeitslasten mit GKE Sandbox härten.

Sicherheitsbulletin-Benachrichtigungen aktivieren

Wenn Sicherheitsbulletins verfügbar sind, die für Ihren Cluster relevant sind, veröffentlicht GKE Benachrichtigungen zu diesen Ereignissen als Nachrichten in Pub/Sub-Themen, die Sie konfigurieren. Sie können diese Benachrichtigungen für ein Pub/Sub-Abo erhalten, den Dienst von Drittanbietern einbinden und nach den Benachrichtigungstypen filtern, die Sie erhalten möchten.

Weitere Informationen zum Empfangen von Sicherheitsbulletins mit GKE-Cluster-Benachrichtigungen finden Sie unter Cluster-Benachrichtigungen.

Berechtigungen

IAM-Dienstkonten mit Mindestberechtigung verwenden

CIS-GKE-Benchmark-Empfehlung: 6.2.1. GKE-Cluster nicht mit dem Compute Engine-Standarddienstkonto ausführen

Jedem GKE-Knoten ist ein IAM-Dienstkonto (Identity and Access Management) zugeordnet. Standardmäßig wird Knoten das Compute Engine-Standarddienstkonto zugewiesen. Sie finden das Konto im IAM-Bereich der Cloud Console. Dieses Konto hat standardmäßig einen weiten Zugriff und ist daher für eine Vielzahl von Anwendungen nützlich. Ihm sind jedoch mehr Berechtigungen zugewiesen, als für die Ausführung des Kubernetes Engine-Clusters erforderlich sind. Sie sollten ein Dienstkonto mit minimalen Berechtigungen erstellen, das Ihre Knoten anstelle des Compute Engine-Standarddienstkontos verwenden können.

Aufgrund der Einführung von Workload Identity Federation for GKE empfehlen wir einen eingeschränkteren Anwendungsfall für das Knotendienstkonto. Wir gehen davon aus, dass das Knotendienstkonto von System-Daemons verwendet wird, die für Logging, Monitoring und ähnliche Aufgaben zuständig sind. Arbeitslasten in Pods sollten stattdessen Identitäten mit Workload Identity Federation for GKE erhalten.

Für GKE müssen dem Dienstkonto mindestens die Rollen monitoring.viewer, monitoring.metricWriter, logging.logWriter, stackdriver.resourceMetadata.writer und autoscaling.metricsWriter zugewiesen sein. Hier erfahren Sie mehr über Monitoring-Rollen und Logging-Rollen.

Hinweis: Zum Bearbeiten von IAM-Richtlinien müssen Sie die Cloud Resource Manager API in Ihrem Projekt aktivieren:

gcloud services enable cloudresourcemanager.googleapis.com

Anhand der folgenden Befehle wird ein IAM-Dienstkonto mit den zum Ausführen von GKE erforderlichen Mindestberechtigungen erstellt. Sie können das Dienstkonto auch für Ressourcen in anderen Projekten verwenden. Eine Anleitung finden Sie unter Identitätswechsel für Dienstkonten über Projekte hinweg aktivieren.

gcloud

gcloud iam service-accounts create SA_NAME \
    --display-name=DISPLAY_NAME

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/logging.logWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.metricWriter

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/monitoring.viewer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/stackdriver.resourceMetadata.writer

gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
    --role roles/autoscaling.metricsWriter

Dabei gilt:

• SA_NAME ist der Name des neuen Dienstkontos.
• DISPLAY_NAME ist der Anzeigename für das neue Dienstkonto, damit das Konto leichter identifiziert werden kann.
• PROJECT_ID ist die Projekt-ID des Projekts, in dem Sie das neue Dienstkonto erstellen möchten.

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

1. Laden Sie zum Erstellen des Dienstkontos die folgende Ressource als service-account.yaml herunter.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMServiceAccount
   metadata:
     name: [SA_NAME]
   spec:
     displayName: [DISPLAY_NAME]

   Ersetzen Sie Folgendes:

   • SA_NAME ist der Name des neuen Dienstkontos.
   • DISPLAY_NAME ist der Anzeigename für das neue Dienstkonto, damit das Konto leichter identifiziert werden kann.

   Führen Sie dann diesen Befehl aus:

   kubectl apply -f service-account.yaml

2. Wenden Sie die Rolle logging.logWriter auf das Dienstkonto an. Laden Sie die folgende Ressource als Datei policy-logging.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-logging
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/logging.logWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-logging.yaml

3. Wenden Sie die Rolle monitoring.metricWriter an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-metrics-writer.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-metrics-writer
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/monitoring.metricWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-metrics-writer.yaml

4. Wenden Sie die Rolle monitoring.viewer an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-monitoring.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-monitoring
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/monitoring.viewer
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-monitoring.yaml

5. Wenden Sie die Rolle autoscaling.metricsWriter an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-autoscaling-metrics-writer.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-autoscaling-metrics-writer
   spec:
     member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
     role: roles/autoscaling.metricsWriter
     resourceRef:
       kind: Project
       name: [PROJECT_ID]

   kubectl apply -f policy-autoscaling-metrics-writer.yaml

Zugriff auf private Image-Repositories gewähren

Wenn Sie private Images in Artifact Registry verwenden möchten, weisen Sie dem Dienstkonto die Rolle „Artifact Registry-Leser“ (roles/artifactregistry.reader) zu.

gcloud

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Ersetzen Sie dabei REPOSITORY_NAME durch den Namen Ihres Artifact Registry-Repositorys.

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

Hinweis: Bei diesen Schritten wird davon ausgegangen, dass Sie Config Connector zur Verwaltung Ihres Artifact Registry-Repositorys verwenden. Wenn Ihr Repository nicht als Config Connector-Ressource vorhanden ist, funktionieren diese Schritte nicht.

1. Speichern Sie das folgende Manifest als policy-artifact-registry-reader.yaml:

   apiVersion: iam.cnrm.cloud.google.com/v1beta1
   kind: IAMPolicyMember
   metadata:
     name: policy-artifact-registry-reader
   spec:
     member: serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com
     role: roles/artifactregistry.reader
     resourceRef:
       apiVersion: artifactregistry.cnrm.cloud.google.com/v1beta1
       kind: ArtifactRegistryRepository
       name: REPOSITORY_NAME

   Ersetzen Sie Folgendes:

   • SA_NAME: Der Name Ihres IAM-Dienstkontos.
   • PROJECT_ID ist Ihre Google Cloud-Projekt-ID.
   • REPOSITORY_NAME: der Name Ihres Artifact Registry-Repositorys

2. Weisen Sie dem Dienstkonto die Rolle „Artifact Registry-Leser” zu:

   kubectl apply -f policy-artifact-registry-reader.yaml
   

Wenn Sie private Images in Container Registry verwenden, müssen Sie auch Zugriff darauf gewähren:

Hinweis: Container Registry wurde verworfen und wird eingestellt. Organisationen, die Container Registry vor dem 8. Januar 2024 nicht verwendet haben, werden standardmäßig neue gcr.io-Repositories in Artifact Registry gehostet. Nach dem 15. Mai 2024 unterstützen Google Cloud-Projekte ohne vorherige Verwendung von Container Registry nur das Hosting und die Verwaltung von Images für die Domain gcr.io in Artifact Registry.

Container Registry soll am 18. März 2025 eingestellt werden. Weitere Informationen zur Einstellung finden Sie unter Einstellung von Container Registry.

gsutil

gsutil iam ch \
  serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com:objectViewer \
  gs://BUCKET_NAME

Der Bucket, in dem Ihre Images gespeichert sind, hat den Namen BUCKET_NAME im Format:

• artifacts.PROJECT_ID.appspot.com für Images, die in eine Registry im Host gcr.io hochgeladen werden, oder
• STORAGE_REGION.artifacts.PROJECT_ID.appspot.com

Dabei gilt:

• PROJECT_ID ist Ihre Projekt-ID der Google Cloud Console.
• STORAGE_REGION ist der Speicherort des Storage-Buckets:
  • us für Registrys im Host us.gcr.io
  • eu für Registrys im Host eu.gcr.io
  • asia für Registrys im Host asia.gcr.io

Weitere Informationen zum Befehl finden Sie in der Dokumentation zu gsutil iam.

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

Wenden Sie die Rolle storage.objectViewer auf Ihr Dienstkonto an. Laden Sie die im Folgenden aufgeführte Ressource als Datei policy-object-viewer.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-object-viewer.yaml

Wenn ein anderer Nutzer die Möglichkeit haben soll, neue Cluster oder Knotenpools mit diesem Dienstkonto zu erstellen, müssen Sie ihm die Rolle des Dienstkontonutzers für dieses Dienstkonto zuweisen:

gcloud

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

Config Connector

Hinweis: Für diesen Schritt ist Config Connector erforderlich. Folgen Sie der Installationsanleitung, um Config Connector in Ihrem Cluster zu installieren.

Wenden Sie die Rolle iam.serviceAccountUser auf Ihr Dienstkonto an. Laden Sie die folgende Ressource als Datei policy-service-account-user.yaml herunter. Ersetzen Sie [SA_NAME] und [PROJECT_ID] durch Ihre eigenen Informationen.

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-service-account-user.yaml

Für vorhandene Standard-Cluster können Sie jetzt einen neuen Knotenpool mit diesem neuen Dienstkonto erstellen. Für Autopilot-Cluster müssen Sie einen neuen Cluster mit dem Dienstkonto erstellen. Eine Anleitung finden Sie unter Autopilot-Cluster erstellen.

• Erstellen Sie einen Knotenpool, der das neue Dienstkonto verwendet:

  gcloud container node-pools create NODE_POOL_NAME \
  --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --cluster=CLUSTER_NAME

Wenn Ihr GKE-Cluster Zugriff auf andere Google Cloud-Dienste benötigt, sollten Sie Workload Identity Federation for GKE verwenden.

Zugriff auf die Discovery APIs des Clusters einschränken

Kubernetes stattet Cluster standardmäßig per Bootstrapping mit einem wenig restriktiven Satz von ClusterRoleBindings zur Erkennung aus, die einen breiten Zugriff auf Informationen zu den APIs eines Clusters ermöglichen, einschließlich jener von CustomResourceDefinitions.

Nutzer sollten sich der Tatsache bewusst sein, dass die Gruppe system:authenticated, die in den Subjekten der ClusterRoleBindings system:discovery und system:basic-user enthalten ist, authentifizierte Nutzer umfassen kann, einschließlich Nutzer mit einem Google-Konto, und daher für GKE-Cluster keine geeignete Sicherheitsstufe darstellt. Weitere Informationen finden Sie unter Standardrollen und -gruppen vermeiden.

Zur Härtung der Erkennungs-APIs von Clustern stehen Nutzern die folgenden Aktionen zur Verfügung:

• Konfigurieren der autorisierten Netzwerke, um den Zugriff auf festgelegte IP-Bereiche einzuschränken.
• Einrichten eines privaten Clusters, um den Zugriff auf eine VPC einzuschränken.

Wenn keine dieser Optionen für Ihren GKE-Anwendungsfall geeignet ist, sollten Sie alle API-Erkennungsinformationen, d. h. das Schema von CustomResources, APIService-Definitionen und Erkennungsinformationen, die von Erweiterungs-API-Servern gehostet werden, als öffentlich behandeln.

Beide Optionen ermöglichen den Zugriff auf die IP-Adresse des API-Servers aus Cloud Run und Cloud Functions. Dieser Zugriff wird entfernt. Verlassen Sie sich daher nicht darauf, dass diese Dienste mit Ihrem API-Server kommunizieren. Weitere Informationen finden Sie im Google Cloud-Blogpost.

Mit Namespaces und RBAC den Zugriff auf Clusterressourcen beschränken

CIS-GKE-Benchmark-Empfehlung: 5.6.1. Administrative Grenzen zwischen Ressourcen mithilfe von Namespaces erstellen

Gewähren Sie Teams Zugriff auf Kubernetes mit minimalen Berechtigungen und erstellen Sie dafür separate Namespaces oder Cluster für jedes Team und jede Umgebung. Weisen Sie jedem Namespace Kostenstellen und entsprechende Labels für Rechnungslegung und Rückbuchungen zu. Gewähren Sie Entwicklern nur Zugriff auf die Namespaces, die sie benötigen, um ihre Anwendung bereitzustellen und zu verwalten, insbesondere in der Produktion. Legen Sie die Aufgaben, die Ihre Nutzer für den Cluster ausführen müssen, fest und definieren Sie die Berechtigungen, die für die jeweilige Aufgabe erforderlich sind.

Weitere Informationen zum Erstellen von Namespaces finden Sie in der Kubernetes-Dokumentation. Best Practices für die Planung Ihrer RBAC-Konfiguration finden Sie unter Best Practices für GKE-RBAC.

IAM und die rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC) arbeiten zusammen. Jede Entität muss auf jeder Ebene ausreichende Berechtigungen haben, um mit Ressourcen im Cluster arbeiten zu können.

Weisen Sie den Gruppen und Nutzern die geeigneten IAM-Rollen für GKE zu, um Berechtigungen auf Projektebene bereitzustellen. Verwenden Sie RBAC, um Berechtigungen auf Cluster- und Namespace-Ebene zu gewähren. Weitere Informationen finden Sie unter Zugriffssteuerung.

Sie können IAM- und RBAC-Berechtigungen zusammen mit Namespaces verwenden, um Nutzerinteraktionen mit Clusterressourcen in der Google Cloud Console einzuschränken. Weitere Informationen finden Sie unter Zugriff gewähren und Clusterressourcen nach Namespace aufrufen.

Traffic zwischen Pods mit einer Netzwerkrichtlinie beschränken

CIS-GKE-Benchmark-Empfehlung: 6.6.7. Netzwerkrichtlinie sollte aktiviert und entsprechend eingerichtet sein

Alle Pods in einem Cluster können standardmäßig miteinander kommunizieren. Sie sollten die Pod-zu-Pod-Kommunikation je nach Arbeitslast entsprechend steuern.

Die Beschränkung des Netzwerkzugriffs auf Dienste erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Sie bietet Diensten außerdem einen gewissen Schutz vor versehentlichen oder absichtlichen "Denial-of-Service"-Angriffen. Es gibt zwei empfohlene Methoden zur Steuerung des Traffics:

1. Verwenden Sie Istio. Lesen Sie Istio in Google Kubernetes Engine installieren, wenn Sie Load-Balancing, Dienstautorisierung, Drosselung, Kontingente, Messwerte und mehr verwenden möchten.
2. Verwenden Sie Kubernetes-Netzwerkrichtlinien. Siehe Cluster-Netzwerkrichtlinie erstellen. Diese Option bietet eine einfache Möglichkeit der Zugriffssteuerung mit Kubernetes. Wenn Sie gängige Ansätze zum Einschränken des Traffics mithilfe von Netzwerkrichtlinien implementieren möchten, lesen Sie den Implementierungsleitfaden der GKE Enterprise Sicherheits-Blueprints. Die Kubernetes-Dokumentation enthält auch eine hervorragende Schritt-für-Schritt-Anleitung für ein einfaches nginx-Deployment. Prüfen Sie mit Logging von Netzwerkrichtlinien, ob Ihre Netzwerkrichtlinien erwartungsgemäß funktionieren.

Istio und Netzwerkrichtlinien können bei Bedarf auch kombiniert verwendet werden.

Secret-Verwaltung

CIS-GKE-Benchmark-Empfehlung: 6.3.1. Kubernetes-Secrets mit Schlüsseln verschlüsseln, die in Cloud KMS verwaltet werden

Sie sollten einen zusätzlichen Schutz für vertrauliche Daten wie Secrets bereitstellen, die in etcd gespeichert sind. Dazu müssen Sie einen Secrets-Manager konfigurieren, der in GKE-Cluster eingebunden ist. Einige Lösungen funktionieren sowohl in GKE als auch in GKE on VMware und sind daher möglicherweise besser geeignet, wenn Sie Arbeitslasten in mehreren Umgebungen ausführen. Wenn Sie einen externen Secrets-Manager wie HashiCorp Vault verwenden möchten, sollten Sie diesen vor dem Erstellen des Clusters einrichten.

Für die Verwaltung von Secrets stehen mehrere Möglichkeiten zur Verfügung.

• Sie können Kubernetes-Secrets nativ in GKE verwenden. Optional können Sie die Secrets auf Anwendungsebene mit einem von Ihnen verwalteten Schlüssel verschlüsseln. Dazu verwenden Sie die Verschlüsselung von Secrets auf Anwendungsebene.
• Sie können einen Secrets-Manager wie z. B. HashiCorp Vault verwenden. Bei Ausführung im gehärteten Hochverfügbarkeitsmodus bietet dieser Manager eine einheitliche und produktionsfertige Möglichkeit zur Verwaltung von Secrets. Sie können sich entweder mit einem Kubernetes- oder Google Cloud-Dienstkonto bei HashiCorp Vault authentifizieren. Weitere Informationen zur Verwendung von GKE mit Vault finden Sie unter HashiCorp Vault ausführen und dafür eine Verbindung in Kubernetes herstellen.

GKE-VMs werden standardmäßig auf Speicherebene verschlüsselt. Dies beinhaltet etcd.

Mithilfe von Zugangs-Controllern Richtlinien durchsetzen

Admission-Controller sind Plug-ins, die die Art der Verwendung des Clusters steuern und erzwingen. Sie müssen aktiviert sein, damit Sie einige der erweiterten Sicherheitsfunktionen von Kubernetes verwenden können. Sie sind außerdem ein wichtiger Bestandteil des "Defense-in-Depth"-Konzepts zur Härtung des Clusters.

Standardmäßig können Pods in Kubernetes mit Funktionen arbeiten, die über ihre Anforderungen hinausgehen. Sie sollten die Funktionen eines Pods auf die für die jeweilige Arbeitslast erforderlichen Funktionen beschränken.

Kubernetes unterstützt zahlreiche Steuerelemente, mit denen Sie Ihre Pods so einschränken können, dass sie nur mit den explizit zugewiesenen Funktionen ausgeführt werden. Beispielsweise ist Policy Controller für Cluster in Flotten verfügbar. Kubernetes verfügt auch über den integrierten PodSecurity-Admission-Controller, mit dem Sie die Pod-Sicherheitsstandards in einzelnen Clustern erzwingen können.

Policy Controller ist ein Feature von GKE Enterprise, mit dem Sie die Sicherheit in GKE-Clustern mithilfe von deklarativen Richtlinien erzwingen und validieren können. Informationen zum Erzwingen deklarativer Steuerungen auf Ihrem GKE-Cluster mit Policy Controller finden Sie unter Policy Controller installieren.

Mit dem PodSecurity-Admission-Controller können Sie vordefinierte Richtlinien in bestimmten Namespaces oder im gesamten Cluster erzwingen. Diese Richtlinien entsprechen den verschiedenen Pod-Sicherheitsstandards.

Möglichkeit einschränken, dass sich Arbeitslasten selbst ändern

Bestimmte Kubernetes-Arbeitslasten, insbesondere Systemarbeitslasten, haben die Berechtigung, sich selbst zu ändern. Beispielsweise werden einige Arbeitslasten automatisch vertikal skaliert. Dies ist zwar praktisch, kann einem Angreifer, der bereits einen Knoten manipuliert hat, aber auch die Möglichkeit bieten, im Cluster weiter zu eskalieren. Ein Angreifer kann beispielsweise dafür sorgen, dass sich eine Arbeitslast auf dem Knoten selbst ändert, um als ein privilegierteres Dienstkonto ausgeführt zu werden, das im selben Namespace vorhanden ist.

Idealerweise sollten Arbeitslasten nicht die Berechtigung erhalten, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, können Sie die Berechtigungen einschränken, indem Sie Gatekeeper- oder Policy Controller-Einschränkungen anwenden, z. B. NoUpdateServiceAccount aus der Open-Source-Gatekeeper-Bibliothek, die mehrere nützliche Sicherheitsrichtlinien bietet.

Wenn Sie Richtlinien bereitstellen, müssen die Controller, die den Clusterlebenszyklus verwalten, normalerweise die Möglichkeit haben, die Richtlinien zu umgehen. Dies ist erforderlich, damit die Controller Änderungen am Cluster vornehmen können, indem sie z. B. Clusterupgrades anwenden. Wenn Sie beispielsweise die Richtlinie NoUpdateServiceAccount in GKE bereitstellen, müssen Sie die folgenden Parameter in der Constraint festlegen:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Verwendung des verworfenen gcePersistentDisk-Volume-Typs einschränken

Mit dem verworfenen gcePersistentDisk-Volume-Typ können Sie einen nichtflüchtigen Compute Engine-Speicher auf Pods bereitstellen. Wir empfehlen, die Nutzung des Volume-Typs gcePersistentDisk in Ihren Arbeitslasten einzuschränken. GKE führt beim Bereitstellen dieses Volume-Typs keine IAM-Autorisierungsprüfungen für den Pod durch, obwohl Google Cloud beim Anhängen des Laufwerks an die zugrunde liegende VM Autorisierungsprüfungen durchführt. Ein Angreifer, der bereits in der Lage ist, Pods in einem Namespace zu erstellen, kann daher auf den Inhalt der nichtflüchtigen Speicher von Compute Engine in Ihrem Google Cloud-Projekt zugreifen.

Für den Zugriff auf nichtflüchtige Compute Engine-Speicher verwenden Sie stattdessen PersistentVolumes und PersistentVolumeClaims. Wenden Sie Sicherheitsrichtlinien in Ihrem Cluster an, um die Verwendung des Volume-Typs gcePersistentDisk zu verhindern.

Um die Nutzung des Volume-Typs gcePersistentDisk zu verhindern, wenden Sie die Referenz oder die Richtlinie "Eingeschränkt" mit dem PodSecurity-Admission-Controller an. Sie können auch eine benutzerdefinierte Einschränkung im Richtlinien-Controller oder im Gatekeeper-Admission-Controller definieren.

So definieren Sie eine benutzerdefinierte Einschränkung, um diesen Volume-Typ einzuschränken:

1. Installieren Sie einen richtlinienbasierten Zulassungs-Controller, z. B. Policy Controller oder Gatekeeper OPA.

   Policy Controller

   Policy Controller im Cluster installieren

   Der Policy Controller ist ein kostenpflichtiges Feature für GKE-Nutzer. Policy Controller basiert auf Open-Source-Gatekeeper. Sie erhalten jedoch auch Zugriff auf die vollständige Einschränkungsvorlagenbibliothek, Richtlinien-Bundles und die Einbindung in Google Cloud Console-Dashboards, um Ihre Cluster zu beobachten und zu verwalten. Richtlinien-Bundles sind Best Practices, die Sie auf Ihre Cluster anwenden können, einschließlich Bundles, die auf Empfehlungen wie der CIS-Kubernetes-Benchmark basieren.

   Gatekeeper

   Installieren Sie Gatekeeper in Ihrem Cluster.

   Öffnen Sie für Autopilot-Cluster das Gatekeeper-Manifest gatekeeper.yaml in einem Texteditor. Ändern Sie das rules-Feld in der MutatingWebhookConfiguration-Spezifikation, um Platzhalterzeichen (*) durch bestimmte API-Gruppen- und Ressourcennamen zu ersetzen, wie im folgenden Beispiel:

   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   ...
   webhooks:
   - admissionReviewVersions:
     - v1
     - v1beta1
     ...
     rules:
     - apiGroups:
       - core
       - batch
       - apps
       apiVersions:
       - '*'
       operations:
       - CREATE
       - UPDATE
       resources:
       - Pod
       - Deployment
       - Job
       - Volume
       - Container
       - StatefulSet
       - StorageClass
       - Secret
       - ConfigMap
     sideEffects: None
     timeoutSeconds: 1
   

   Wenden Sie das aktualisierte gatekeeper.yaml-Manifest auf Ihren Autopilot-Cluster an, um Gatekeeper zu installieren. Dies ist erforderlich, da Autopilot als integrierte Sicherheitsmaßnahme Platzhalterzeichen in mutierenden Zulassungs-Webhooks nicht zulässt.

2. Stellen Sie die integrierte Einschränkungsvorlage für Pod-Sicherheitsrichtlinien-Volumentypen bereit:

   kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml
   

3. Speichern Sie folgende Einschränkung mit einer Liste der zulässigen Volume-Typen als constraint.yaml:

   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: k8sPSPVolumeTypes
   metadata:
     name: nogcepersistentdisk
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pods"]
     parameters:
       volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]
   

   Diese Einschränkung beschränkt Volumes auf die Liste im spec.parameters.volumes-Feld.

4. Stellen Sie die Einschränkung bereit:

   kubectl apply -f constraint.yaml
   

Clusterkonfiguration überwachen

Es wird empfohlen, Ihre Clusterkonfigurationen auf Abweichungen von Ihren definierten Einstellungen zu prüfen.

Viele Empfehlungen, die in diesem Leitfaden zur Härtung behandelt werden, sowie andere häufige Fehlkonfigurationen können mithilfe von Sicherheitsintegritäts-Analysen automatisch überprüft werden.

Sichere Standardeinstellungen

In den folgenden Abschnitten werden Optionen erläutert, die in neuen Clustern standardmäßig sicher konfiguriert sind. Prüfen Sie, ob bereits vorhandene Cluster sicher konfiguriert sind.

Knotenmetadaten schützen

CIS-GKE-Benchmark-Empfehlungen: 6.4.1. Die Legacy-Instanzmetadaten-APIs in Compute Engine sollten deaktiviert sein, und 6.4.2. Der GKE-Metadatenserver sollte aktiviert sein

Die Compute Engine-Metadatenserver-Endpunkte v0.1 und v1beta1 wurden verworfen und am 30. September 2020 eingestellt. Diese Endpunkte haben keine Metadatenabfrage-Header erzwungen. Informationen zum Zeitplan für die Einstellung finden Sie unter Einstellung der Metadatenserver-Endpunkte v0.1 und v1beta1.

Manche Angriffe auf Kubernetes in der Praxis erfordern Zugriff auf den Metadatenserver der VM, um Anmeldedaten zu extrahieren. Diese Angriffe werden blockiert, wenn Sie Workload Identity Federation for GKE oder Metadatenverbergung verwenden.

Legacy-Authentifizierungsmethoden für Legacy-Clients aktiviert lassen

CIS-GKE-Benchmark-Empfehlungen: 6.8.1. Die Basisauthentifizierung mit statischen Passwörtern sollte deaktiviert sein, und 6.8.2. Die Authentifizierung mit Clientzertifikaten sollte deaktiviert sein

Hinweis: Die Basisauthentifizierung ist veraltet und wurde in GKE 1.19 und höher entfernt.

Es gibt mehrere Methoden zur Authentifizierung beim Kubernetes API-Server. Die unterstützten Methoden in GKE sind Inhabertokens für Dienstkonten, OAuth-Tokens und x509-Clientzertifikate. GKE verwaltet die Authentifizierung mit gcloud mithilfe der OAuth-Token-Methode. Dabei wird die Kubernetes-Konfiguration eingerichtet sowie ein Zugriffstoken abgerufen und auf den neuesten Stand gebracht.

Vor der Einbindung von GKE in OAuth waren einmalig erstellte x509-Zertifikate oder statische Passwörter die einzigen verfügbaren Authentifizierungsmethoden. Diese sind jedoch nicht mehr empfehlenswert und sollten deaktiviert werden. Diese Methoden bieten eine größere Angriffsfläche zur Manipulation von Clustern und sind seit GKE-Version 1.12 standardmäßig deaktiviert. Wenn Sie Legacy-Authentifizierungsmethoden verwenden, empfehlen wir, sie zu deaktivieren. Die Authentifizierung mit einem statischen Passwort ist veraltet und wurde seit der GKE-Version 1.19 entfernt.

Vorhandene Cluster sollten nach OAuth verschoben werden. Wenn ein System, das sich außerhalb des Clusters befindet, langlebige Anmeldedaten benötigt, empfehlen wir, ein Google-Dienstkonto oder ein Kubernetes-Dienstkonto mit den erforderlichen Berechtigungen zu erstellen und den Schlüssel zu exportieren.

Informationen zum Aktualisieren eines vorhandenen Clusters und zum Entfernen des statischen Passworts finden Sie unter Authentifizierung mit einem statischen Passwort deaktivieren.

Derzeit ist es nicht möglich, das vorab ausgestellte Clientzertifikat aus einem vorhandenen Cluster zu entfernen. Es sind damit aber keine Berechtigungen vorhanden, wenn RBAC aktiviert und ABAC deaktiviert ist.

Cloud Logging aktiviert lassen

CIS-GKE-Benchmark-Empfehlung: 6.7.1. Stackdriver Kubernetes Logging und Monitoring sollten aktiviert sein

Zur Reduzierung des operativen Aufwands und zur Bereitstellung einer konsolidierten Ansicht Ihrer Logs sollten Sie eine einheitliche Logging-Strategie für alle bereitgestellten Cluster implementieren. GKE Enterprise-Cluster sind standardmäßig in Cloud Logging eingebunden und sollten so konfiguriert bleiben.

Hinweis: In GKE sind Cloud Logging und Cloud Monitoring standardmäßig konfiguriert. Weitere Informationen finden Sie unter Beobachtbarkeit in GKE.

Alle GKE-Cluster bieten Kubernetes-Audit-Logging mit einer chronologischen Aufzeichnung von Aufrufen, die an den Kubernetes API-Server gesendet wurden. Dieses Feature ist standardmäßig aktiviert. Die Einträge im Kubernetes-Audit-Log sind nützlich, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen oder Monitoringbenachrichtigungen für unerwünschte API-Aufrufe zu erstellen.

GKE-Cluster ermöglichen die Einbindung von Kubernetes-Audit-Logging in Cloud-Audit-Logs und Cloud Logging. Logs können von Cloud Logging an Ihre eigenen Logging-Systeme weitergeleitet werden.

Kubernetes-Web-UI (Dashboard) deaktiviert lassen

CIS-GKE-Benchmark-Empfehlung: 6.10.1. Die Kubernetes-Web-UI sollte deaktiviert sein

Sie sollten die Kubernetes-Web-UI (Dashboard) nicht aktivieren, wenn sie in GKE ausgeführt wird.

Hinweis: Standardmäßig hat die Kubernetes-Web-UI (Dashboard) keinen Administratorzugriff und ist in GKE ab Version 1.10 deaktiviert. Ab Version 1.15 wird das Kubernetes-Web-UI-Add-on KubernetesDashboard in GKE nicht als verwaltetes Add-on unterstützt. Wenn Sie die Kubernetes-Web-UI dennoch verwenden möchten, installieren Sie sie mithilfe der Dokumentation für die Kubernetes-Web-UI.

Die Kubernetes-Web-UI (Dashboard) wird von einem Kubernetes-Dienstkonto mit hoher Priorität unterstützt. Die Google Cloud Console bietet weitgehend die gleiche Funktionalität, sodass Sie diese Berechtigungen nicht benötigen.

So deaktivieren Sie die Kubernetes-Web-UI:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

ABAC deaktiviert lassen

CIS-GKE-Benchmark-Empfehlung: 6.8.4. Die Legacy-Autorisierung (ABAC) sollte deaktiviert sein

Sie sollten in GKE die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) deaktivieren und stattdessen die rollenbasierte (Role-Based Access Control, RBAC) verwenden.

Standardmäßig ist ABAC für Cluster deaktiviert, die mit GKE ab Version 1.8 erstellt wurden. In Kubernetes wird RBAC zum Erteilen von Berechtigungen für Ressourcen auf Cluster- und Namespace-Ebene verwendet. Mit RBAC können Sie Rollen mit Regeln definieren, die eine Reihe von Berechtigungen enthalten. RBAC bietet erhebliche Sicherheitsvorteile gegenüber ABAC.

Wenn Sie dennoch ABAC verwenden, lesen Sie zuerst die Voraussetzungen für die Verwendung von RBAC. Wenn Sie Ihren Cluster von einer älteren Version aktualisiert haben und ABAC verwenden, müssen Sie die Konfiguration der Zugriffssteuerung entsprechend aktualisieren:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

So erstellen Sie einen neuen Cluster mit der obigen Empfehlung:

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

Aktivierung des DenyServiceExternalIPs-Admission-Controller übernehmen

Deaktivieren Sie den DenyServiceExternalIPs-Admission-Controller nicht.

Der DenyServiceExternalIPs-Admission-Controller blockiert die Verwendung externer IP-Adressen durch Dienste und entschärft eine bekannte Sicherheitslücke.

Der DenyServiceExternalIPs-Admission-Controller ist standardmäßig für neue Cluster aktiviert, die mit den GKE-Versionen 1.21 und höher erstellt wurden. Bei Clustern, auf die GKE-Versionen 1.21 und höher aktualisiert werden, können Sie den Admission-Controller mit folgendem Befehl aktivieren:

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-service-externalips

Nächste Schritte

• Weitere Informationen zur GKE-Sicherheit finden Sie in der Übersicht über die Sicherheit.
• Mehr über das GKE- Modell zur geteilten Verantwortung erfahren
• CIS-GKE-Benchmark auf Ihren Cluster anwenden
• Mehr über die Zugriffssteuerung in GKE erfahren
• GKE-Netzwerkübersicht
• Mehr über die GKE-Mandantenfähigkeit erfahren