Sicherheitsfunktionen von GKE Autopilot

Auf dieser Seite werden die Sicherheitsfeatures, Konfigurationen und Einstellungen in Google Kubernetes Engine (GKE) Autopilot beschrieben, das zur Ausführung von GKE empfohlen wird.

Wer sollte diese Seite verwenden?

Diese Seite richtet sich an Sicherheitsadministratoren, die die Sicherheitsbeschränkungen von Google für Autopilot-Cluster sowie die Sicherheitsfeatures, die für Autopilot verfügbar sind, verstehen möchten.

Sie sollten auch die GKE-Sicherheitsübersicht lesen, in der die Optionen, Maßnahmen und Empfehlungen zur Härtung beschrieben werden, die für alle GKE-Cluster, Netzwerkkonfigurationen und Arbeitslasten gelten.

Sicherheitsmaßnahmen in Autopilot

Autopilot-Cluster aktivieren standardmäßig Best Practices und Einstellungen für die Sicherheit und wenden sie an, einschließlich vieler Empfehlungen in der Sicherheitsübersicht und unter Clustersicherheit härten.

Wenn Sie je nach Anwendungsfall empfohlene Ressourcen benötigen, fahren Sie mit Sicherheitsressourcen nach Anwendungsfall fort. In den folgenden Abschnitten werden die Sicherheitsrichtlinien beschrieben, die Autopilot für Sie anwendet.

Autopilot und die Kubernetes-Pod-Sicherheitsstandards

Das Kubernetes-Projekt hat eine Reihe von Sicherheitsrichtlinien namens Pod-Sicherheitsstandards, die die folgenden Richtlinien definieren:

  • Privilegiert: Keine Zugriffsbeschränkungen Wird in Autopilot nicht verwendet.
  • Baseline: Verhindert bekannte Pfade zur Rechteausweitung. Die meisten Arbeitslasten können ohne größere Änderungen ausgeführt werden.
  • Eingeschränkt: Höchste Sicherheit. Erfordert erhebliche Änderungen an den meisten Arbeitslasten.

Im Autopilot-Modus erzwingt GKE Pod-Sicherheitsbeschränkungen mithilfe eines benutzerdefinierten Admission-Controllers namens GKE Warden. Wir erzwingen eine Standardsicherheitsrichtlinie, die alle Empfehlungen auf der Baseline-Ebene der Pod-Sicherheitsstandards enthält, mit einigen Änderungen für die Nutzerfreundlichkeit. Außerdem erzwingt die standardmäßige GKE Warden-Zulassungsrichtlinie für Autopilot viele Einschränkungen der Restricted-Ebene der Pod-Sicherheitsstandards, vermeidet aber Einschränkungen, die die Ausführung der meisten Arbeitslasten verhindern würden.

Wenn Sie zusätzliche Einschränkungen anwenden müssen, um die vollständige Richtlinie „Eingeschränkt“ einzuhalten, können Sie optional den PodSecurity-Admission-Controller in bestimmten Namespaces verwenden.

In der folgenden Tabelle wird verglichen, wie sich die Einstellungen in der Standard-Autopilot-GKE Warden-Richtlinie von den Einstellungen in der Baseline und den eingeschränkten Ebenen der Pod-Sicherheitsstandards unterscheiden. Beschreibungen der einzelnen Steuerelemente in dieser Tabelle finden Sie im entsprechenden Eintrag in den Pod-Sicherheitsstandards.

Bei der Prüfung der Compliance haben wir berücksichtigt, wie sich die Einschränkungen auf Ihre eigenen Arbeitslasten auswirken. Ausgenommen sind geprüfte Arbeitslasten von Google Cloud-Partnern und Systemarbeitslasten, für die bestimmte Berechtigungen erforderlich sind.

Steuerelement Einhaltung der Baseline-Richtlinie Einhaltung der Richtlinien für eingeschränkt zulässige Inhalte Weitere Informationen
HostProcess Autopilot blockiert HostProcess.
Host-Namespaces Autopilot blockiert Host-Namespaces. Einige Container von bestätigten Partnern dürfen Host-Namespaces verwenden.
Privilegierte Container Autopilot blockiert standardmäßig privilegierte Container. Autopilot erlaubt privilegierte Container von verifizierten Partnern für Zwecke wie das Ausführen von Sicherheits- und Überwachungstools.
Linux-Funktionen

