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-Sicherheitsstandards für Pods
Das Kubernetes-Projekt enthält 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 signifikante Änderungen ausgeführt werden.
- Eingeschränkt: Höchste Sicherheit. Erfordert erhebliche Änderungen an den meisten Arbeitslasten.
Autopilot wendet die Baseline-Richtlinie mit einigen Änderungen an der Nutzerfreundlichkeit an. Autopilot wendet auch viele Einschränkungen aus der eingeschränkten Richtlinie an, vermeidet aber Einschränkungen, die den Großteil Ihrer Arbeitslasten blockieren. Autopilot wendet diese Einschränkungen auf Clusterebene mit einem Admission-Controller an, der von Google gesteuert wird. Wenn Sie zusätzliche Einschränkungen anwenden müssen, um die vollständige Richtlinie von „Eingeschränkt“ zu erfüllen, können Sie optional den PodSecurity-Admission-Controller in bestimmten Namespaces verwenden.
In der folgenden Tabelle wird beschrieben, wie Autopilot-Cluster die Referenz- und die eingeschränkten Richtlinien implementieren. Beschreibungen der einzelnen Steuerelemente in dieser Tabelle finden Sie im entsprechenden Eintrag unter Pod-Sicherheitsstandards.
Bei der Bewertung der Compliance haben wir berücksichtigt, wie die Einschränkungen für Ihre eigenen Arbeitslasten gelten. Dies schließt verifizierte Google Cloud-Partnerarbeitslasten und Systemarbeitslasten, die bestimmte Berechtigungen benötigen, aus.
| Steuerelement | Compliance mit der Baseline-Richtlinie | Eingeschränkte Richtliniencompliance | Weitere Informationen |
|---|---|---|---|
| HostProcess | Autopilot blockiert HostProcess. | ||
| Host-Namespaces | Autopilot blockiert Host-Namespaces. Einige Container von bestätigten Partnern sind berechtigt, Host-Namespaces zu verwenden. | ||
| Privilegierte Container | Autopilot blockiert privilegierte Container standardmäßig. Autopilot ermöglicht privilegierten Containern von geprüften Partnern zu Zwecken wie das Ausführen von Sicherheits- und Monitoring-Tools. | ||
| 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:
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 | Mit Autopilot können Container Lesezugriff auf /var/log zum Debugging anfordern, aber alle anderen Lese- oder Schreibzugriffe ablehnen. |
| HostPorts | Das Festlegen bestimmter Hostports ist nicht zulässig, wodurch einige Planungsprobleme verringert werden und eine versehentliche oder absichtliche direkte Netzwerksichtbarkeit von Diensten verhindert wird. Sie können die zufällige Hostportzuweisung aus einem bekannten Bereich manuell einrichten, um Netzwerkanwendungen für direkte Verbindungen wie Spieleserver zu unterstützen. | ||
| AppArmor | Das AppArmor-Docker-Standardsicherheitsprofil wird automatisch auf Container-Optimized OS angewendet. | ||
| SELinux | SELinux wurde nicht angewendet, da AppArmor bereits angewendet wurde. SELinux ist in den Pod-Sicherheitsstandards ebenfalls nicht 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. Setzen Sie dazu das Profil in der Pod-Spezifikation auf Unconfined. |
||
| 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 lässt nur die Volume-Typen in der Richtlinie „Eingeschränkt“ zu, und zwar 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 Netzwerkdateisystem-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 Nicht-Root-Nutzer ausführen | Container können für runAsUser den Wert 0 festlegen.
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:
In GKE-Versionen vor 1.21 wird die Funktion |
| 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
|
| 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 |
| Ü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 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 |
| Zertifikatsignierungsanfragen | Sie können CertificateSigningRequests in Autopilot erstellen, um Zertifikate zu erstellen, die von der Cluster-Zertifizierungsstelle signiert sind. 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 |
|
| 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
- Übersicht zur GKE-Sicherheit lesen
- Leitfaden zum Härten von GKE lesen
- Sicherheitsbulletins und Versionshinweise abonnieren