Autopilot-Arbeitslasten können standardmäßig nur auf die Funktionen zugreifen, die im Sicherheitsstandard von Pod-Baseline angegeben sind.

Sie können die folgenden Funktionen manuell aktivieren:

  • NET_RAW für Ping und SYS_PTRACE für das Debugging: Zum Pod SecurityContext hinzufügen
  • NET_ADMIN für Service Meshes wie Istio: Geben Sie --workload-policies=allow-net-admin im Befehl zur Clustererstellung an. Verfügbar auf neuen und aktualisierten vorhandenen Clustern, auf denen GKE Version 1.27 und höher ausgeführt wird.

Mit Autopilot können auch einige verifizierte Arbeitslasten von Partnern verworfene Funktionen festlegen.
HostPath-Volumes Erfüllt teilweise die Anforderungen Erfüllt teilweise die Anforderungen Autopilot ermöglicht Containern, Lesezugriff auf /var/log für die Fehlerbehebung anzufordern, lehnt aber jeglichen anderen Lese- oder Schreibzugriff ab.
HostPorts Das Festlegen bestimmter Hostports ist nicht zulässig. Dadurch werden einige Planungsprobleme vermieden und die versehentliche oder vorsätzliche direkte Netzwerkpräsenz von Diensten verhindert. Sie können die Zuweisung von zufälligen Hostports aus einem bekannten Bereich manuell einrichten, um Netzwerkanwendungen mit Direktverbindungen wie Gameserver zu unterstützen.
AppArmor Das standardmäßige AppArmor-Sicherheitsprofil von Docker wird automatisch auf Container-Optimized OS angewendet.
SELinux SELinux wird nicht angewendet, da bereits AppArmor angewendet wird. SELinux ist auch nicht in den Pod-Sicherheitsstandards obligatorisch.
/proc-Bereitstellungstyp GKE legt nicht das ProcMountType-Feature-Flag fest. Wenn der Pod securityContext procMount auf "Unmaskiert" setzt, überschreibt GKE es automatisch mit "Standard".
seccomp-Profil Autopilot wendet das seccomp-Profil RuntimeDefault auf alle Arbeitslasten an. Sie können diese Einstellung für bestimmte Arbeitslasten manuell überschreiben, indem Sie das Profil in der Pod-Spezifikation auf Unconfined festlegen.
sysctls GKE setzt das Flag --allow-unsafe-sysctls kubelet nicht, sodass Pods mit unsicheren sysctls nicht geplant werden können. Für zusätzlichen Schutz haben ab dem 11. Juli 2023 neue Cluster ab Version 1.27 eine Richtlinienregel, die die securityContext-Einstellungen erzwingt und Pods, die unsichere sysctls verwenden, ablehnen.
Volume-Typen Autopilot erlaubt nur die Volume-Typen in der Richtlinie „Eingeschränkt“ mit den folgenden Ergänzungen: HostPath-Volumes mit Lesezugriff auf /var/log für die Fehlerbehebung, gcePersistentDisk für nichtflüchtige Compute Engine-Speicher und nfs für Network File System-Volumes.
Rechteausweitung Diese Einstellung bietet nur Schutz für Container, die nicht als Root ausgeführt werden. Branchenstudien zeigen, dass 76 % der Container als Root ausgeführt werden, sodass Autopilot die Ausführung als Root ermöglicht, um die meisten Arbeitslasten zu ermöglichen. Diese Einstellung ist derzeit auch nützlich, um Arbeitslasten auf Nicht-Roots zu setzen, indem Sie die Verwendung von Dateisystemfunktionen ermöglichen, um Mängel bei der Verarbeitung von Root-Funktionen von Kubernetes zu umgehen.
Als Nicht-Root ausführen Branchenumfragen zeigen, dass 76 % der Container als Root ausgeführt werden. Daher ermöglicht Autopilot die Ausführung als Root, um die meisten Arbeitslasten zu ermöglichen.
Als Nutzer ohne Root-Berechtigung ausführen Container können runAsUser auf 0 setzen. Branchenumfragen zeigen, dass 76 % der Container als Root ausgeführt werden. Daher ermöglicht Autopilot die Ausführung als Root, um die meisten Arbeitslasten zu ermöglichen

Integrierte Sicherheitskonfigurationen

Google wendet viele integrierte Sicherheitseinstellungen auf Autopilot-Cluster an, basierend auf Best Practices der Branche und auf unserem Fachwissen. In der folgenden Tabelle werden einige der von Autopilot für Sie angewendeten Sicherheitskonfigurationen beschrieben:

Konfiguration Beschreibung
Host-Optionen
Linux-Funktionen

Sie können die folgenden Linux-Funktionen verwenden:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER", "FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP", "SYS_PTRACE"

Sie können auch die folgenden Funktionen manuell aktivieren:

  • NET_RAW für ping: Fügen SIe dem Pod SecurityContext hinzu.
  • SYS_PTRACE für das Debugging: Fügen Sie dem Pod SecurityContext hinzu.
  • NET_ADMIN für Service Meshes wie Istio: Verwenden Sie beim Erstellen eines Clusters oder beim Aktualisieren eines vorhandenen Clusters --workload-policies=allow-net-admin. Fügen Sie dann dem Pod SecurityContext die Funktion hinzu. Verfügbar ab GKE-Version 1.27.

In GKE-Versionen vor 1.21 wird die Funktion "SYS_PTRACE" nicht unterstützt.
Privilegierte Container Container können nur dann im privilegierten Modus ausgeführt werden, wenn sie von einem Google Cloud-Partner bereitgestellt werden. Privilegierte Container können Änderungen am zugrunde liegenden Knoten vornehmen, z. B. indem sie das Kubelet ändern. Dieser Zugriff kann die Auswirkungen eines Pod-Hackings erhöhen.
Von GKE verwaltete Namespaces Aus Sicherheitsgründen lässt Autopilot keine Bereitstellung von Arbeitslasten in von GKE verwalteten Namespaces wie kube-system zu.
Container-Isolation

Autopilot erzwingt die folgenden Einschränkungen für Container, um die Auswirkungen von Container-Escape-Sicherheitslücken zu begrenzen.

Linux-Funktionen und Kernel-Sicherheit

  • Autopilot wendet das seccomp-Profil RuntimeDefault auf alle Pods im Cluster an, es sei denn, die Pods verwenden GKE Sandbox. Die GKE-Sandbox erzwingt die Hostisolation und ignoriert die im Pod-Manifest angegebenen seccomp-Regeln. Die Sandbox gilt als Sicherheitsgrenze für GKE Sandbox-Pods.
  • Autopilot verwirft die Linux-Funktion CAP_NET_RAW für alle Container. Diese Berechtigung wird nicht oft verwendet und wurde bei mehreren Escape-Sicherheitslücken ausgenutzt. Der Befehl ping kann in Ihren Containern fehlschlagen, da diese Funktion verworfen wurde. Sie können diese Funktion manuell wieder aktivieren, indem Sie sie in Ihrem Pod-SecurityContext festlegen.
  • Autopilot verwirft die Linux-Funktion CAP_NET_ADMIN für alle Container. Wenn Sie diese Funktion wieder aktivieren möchten, geben Sie beim Erstellen oder Aktualisieren des Clusters das Flag --workload-policies=allow-net-admin an. NET_ADMIN ist für einige Arbeitslasten wie Istio erforderlich.
  • Autopilot aktiviert die Workload Identity-Föderation für GKE, die den Pod-Zugriff auf vertrauliche Metadaten auf dem Knoten verhindert.
  • Autopilot blockiert Kubernetes-Services, die das Feld spec.externalIPs zum Schutz vor CVE-2020-8554 festlegen.

  • Autopilot lässt nur die folgenden Volume-Typen zu:

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "nfs", "persistentVolumeClaim", "projected", "secret"

    Andere Volume-Typen werden blockiert, da sie Knotenberechtigungen erfordern. HostPath-Volumes sind standardmäßig blockiert, aber Container können für die Fehlerbehebung schreibgeschützten Zugriff auf /var/log-Pfade anfordern.
Erzwingung von Sicherheitsrichtlinien auf Pod-Ebene Autopilot unterstützt Erzwingungsmechanismen für Sicherheitsrichtlinien auf Pod-Ebene, z. B. PodSecurity Admission-Controller, Gatekeeper oderRichtlinien-Controller. Möglicherweise müssen Sie keine dieser Konfigurationen verwenden, wenn die auf dieser Seite beschriebenen vorhandenen Sicherheitskonfigurationen bereits Ihre Anforderungen erfüllen.
SSH-Verbindung zu Knoten

Autopilot blockiert den SSH-Zugriff auf Knoten. GKE verarbeitet alle operativen Aspekte der Knoten, einschließlich Knotenstatus und Kubernetes-Komponenten, die auf den Knoten ausgeführt werden.

Sie können mit den exec-Funktionen von Kubernetes weiterhin Remote-Verbindungen zu Ihren ausgeführten Containern herstellen, um Befehle zum Debugging in Ihren Containern auszuführen. Dazu gehört auch der Verbindungsaufbau zu einer interaktiven Shell, z. B. mit kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.
Übernahme der Nutzeridentität Die GKE-Version 1.22.4-gke.1501 und höher unterstützt die Übernahme der Nutzeridentität für alle benutzerdefinierten Nutzer und Gruppen. Für Systemnutzer und Gruppen wie den kube-apiserver-Nutzer und die system:masters-Gruppe kann aber keine Identität übernommen werden.
Dynamische Zulassungs-Webhooks mutieren

Autopilot ändert mutierende Webhooks so, dass Ressourcen in verwalteten Namespaces wie kube-system nicht abgefangen werden.

Autopilot lehnt auch Webhooks ab, die eine oder mehrere der folgenden Ressourcen und oder Unterressourcen dieser Ressourcen angeben.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Sie können nicht den Platzhalter * für Ressourcen oder Gruppen verwenden, um diese Einschränkung zu umgehen.
ValidatingAdmissionPolicies

Autopilot ändert ValidatingAdmissionPolicy-Objekte so, dass Ressourcen in verwalteten Namespaces wie kube-system nicht abgefangen werden.

Autopilot lehnt auch ValidatingAdmissionPolicy-Objekte ab, die eine oder mehrere der folgenden Ressourcen und oder Unterressourcen dieser Ressourcen angeben.

- group: ""
  resource: nodes
- group: ""
  resource: persistentVolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Sie können nicht den Platzhalter * für Ressourcen oder Gruppen verwenden, um diese Einschränkung zu umgehen.
Zertifikatsignierungsanfragen Sie können in Autopilot CertificateSigningRequests erstellen, um Zertifikate zu erstellen, die von der Zertifizierungsstelle des Clusters signiert werden. Um Störungen mit Systemkomponenten zu vermeiden, lehnt Autopilot CertificateSigningRequests für bekannte privilegierte Identitäten ab, z. B. Systemgruppen, System-Agents oder von Google verwaltete IAM-Dienst-Agents.
GKE-Sicherheitsfeatures Autopilot-Cluster aktivieren die empfohlenen GKE-Sicherheitsfeatures für Sie. Eine Liste der aktivierten und optionalen Sicherheitsfeatures finden Sie unter Sicherheitsfeatures in Autopilot.
Betriebssystem des Knotens Autopilot-Cluster verwenden Container-Optimized OS mit containerd als Knotenbetriebssystem. Container-Optimized OS wird von Google erstellt und verwaltet.
Upgrades der GKE-Versionen Autopilot-Cluster werden nach der Erstellung in einer GKE-Release-Version registriert und automatische Upgrades sind immer aktiviert. Google aktualisiert Ihre Steuerungsebene und Knoten im Laufe der Zeit automatisch auf die neueste qualifizierte Version in der Release-Version.

Sicherheitsgrenzen in Autopilot

Autopilot bietet Zugriff auf die Kubernetes API, entfernt jedoch Berechtigungen für die Verwendung einiger stark privilegierter Kubernetes-Features wie privilegierter Pods. Das Ziel besteht darin, die Möglichkeit zu beschränken, auf die virtuelle Knotenmaschine (VM) zuzugreifen, sie zu ändern oder sie direkt zu steuern. Autopilot implementiert diese Einschränkungen, um Arbeitslasten daran zu hindern, Zugriff auf niedriger Ebene auf eine Knoten-VM zu gewähren, sodass Google Cloud die vollständige Verwaltung von Knoten und ein SLA auf Pod-Ebene anbieten kann.

Wir möchten den unbeabsichtigten Zugriff auf die Knoten-VM verhindern. Wir nehmen Einreichungen im Rahmen des Google Vulnerability Reward Program (VRP) an und werden Berichte nach Ermessen des Google VRP-Prämiengremiums belohnen.

Privilegierte Nutzer wie Clusteradministratoren haben planmäßig die vollständige Kontrolle über jeden GKE-Cluster. Als Best Practice für Sicherheit sollten Sie die leistungsstarken GKE- bzw. Kubernetes-Berechtigungen vermeiden und stattdessen die Namespace-Administrator-Delegierung verwenden, wie in unserer Anleitung zur Mehrmandantenfähigkeit beschrieben.

Autopilot stellt VMs für einzelne Mandanten in Ihrem Projekt zur exklusiven Verwendung bereit. Auf jeder einzelnen VM werden Ihre Autopilot-Arbeitslasten möglicherweise gemeinsam ausgeführt, wobei ein sicherheitsoptimierter Kernel gemeinsam genutzt wird. Da der freigegebene Kernel eine einzelne Sicherheitsgrenze darstellt, empfehlen wir, dass Sie Ihre Arbeitslasten (z. B. riskante oder nicht vertrauenswürdige Arbeitslasten) mit GKE Sandbox-Pods ausführen, wenn Sie eine starke Isolation benötigen. So sorgen Sie für eine mehrstufige Sicherheit.

Sicherheitsressourcen basierend auf dem Anwendungsfall

In den folgenden Abschnitten finden Sie Links und Empfehlungen zur Planung, Implementierung und Verwaltung der Sicherheit Ihrer Autopilot-Cluster je nach Anwendungsfall.

Clustersicherheit planen

Anwendungsfall Ressourcen
Sicherheitsansatz von GKE als Plattform
Ihre Rolle bei der Härtung Ihrer Umgebung Mehr über das Modell der geteilten Verantwortung erfahren
Empfehlungen von Google zu Härtungsmaßnahmen und zur Vorfallreaktion ansehen
Informationen zur Implementierung von Audit-Logging in GKE

Authentifizieren und autorisieren

Nach dem Einrichten Ihrer Autopilot-Cluster müssen Sie möglicherweise Ihre Nutzer und Anwendungen authentifizieren, um Ressourcen wie die Kubernetes API oder Google Cloud APIs verwenden zu können.

Anwendungsfall Ressourcen
Nutzer oder Anwendungen beim Cluster-API-Server authentifizieren
  • Informationen zur Authentifizierung von Nutzern finden Sie unter Nutzer authentifizieren.
  • Informationen zur Authentifizierung von Anwendungen finden Sie unter Anwendungen authentifizieren. Hier werden die Schritte zur Authentifizierung von Anwendungen im selben Cluster, in anderen Google Cloud-Umgebungen und in externen Umgebungen beschrieben.
Anwendungen beu Google Cloud APIs und Diensten authentifizieren Mit Autopilot-Clustern können Sie die Workload Identity-Föderation für GKE verwenden, um Ihre Arbeitslasten sicher bei Google Cloud APIs zu authentifizieren. Dazu konfigurieren Sie Kubernetes-Dienstkonten dafür, als IAM-Dienstkonten zu fungieren. Eine Anleitung finden Sie unter Anwendungen für die Verwendung der Workload Identity-Föderation für GKE konfigurieren.
Aktionen auf Projektebene autorisieren Verwenden Sie IAM, um Aktionen über Cluster hinweg auf Projektebene zu autorisieren. Sie können Zugriff auf bestimmte GKE- und Kubernetes API-Ressourcen mithilfe von IAM-Rollen und -Berechtigungen gewähren oder verweigern. Eine Anleitung finden Sie unter IAM-Richtlinien erstellen.
Aktionen auf Clusterebene autorisieren Verwenden Sie den integrierten Mechanismus zur rollenbasierten Zugriffssteuerung von Kubernetes (RBAC), um Aktionen für Kubernetes API-Ressourcen in bestimmten Clustern zu autorisieren. Eine Anleitung finden Sie unter Aktionen in Clustern mit RBAC autorisieren.
Aktionen auf Organisationsebene autorisieren Mit dem Google Cloud-Organisationsrichtliniendienst können Sie Einschränkungen für bestimmte Vorgänge in GKE-Ressourcen in Ihrer Google Cloud-Organisation erzwingen. Eine Anleitung finden Sie unter Aktionen für GKE-Ressourcen mithilfe von benutzerdefinierten Organisationsrichtlinien einschränken.

Cluster und Arbeitslasten härten

Wenn Sie spezielle Isolations- oder Härtungsanforderungen über die vorkonfigurierten Autopilot-Maßnahmen hinaus haben, sollten Sie die folgenden Ressourcen in Betracht ziehen:

Anwendungsfall Ressourcen
Öffentlichen Zugriff auf den Clusterendpunkt einschränken Erstellen Sie Ihre Autopilot-Cluster als private Cluster, die die öffentliche IP-Adresse der Steuerungsebene des Clusters deaktivieren. Eine Anleitung finden Sie unter Private Cluster.
Clusterzugriff auf bestimmte Netzwerke einschränken Verwenden Sie autorisierte Netzwerke auf Steuerungsebene, um IP-Adressbereiche anzugeben, die auf Ihren Cluster zugreifen können.
Vertrauliche Informationen außerhalb des Clusters speichern Das Speichern vertraulicher Daten bei einem externen, verschlüsselten Speicheranbieter mit aktivierter Versionsverwaltung ist eine gängige Compliance-Anforderung und eine Best Practice. Verwenden Sie Secret Manager, um Ihre Daten zu speichern und über die Workload Identity-Föderation für GKE über Ihre Autopilot-Cluster darauf zuzugreifen. Eine Anleitung finden Sie unter Mit der Workload Identity-Föderation für GKE auf Secrets zugreifen, die außerhalb von GKE-Clustern gespeichert sind.
Container-Images vor der Bereitstellung im Cluster überprüfen Mit der Binärautorisierung können Sie bei der Bereitstellung die Integrität der Container-Images prüfen, auf die in Ihren Pod-Manifesten verwiesen wird. Eine Anleitung finden Sie unter Container-Images zum Zeitpunkt der Bereitstellung mit Binärautorisierung überprüfen.

Sicherheitsstatus überwachen

Nachdem Sie die Cluster eingerichtet und die Arbeitslasten bereitgestellt haben, sollten Sie Monitoring und Logging einrichten und konfigurieren, damit Sie den Sicherheitsstatus des Clusters beobachten können. Wir empfehlen Folgendes:

  • Registrieren Sie Ihre Cluster im GKE-Sicherheitsstatus-Dashboard, um Arbeitslasten auf Probleme wie unsichere Sicherheitskonfigurationen oder Sicherheitslücken in Ihren Container-Betriebssystempaketen zu prüfen und praktisch nutzbare Informationen zur Problembegrenzung zu erhalten.
  • Verwenden Sie Clusterbenachrichtigungen, um über neue Sicherheitsbulletins und Upgrade-Ereignisse informiert zu werden.
  • Beobachten Sie Ihre Cluster mit dem GKE-Dashboard in Cloud Monitoring oder mit dem Tab "Beobachtbarkeit" in GKE.
  • Lesen Sie die Informationen zum Aufrufen und Verwalten Ihrer GKE-Audit-Logs in Cloud Logging.

Nächste Schritte