Best Practices zur Härtung der Clustersicherheit

In diesem Dokument finden Sie Best Practices zur Verbesserung der Sicherheit Ihrer GKE-Umgebungen (Google Kubernetes Engine). Sicherheitsexperten, die Richtlinien und Verfahren definieren, verwalten und implementieren, können diese Best Practices nutzen, um die Daten ihrer Organisation zu schützen.

Eine konsolidierte Übersicht über alle GKE-Best Practices finden Sie unter Best Practices für GKE.

Sie sollten bereits mit Folgendem vertraut sein:

Neue GKE-Cluster implementieren standardmäßig viele der Best Practices in diesem Dokument. Cluster im Autopilot-Modus haben einen strengeren Standardsicherheitsstatus als Cluster im Standardmodus.

Wenn Sie die Best Practices in diesem Dokument in Ihrer gesamten Organisation implementieren und durchsetzen möchten, sollten Sie die folgenden Dienste in Betracht ziehen:

  • Security Command Center: Prüfen Sie automatisch, ob Ihre Cluster viele dieser Best Practices implementieren, und prüfen Sie, ob andere häufige Fehlkonfigurationen vorliegen.
  • Organisationsrichtliniendienst: Erzwingen Sie bestimmte Best Practices für GKE-Ressourcen in einer Organisation, einem Ordner oder einem Projekt. Bestimmte Abschnitte in diesem Dokument enthalten Links zur Google Cloud Console, über die Sie verwaltete Einschränkungen für diese Empfehlungen anwenden können.

Google Cloud Umgebungsdesign

In den folgenden Abschnitten werden Sicherheitsmaßnahmen beschrieben, die Sie bei der Planung und Gestaltung Ihrer Ressourcen in Google Cloudberücksichtigen sollten. Cloud-Architekten sollten diese Empfehlungen bei der Planung und Definition Google Cloud der Architektur berücksichtigen.

Best Practices

Google Cloud Ressourcenstruktur planen

Empfohlen: Implementieren Sie den Blueprint für Unternehmensgrundlagen, der eine vollständige Grundlage für Ihre Unternehmensumgebung basierend auf unseren Best Practices darstellt.

Die Architektur Ihrer Google Cloud Organisationen, Ordner und Projekte wirkt sich auf Ihren Sicherheitsstatus aus. Entwerfen Sie diese grundlegenden Ressourcen so, dass Governance- und Sicherheitskontrollen in großem Umfang für Ihre Dienste möglich sind.

Mehrmandantenfähige Umgebungen planen

Empfohlen: Implementieren Sie Google Cloud und GKE-Best Practices für Mehrmandantenplattformen für Unternehmen.

Viele GKE-Kunden verwalten verteilte Teams mit separaten Engineering-Workflows und Verantwortlichkeiten. Diese mehrmandantenfähigen Umgebungen müssen eine gemeinsam genutzte Infrastruktur haben, die alle Ihre Entwickler nutzen können. Gleichzeitig muss der Zugriff auf Komponenten basierend auf Rollen und Verantwortlichkeiten eingeschränkt werden. Der Blueprint für Unternehmensanwendungen basiert auf dem Blueprint für Unternehmensgrundlagen und unterstützt Sie bei der Bereitstellung interner Entwicklerplattformen in mehrmandantenfähigen Umgebungen.

Weitere Informationen finden Sie in folgenden Dokumenten:

Tags zum Gruppieren von Google Cloud Ressourcen verwenden

Empfohlen: Verwenden Sie Tags, um GKE-Ressourcen für die bedingte Richtliniendurchsetzung und eine bessere Verantwortlichkeit in Ihren Teams zu organisieren.

Tags sind Metadaten, die Sie Ressourcen in Ihren Organisationen, Ordnern und Projekten zuweisen können, um Geschäftsdimensionen in IhrerGoogle Cloud Ressourcenhierarchie zu identifizieren. Sie können Tags an GKE-Cluster und -Knotenpools anhängen und diese Tags dann verwenden, um IAM- und Firewallrichtlinien bedingt anzuwenden.

Weitere Informationen finden Sie in folgenden Dokumenten:

VPC-Netzwerke planen

Empfohlen: Implementieren Sie Google Cloud und die Best Practices für GKE für das VPC-Netzwerkdesign.

Ihr VPC-Netzwerkdesign und die von Ihnen verwendeten Funktionen wirken sich auf die Netzwerksicherheit aus. Planen Sie Ihre Netzwerke basierend auf Ihrer Google CloudRessourcenhierarchie und Ihren Sicherheitszielen. Weitere Informationen finden Sie in folgenden Dokumenten:

Incident Response-Plan entwerfen

Empfohlen: Erstellen und pflegen Sie einen Incident-Response-Plan, der Ihren Sicherheits- und Zuverlässigkeitszielen entspricht.

Sicherheitsvorfälle können auch dann auftreten, wenn Sie alle möglichen Sicherheitskontrollen implementieren. Ein Reaktionsplan für Vorfälle hilft Ihnen, potenzielle Lücken in Ihren Sicherheitskontrollen zu erkennen, schnell und effektiv auf verschiedene Arten von Vorfällen zu reagieren und Ausfallzeiten bei einem Ausfall zu verkürzen. Weitere Informationen finden Sie in folgenden Dokumenten:

Google Cloud Netzwerksicherheit

In den folgenden Abschnitten finden Sie Sicherheitsempfehlungen für Ihre VPC-Netzwerke. Netzwerkarchitekten und Netzwerkadministratoren sollten diese Empfehlungen anwenden, um die Angriffsfläche auf Netzwerkebene zu verringern und die Auswirkungen von unbeabsichtigtem Netzwerkzugriff zu begrenzen.

Best Practices

Firewallregeln mit geringsten Berechtigungen verwenden

Empfohlen: 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 oder diese überschreiben.

GKE erstellt Standard-VPC-Firewallregeln, um Systemfunktionen zu aktivieren und gute Sicherheitspraktiken zu erzwingen. Wenn Sie freie Firewallregeln mit einer höheren Priorität als eine Standard-Firewallregel erstellen, z. B. eine Firewallregel, die den gesamten eingehenden Traffic für das Debugging zulässt, besteht das Risiko eines unbeabsichtigten Zugriffs auf Ihren Cluster.

Gemeinsam genutzte VPC für projektübergreifenden Traffic verwenden

Empfohlen: Verwenden Sie die freigegebene VPC, damit Ressourcen in mehreren Projekten über interne IP-Adressen miteinander kommunizieren können.

Ressourcen in verschiedenen Projekten in Ihrer Organisation müssen möglicherweise miteinander kommunizieren. Beispielsweise müssen Frontend-Dienste in einem GKE-Cluster in einem Projekt möglicherweise mit Compute Engine-Backend-Instanzen in einem anderen Projekt kommunizieren.

Weitere Informationen finden Sie in folgenden Dokumenten:

Separate Netzwerke zum Isolieren von Umgebungen verwenden

Empfohlen: Verwenden Sie separate freigegebene VPC-Netzwerke für Staging-, Test- und Produktionsumgebungen.

Isolieren Sie Ihre Entwicklungsumgebungen voneinander, um die Auswirkungen und das Risiko unberechtigter Zugriffe oder störender Fehler zu verringern. Weitere Informationen finden Sie unter Mehrere Hostprojekte.

Unveränderliche Sicherheitseinstellungen

In den folgenden Abschnitten finden Sie Sicherheitsempfehlungen, die Sie nur beim Erstellen von Clustern oder Knotenpools konfigurieren können. Sie können vorhandene Cluster oder Knotenpools nicht aktualisieren, um diese Einstellungen zu ändern. Plattformadministratoren sollten diese Empfehlungen auf neue Cluster und Knotenpools anwenden.

IAM-Knotendienstkonten mit geringsten Berechtigungen verwenden

Empfohlen: Verwenden Sie ein benutzerdefiniertes IAM-Dienstkonto für Ihre GKE-Cluster und Knotenpools anstelle des Compute Engine-Standarddienstkontos.

GKE verwendet IAM-Dienstkonten, die an Ihre Knoten angehängt sind, um Systemaufgaben wie Logging und Monitoring auszuführen. Diese Knoten-Dienstkonten müssen in Ihrem Projekt mindestens die Rolle Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) haben. Standardmäßig verwendet GKE das Compute Engine-Standarddienstkonto, das automatisch in Ihrem Projekt erstellt wird, als Knotendienstkonto.

Wenn Sie das Compute Engine-Standarddienstkonto für andere Funktionen in Ihrem Projekt oder Ihrer Organisation verwenden, hat das Dienstkonto möglicherweise mehr Berechtigungen als für GKE erforderlich. Das kann zu Sicherheitsrisiken führen.

Das Dienstkonto, das an Ihre Knoten angehängt ist, sollte nur von Systemarbeitslasten verwendet werden, die Aufgaben wie Logging und Monitoring ausführen. Für Ihre eigenen Arbeitslasten stellen Sie Identitäten mit Workload Identity Federation for GKE bereit.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.disallowDefaultComputeServiceAccount-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Container-Optimized OS-Knoten-Image verwenden

Empfohlen: Sofern Sie nicht Ubuntu oder Windows verwenden müssen, sollten Sie das Container-Optimized OS-Knoten-Image für Ihre Knoten verwenden.

Container-Optimized OS wurde speziell für die Ausführung von Containern entwickelt, optimiert und gehärtet. Container-Optimized OS ist das einzige unterstützte Knoten-Image für den Autopilot-Modus und das Standardknoten-Image für den Standardmodus.

Weitere Informationen finden Sie in folgenden Dokumenten:

Knotensicherheitskonfiguration

In den folgenden Abschnitten finden Sie Sicherheitsempfehlungen für die GKE-Knotenkonfiguration. Plattformadministratoren und Sicherheitsexperten sollten diese Empfehlungen anwenden, um die Integrität Ihrer GKE-Knoten zu verbessern.

Best Practices

Shielded GKE-Knoten verwenden

Empfohlen: Aktivieren Sie Shielded GKE-Knoten, Secure Boot und Integritätsmonitoring in allen Clustern und Knotenpools.

Shielded GKE-Knoten bieten überprüfbare Identitäts- und Integritätsprüfungen, die die Sicherheit Ihrer Knoten verbessern. Shielded GKE-Knoten und Funktionen wie das Integritätsmonitoring von Knoten und Secure Boot sind in Autopilot-Clustern immer aktiviert. Führen Sie in Standardclustern die folgenden Schritte aus:

  • Deaktivieren Sie Shielded GKE-Knoten in Ihren Clustern nicht.
  • Aktivieren Sie Secure Boot in allen Knotenpools.
  • Deaktivieren Sie das Integritätsmonitoring in Ihren Knotenpools nicht.

Weitere Informationen zum Aktivieren dieser Funktionen finden Sie unter Shielded GKE-Knoten verwenden.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die verwaltete Einschränkung für Organisationsrichtlinien constraints/container.managed.enableShieldedNodes. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Unsicheren schreibgeschützten Port für kubelet deaktivieren

Empfohlen: Deaktivieren Sie den schreibgeschützten Port kubelet und wechseln Sie alle Arbeitslasten, die Port 10255 verwenden, um stattdessen den sichereren Port 10250 zu verwenden.

Der auf Knoten ausgeführte kubelet-Prozess stellt eine schreibgeschützte API mit dem unsicheren Port 10255 bereit. Kubernetes führt an diesem Port keine Authentifizierungs- oder Autorisierungsprüfungen durch. kubelet stellt dieselben Endpunkte auf dem sichereren, authentifizierten Port 10250 bereit.

Weitere Informationen finden Sie unter Schreibgeschützten kubelet-Port in GKE-Clustern deaktivieren.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.disableInsecureKubeletReadOnlyPort-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Selbstregistrierung von Knoten deaktivieren

Empfohlen: Verwenden Sie eine vertrauenswürdige Komponente der Steuerungsebene, um Node-Objekte anstelle von kubelet zu erstellen.

Standardmäßig registriert der kubelet-Prozess auf einem neuen GKE-Knoten den Knoten bei der Steuerungsebene, nachdem die Steuerungsebene eine genehmigte CertificateSigningRequest zurückgegeben hat. Dieser Workflow zur Selbstregistrierung birgt ein Sicherheitsrisiko, da ein kompromittiertes kubelet neue Knoten mit schädlichen Taints oder Labels registrieren kann, wie in CVE-2025-5187 beschrieben.

Wenn Sie Shielded GKE-Knoten verwenden, die in allen GKE-Clustern standardmäßig aktiviert sind, können Sie verhindern, dass kubelet Knoten registriert. Stattdessen erstellt eine vertrauenswürdige Komponente der Steuerungsebene neue Node-Objekte in der Kubernetes API, nachdem die Steuerungsebene eine genehmigte CertificateSigningRequest zurückgegeben hat. GKE lehnt jeden Versuch des kubelet ab, Node-Objekte zu erstellen.

Weitere Informationen finden Sie unter Knoten der Steuerungsebene erstellen.

Zugriffssteuerung

In den folgenden Abschnitten finden Sie Empfehlungen zum Einschränken des unautorisierten Zugriffs in Ihrem Cluster. Sicherheitsexperten sowie Identitäts- und Kontoadministratoren sollten diese Empfehlungen umsetzen, um die Angriffsfläche zu verringern und die Auswirkungen unbefugter Zugriffe zu begrenzen.

Best Practices

Zugriff auf die Discovery APIs des Clusters einschränken

Empfohlen: Schränken Sie den Zugriff auf Ihre Steuerungsebene und Knoten über das Internet ein, um unbeabsichtigten Zugriff auf die Discovery APIs des Clusters zu verhindern.

Standardmäßig erstellt Kubernetes Cluster mit einem permissiven Satz von Standard-API-Erkennungsrollen. Diese Standardrollen gewähren verschiedenen Standardgruppen wie system:authenticated umfassenden Zugriff auf Informationen zu den APIs eines Clusters. Diese Standardrollen bieten kein sinnvolles Sicherheitsniveau für GKE-Cluster. Beispielsweise wird die Gruppe system:authenticated, die Informationen zu APIs wie CustomResources lesen kann, jedem authentifizierten Nutzer zugewiesen, einschließlich aller Nutzer mit einem Google-Konto.

So schränken Sie den Zugriff auf die Discovery APIs Ihres Clusters ein:

  • Zugriff auf die Steuerungsebene beschränken: Verwenden Sie für den Zugriff auf die Steuerungsebene nur den DNS-basierten Endpunkt. Wenn Sie IP-basierte Endpunkte verwenden, können Sie den Zugriff auf eine Reihe bekannter Adressbereiche einschränken, indem Sie autorisierte Netzwerke konfigurieren.
  • Private Knoten konfigurieren: Deaktivieren Sie die externen IP-Adressen Ihrer Knoten, damit Clients außerhalb Ihres Netzwerks nicht auf die Knoten zugreifen können.

Weitere Informationen finden Sie unter Netzwerkisolation.

Wenn Sie diese Funktionen zur Netzwerkisolation nicht aktivieren, sollten Sie alle API-Erkennungsinformationen, insbesondere das Schema von CustomResources, APIService-Definitionen und Erkennungsinformationen, die von Erweiterungs-API-Servern gehostet werden, als öffentlich behandeln.

Teams und Umgebungen in separaten Namespaces oder Clustern platzieren

Gewähren Sie Teams Zugriff auf Kubernetes nach dem Prinzip der geringsten Berechtigung, indem Sie getrennte Namespaces oder Cluster für jedes Team und jede Umgebung erstellen. Weisen Sie jedem Namespace oder Cluster Kostenstellen und Labels für Rechnungslegung und Rückbuchungen zu.

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.

Prinzip der geringsten Berechtigung in Zugriffsrichtlinien anwenden

Empfohlen: Gewähren Sie Entwicklern nur den Zugriff, den sie zum Bereitstellen und Verwalten von Anwendungen in ihrem Namespace benötigen, insbesondere in Produktionsumgebungen. Wenn Sie Ihre Richtlinien zur Zugriffssteuerung entwerfen, legen Sie die Aufgaben fest, die Ihre Nutzer im Cluster ausführen müssen, und gewähren Sie ihnen nur die Berechtigungen, die sie für diese Aufgaben benötigen.

In GKE können Sie IAM und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes verwenden, um Berechtigungen für Ressourcen zu erteilen. Diese Mechanismen zur Zugriffssteuerung arbeiten zusammen. So verringern Sie die Komplexität der Zugriffsverwaltung:

  • Wenn Sie Zugriff auf Ihr Projekt oder auf Google Cloud Ressourcen gewähren möchten, verwenden Sie IAM-Rollen.

  • Um Zugriff auf Kubernetes-Ressourcen in Ihrem Cluster, z. B. Namespaces, zu gewähren, verwenden Sie RBAC.

Weitere Informationen zum Planen und Entwerfen von IAM- und RBAC-Richtlinien finden Sie in den folgenden Dokumenten:

Workload Identity Federation for GKE für den Zugriff auf Google Cloud -APIs verwenden

Empfohlen: Verwenden Sie die Workload Identity-Föderation für GKE, um von Ihren GKE-Arbeitslasten auf Google Cloud -Ressourcen zuzugreifen.

Workload Identity Federation for GKE ist die empfohlene Methode zur Authentifizierung beiGoogle Cloud -APIs. Sie können Hauptkonten in Ihrem Cluster, z. B. bestimmten Kubernetes-Dienstkonten oder Pods, IAM-Rollen für verschiedene Ressourcen zuweisen. Workload Identity Federation for GKE schützt auch sensible Metadaten auf Ihren Knoten und bietet einen sichereren Authentifizierungsworkflow als Alternativen wie statische Tokendateien.

Die Workload Identity-Föderation für GKE ist in Autopilot-Clustern immer aktiviert. Aktivieren Sie in Standardclustern die Workload Identity-Föderation für GKE für alle Cluster und Knotenpools. Beachten Sie außerdem die folgenden Empfehlungen:

  • Wenn Sie Google Cloud Clientbibliotheken in Ihrem Anwendungscode verwenden, verteilen Sie keine Google Cloud Anmeldedaten an Ihre Arbeitslasten. Code, der Clientbibliotheken verwendet, ruft automatisch Anmeldedaten für Workload Identity Federation for GKE ab.
  • Verwenden Sie für jede Arbeitslast, die eine eigene Identität benötigt, einen separaten Namespace und ein separates Dienstkonto. IAM-Berechtigungen für bestimmte Dienstkonten gewähren

Weitere Informationen finden Sie unter Über GKE-Arbeitslasten bei Google Cloud APIs authentifizieren.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.enableWorkloadIdentityFederation-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Zugriff mit Gruppen verwalten

Empfohlen: Erteilen Sie in Ihren Zugriffsrichtlinien Berechtigungen für Nutzergruppen statt für Einzelpersonen.

Wenn Sie Nutzer in Gruppen verwalten, können Ihr Identitätsverwaltungssystem und Ihre Identitätsadministratoren Identitäten zentral steuern, indem sie die Mitgliedschaft von Nutzern in verschiedenen Gruppen ändern. Bei dieser Art der Verwaltung müssen Sie Ihre RBAC- oder IAM-Richtlinien nicht jedes Mal aktualisieren, wenn ein bestimmter Nutzer aktualisierte Berechtigungen benötigt.

Sie können Google-Gruppen in Ihren IAM- oder RBAC-Richtlinien angeben. Weitere Informationen finden Sie in folgenden Dokumenten:

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die verwaltete Einschränkung für Organisationsrichtlinien constraints/container.managed.enableGoogleGroupsRBAC. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Anonymen Zugriff auf Clusterendpunkte einschränken

Empfohlen: Verhindern Sie anonyme Anfragen an alle Clusterendpunkte mit Ausnahme von Endpunkten für den Integritätscheck in allen Autopilot- und Standardclustern.

Standardmäßig weist Kubernetes den Nutzer system:anonymous und die Gruppe system:unauthenticated anonymen Anfragen an Clusterendpunkte zu. Wenn Ihre RBAC-Richtlinien diesem Nutzer oder dieser Gruppe zusätzliche Berechtigungen gewähren, kann ein anonymer Nutzer möglicherweise die Sicherheit eines Dienstes oder des Clusters selbst gefährden.

In GKE-Version 1.32.2-gke.1234000 und höher können Sie die Endpunkte, die anonyme Anfragen erreichen können, auf die Kubernetes API-Server-Systemdiagnose-Endpunkte /healthz, /livez und /readyz beschränken. Anonymer Zugriff auf diese Endpunkte für Systemdiagnosen ist erforderlich, um zu prüfen, ob ein Cluster ordnungsgemäß funktioniert.

Wenn Sie den anonymen Zugriff auf Clusterendpunkte einschränken möchten, geben Sie LIMITED für das Flag --anonymous-authentication-config an, wenn Sie die gcloud CLI oder die GKE API zum Erstellen oder Aktualisieren von Standard- und Autopilot-Clustern verwenden. GKE lehnt anonyme Anfragen an Clusterendpunkte ab, die während der Authentifizierung nicht die Systemdiagnoseendpunkte sind. Anonyme Anfragen erreichen die Endpunkte nicht, auch wenn Ihre RBAC-Richtlinien anonymen Nutzern und Gruppen Zugriff gewähren. Abgelehnte Anfragen geben den HTTP-Status 401 zurück.

In GKE-Version 1.35.0-gke.1171000 und höher wird der anonyme Zugriff auf Endpunkte, die nicht für Health Checks verwendet werden, standardmäßig nur für neu erstellte Cluster verweigert.

Wenn Sie diese Empfehlung in Ihrer Organisation, Ihrem Ordner oder Ihrem Projekt mithilfe einer Organisationsrichtlinie erzwingen möchten, erstellen Sie eine benutzerdefinierte Einschränkung mit der Bedingung resource.anonymousAuthenticationConfig.mode. Weitere Informationen und ein Beispiel für eine Einschränkung finden Sie unter Aktionen für GKE-Ressourcen mithilfe von benutzerdefinierten Organisationsrichtlinien einschränken.

Verlassen Sie sich nicht allein auf diese Funktion, um Ihren Cluster zu schützen. Implementieren Sie zusätzliche Sicherheitsmaßnahmen wie die folgenden:

GKE-Netzwerksicherheit

In den folgenden Abschnitten finden Sie Empfehlungen zur Verbesserung der Netzwerksicherheit in Ihren Clustern. Netzwerkadministratoren und Sicherheitsexperten sollten diese Empfehlungen anwenden, um Arbeitslasten und Infrastruktur vor unbeabsichtigtem externen oder internen Zugriff zu schützen.

Best Practices

Zugriff auf die Steuerungsebene einschränken

Empfohlen: Aktivieren Sie den DNS-basierten Endpunkt für den Zugriff auf die Steuerungsebene und deaktivieren Sie alle IP-basierten Endpunkte der Steuerungsebene.

Standardmäßig können externe Instanzen wie Clients im Internet Ihre Steuerungsebene erreichen. Sie können einschränken, wer auf Ihre Steuerungsebene zugreifen kann, indem Sie Netzwerkisolation konfigurieren.

Führen Sie einen der folgenden Schritte aus, um die Steuerungsebene zu isolieren:

  • Nur den DNS-basierten Endpunkt verwenden (empfohlen): Aktivieren Sie den DNS-basierten Endpunkt für die Steuerungsebene und deaktivieren Sie interne und externe IP-Adressen-basierte Endpunkte. Für den gesamten Zugriff auf die Steuerungsebene muss der DNS-basierte Endpunkt verwendet werden. Mit VPC Service Controls können Sie steuern, wer auf den DNS-basierten Endpunkt zugreifen kann.

    Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.enableControlPlaneDNSOnlyAccess-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud Console prüfen möchten, rufen Sie die Seite Richtliniendetails auf.

    Zu den Richtliniendetails

  • Deaktivieren Sie den externen IP-basierten Endpunkt: Entfernen Sie die externe IP-Adresse der Steuerungsebene. Clients außerhalb Ihres VPC-Netzwerks können nicht über die externe IP-Adresse auf die Steuerungsebene zugreifen.

    Diese Option eignet sich gut, wenn Sie Technologien wie Cloud Interconnect und Cloud VPN verwenden, um Ihr Unternehmensnetzwerk mit Ihrem VPC-Netzwerk zu verbinden.

  • Autorisierte Netzwerke mit dem externen IP-basierten Endpunkt verwenden: Beschränken Sie den Zugriff auf den externen IP-basierten Endpunkt auf einen vertrauenswürdigen Bereich von Quell-IP-Adressen.

    Diese Option eignet sich gut, wenn Sie keine vorhandene VPN-Infrastruktur haben oder wenn Sie Remote-Nutzer oder Zweigstellen haben, die über das öffentliche Internet auf Ihre Cluster zugreifen.

In den meisten Szenarien sollten Sie nur den DNS-basierten Endpunkt für den Zugriff auf die Steuerungsebene verwenden. Wenn Sie den IP-basierten Endpunkt aktivieren müssen, verwenden Sie autorisierte Netzwerke, um den Zugriff auf die Steuerungsebene auf die folgenden Entitäten zu beschränken:

  • Die von Ihnen angegebenen IP-Adressbereiche.
  • GKE-Knoten im selben VPC-Netzwerk wie der Cluster.
  • Von Google reservierte IP-Adressen für die Clusterverwaltung.

Knoten vom Internet isolieren

Standardmäßig haben alle GKE-Knoten eine externe IP-Adresse, die Clients im Internet erreichen können. Wenn Sie diese externe IP-Adresse entfernen möchten, aktivieren Sie private Knoten.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.enablePrivateNodes-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud Console prüfen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Netzwerkverkehr zwischen Pods einschränken

Empfohlen: Steuern Sie den Pod-zu-Pod-Netzwerkverkehr mithilfe von Netzwerkrichtlinien, einem Service Mesh oder beidem.

Standardmäßig kann jeder Pod in Ihrem Cluster mit jedem anderen Pod kommunizieren. Wenn Sie den Netzwerkzugriff zwischen Diensten einschränken, ist es für Angreifer viel schwieriger, sich seitlich in Ihrem Cluster zu bewegen. Ihre Dienste sind außerdem besser vor versehentlichen oder vorsätzlichen Denial-of-Service-Vorfällen geschützt. Je nach Ihren Anforderungen können Sie eine oder beide der folgenden Methoden verwenden, um den Pod-zu-Pod-Traffic einzuschränken:

Schutz sensibler Daten

In den folgenden Abschnitten finden Sie Empfehlungen zum Verschlüsseln von Daten und zum Schutz sensibler Informationen wie Anmeldedaten. Sicherheitstechniker und Plattformadministratoren sollten diese Empfehlungen anwenden, um das Risiko eines unbeabsichtigten Zugriffs auf kritische Daten zu verringern.

Best Practices

Aktive Arbeitslastdaten verschlüsseln

Verwenden Sie die hardwarebasierte Arbeitsspeicherverschlüsselung, um Daten zu schützen, die von Ihren Arbeitslasten verwendet werden, indem Sie Confidential GKE Nodes verwenden. Sie können eine Confidential Computing-Technologie basierend auf Ihren Anforderungen auswählen. Weitere Informationen finden Sie unter Aktive Arbeitslastdaten mit Confidential GKE Nodes verschlüsseln.

Secrets außerhalb des Clusters speichern

Empfohlen: Verwenden Sie einen externen Secret Manager wie Secret Manager, um sensible Daten wie API-Schlüssel außerhalb Ihres Clusters zu speichern.

In Kubernetes können Sie sensible Daten in Secrets in Ihrem Cluster speichern. Mit Secrets können Sie Anwendungen vertrauliche Daten zur Verfügung stellen, ohne diese Daten in den Anwendungscode aufzunehmen. Das Speichern dieser Daten in Ihrem Cluster birgt jedoch Risiken wie die folgenden:

  • Jeder, der Pods in einem Namespace erstellen kann, kann die Daten aller Secrets in diesem Namespace lesen.
  • Alle Nutzer mit RBAC- oder IAM-Zugriff zum Lesen aller Kubernetes API-Objekte können Secrets lesen.

Erstellen Sie Secrets in Ihrem Cluster nur, wenn Sie diese Daten nicht auf andere Weise für Ihre Arbeitslasten bereitstellen können. Wir empfehlen die folgenden Methoden zum Speichern und Zugreifen auf Ihre sensiblen Daten (in der Reihenfolge der Präferenz):

  • Secret Manager-Clientbibliotheken: Sie können programmatisch über Ihren Anwendungscode auf Secrets zugreifen, indem Sie die Secret Manager API mit Workload Identity Federation for GKE verwenden. Weitere Informationen finden Sie unter Mit Clientbibliotheken auf Secrets zugreifen, die außerhalb von GKE-Clustern gespeichert sind.
  • Secret Manager-Daten als eingebundene Volumes: Mit dem Secret Manager-Add-on für GKE können Sie sensible Daten als eingebundene Volumes für Ihre Pods bereitstellen. Diese Methode ist nützlich, wenn Sie Ihren Anwendungscode nicht ändern können, um die Secret Manager-Clientbibliotheken zu verwenden. Weitere Informationen finden Sie unter Secret Manager-Add-on mit Google Kubernetes Engine verwenden.

  • Drittanbietertools zur Verwaltung von Secrets: Drittanbietertools wie HashiCorp Vault bieten Funktionen zur Verwaltung von Secrets für Kubernetes-Arbeitslasten. Diese Tools erfordern mehr Erstkonfiguration als Secret Manager, sind aber eine sicherere Option als das Erstellen von Secrets im Cluster. Informationen zum Konfigurieren eines Drittanbietertools für die Secret-Verwaltung finden Sie in der Dokumentation des Anbieters. Beachten Sie außerdem die folgenden Empfehlungen:

    • Wenn das Drittanbietertool in einem Cluster ausgeführt wird, verwenden Sie einen anderen Cluster als den, in dem Ihre Arbeitslasten ausgeführt werden.
    • Verwenden Sie Cloud Storage oder Spanner, um die Daten des Tools zu speichern.
    • Verwenden Sie einen internen Passthrough-Network Load Balancer, um das Drittanbieter-Tool zur Verwaltung von Secrets für Pods verfügbar zu machen, die in Ihrem VPC-Netzwerk ausgeführt werden.

  • Kubernetes-Secrets verwenden (nicht empfohlen): Wenn keine der vorherigen Optionen für Ihren Anwendungsfall geeignet ist, können Sie die Daten als Kubernetes-Secrets speichern. Google Cloud verschlüsselt Daten auf der Speicherebene standardmäßig. Diese standardmäßige Verschlüsselung der Speicherebene umfasst die Datenbank, in der der Status Ihres Clusters gespeichert wird. Diese basiert entweder auf etcd oder Spanner. Außerdem können Sie diese Secrets auf Anwendungsebene mit einem von Ihnen verwalteten Schlüssel verschlüsseln. Weitere Informationen finden Sie unter Secrets auf Anwendungsebene verschlüsseln.

Arbeitslastsicherheit

In den folgenden Abschnitten finden Sie Empfehlungen zur Verbesserung der Sicherheit Ihres Clusters gegen Probleme mit Arbeitslasten. Sicherheitsingenieure und Plattformadministratoren sollten diese Empfehlungen anwenden, um den Schutz der GKE-Infrastruktur vor Arbeitslasten zu verbessern.

Best Practices

Arbeitslasten mit GKE Sandbox isolieren

Empfohlen: Verwenden Sie GKE Sandbox, um zu verhindern, dass schädlicher Code den Hostkernel auf Ihren Clusterknoten beeinträchtigt.

Sie können Container in einer Sandbox-Umgebung ausführen, um die meisten Container-Escape-Angriffe, auch lokale Rechteausweitungsangriffe genannt, zu minimieren. Wie in den GKE-Sicherheitsbulletins beschrieben, ermöglicht diese Art von Angriff einem Angreifer Zugriff auf die Host-VM des Containers. Der Angreifer kann diesen Hostzugriff nutzen, um auf andere Container auf derselben VM zuzugreifen. GKE Sandbox kann die Auswirkungen dieser Angriffe begrenzen.

Verwenden Sie GKE Sandbox in Szenarien wie den folgenden:

  • Sie haben Arbeitslasten, die nicht vertrauenswürdigen Code ausführen.
  • Sie möchten die Auswirkungen begrenzen, wenn ein Angreifer einen Container in der Arbeitslast manipuliert.

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

Arbeitslastzugriff mithilfe von RBAC einschränken

Empfohlen: Entwerfen und implementieren Sie gute RBAC-Richtlinien, um das Risiko eines unautorisierten Zugriffs durch Arbeitslasten zu verringern.

Kubernetes-Pods verwenden die Identität eines Dienstkontos, um verschiedene Aktionen auszuführen, z. B. auf Ressourcen in anderen Namespaces zuzugreifen oder Daten in Secrets zu lesen. Verwenden Sie RBAC, um die Berechtigungen von ServiceAccounts basierend auf den Anforderungen der entsprechenden Arbeitslasten einzuschränken. Implementieren Sie die Best Practices für RBAC, um das Risiko eines unbefugten Zugriffs durch Arbeitslasten zu verringern.

Richtlinienbasierte Erzwingung

In den folgenden Abschnitten finden Sie Empfehlungen für die Verwendung von Richtlinien zur Erzwingung von Sicherheitsbeschränkungen für mehrere Ressourcen. Identitäts- und Kontoadministratoren sowie Sicherheitsexperten sollten diese Empfehlungen anwenden, um die Compliance von Clustern und Arbeitslasten mit den Sicherheitsanforderungen der Organisation aufrechtzuerhalten.

Best Practices

Richtlinien in der gesamten Google Cloud Ressourcenhierarchie erzwingen

Empfohlen: Wenn Sie Sicherheitsmaßnahmen in Ihrer Organisation, Ihrem Ordner oder Ihrem Projekt erzwingen möchten, verwenden Sie den Organisationsrichtliniendienst.

Mit Organisationsrichtlinien können Sie Einschränkungen zentral definieren und auf verschiedenen Ebenen Ihrer Ressourcenhierarchie erzwingen. Für verschiedene Google Cloud -Produkte werden verwaltete Einschränkungen veröffentlicht, mit denen Sie Best-Practice-Empfehlungen für das jeweilige Produkt anwenden können. GKE veröffentlicht beispielsweise verwaltete Einschränkungen für viele der Best Practices in diesem Dokument.

Weitere Informationen zum Aktivieren von Organisationsrichtlinien finden Sie unter Organisationsrichtlinien erstellen und verwalten.

Richtlinien beim Zulassen von Arbeitslasten erzwingen

Empfohlen: Verwenden Sie einen Admission-Controller wie Policy Controller oder den PodSecurity-Admission-Controller, um eingehende API-Anfragen zu prüfen und Richtlinien für diese Anfragen zu erzwingen.

Admission-Controller fangen authentifizierte, autorisierte Anfragen an die Kubernetes API ab, um Validierungs- oder Mutationsaufgaben auszuführen, bevor eine Ressource in der API beibehalten werden darf.

Sie haben folgende Möglichkeiten, die Zugangssteuerung in GKE-Clustern zu verwenden:

Clusterverwaltung

In den folgenden Abschnitten finden Sie Empfehlungen für die Verwaltung Ihrer Cluster im Laufe der Zeit, z. B. für Upgrades, Monitoring und die Konfiguration von Logs. Sicherheitsingenieure, Plattformadministratoren und SREs sollten diese Empfehlungen verwenden, um den Sicherheitsstatus der GKE-Plattform aufrechtzuerhalten.

Best Practices

GKE-Infrastruktur regelmäßig upgraden

Empfohlen: Halten Sie Ihre GKE-Version auf dem neuesten Stand, um auf neue Sicherheitsfunktionen zuzugreifen und Sicherheitspatches anzuwenden. Verwenden Sie Release-Versionen, beschleunigte automatische Patch-Upgrades und automatische Knotenupgrades.

Für Kubernetes und GKE werden häufig neue Patchversionen veröffentlicht, die Sicherheitsverbesserungen und Korrekturen für Sicherheitslücken enthalten. Bei allen Clustern aktualisiert die GKE die Steuerungsebene automatisch auf stabilere Nebenversionen und Patchversionen.

So sorgen Sie dafür, dass auf Ihrem GKE-Cluster eine aktuelle Version ausgeführt wird:

  • Registrieren Sie Ihre Cluster in einer Release-Version. Autopilot-Cluster sind immer in einer Release-Version registriert.
  • Aktivieren Sie für Cluster, die sich in einer Release-Version befinden, beschleunigte automatische Patch-Upgrades, um Sicherheitspatch-Versionen zu erhalten, sobald sie in Ihrer Release-Version verfügbar sind.
  • Aktivieren Sie für Standardcluster, die nicht in einer Release-Version sind, automatische Knotenupgrades. Das automatische Knoten-Upgrade ist standardmäßig für Cluster aktiviert, die seit Juni 2019 mit derGoogle Cloud Console erstellt wurden, und für Cluster, die seit dem 11. November 2019 mit der GKE API erstellt wurden.
  • Wenn Sie Wartungsrichtlinien verwenden, sollten Sie ein Wartungsfenster verwenden, damit GKE Ihre Knoten mindestens einmal im Monat automatisch aktualisiert.
  • Für Knotenpools, die keine automatischen Knotenupgrades verwenden, sollten Sie die Knotenpools mindestens einmal im Monat nach Ihrem eigenen Zeitplan aktualisieren.
  • Informationen zu Sicherheitspatches finden Sie in den GKE-Sicherheitsbulletins und den GKE-Versionshinweisen.

Benachrichtigungen zu Sicherheitsbulletins aktivieren

Empfohlen: Konfigurieren Sie Benachrichtigungen für neue Sicherheitsbulletins, die sich auf Ihren Cluster auswirken.

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 empfangen, Dienste von Drittanbietern einbinden und Benachrichtigungen in Cloud Logging erhalten.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.enableSecurityBulletinNotifications-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Logerfassung konfigurieren

Empfohlen: Zur Reduzierung des operativen Aufwands und zur Bereitstellung einer konsolidierten Ansicht Ihrer Logs sollten Sie eine einheitliche Logging-Strategie für alle Cluster implementieren. Deaktivieren Sie die Logerfassung in Ihren Standardclustern nicht.

GKE-Cluster senden bestimmte Logs an Google Cloud Observability. Optional können Sie die Erfassung zusätzlicher Logtypen konfigurieren. Zusätzlich zu System- und Arbeitslastlogs senden alle GKE-Cluster die folgenden Audit-Logs an Logging:

  • Kubernetes-Audit-Logs: eine chronologische Aufzeichnung von Aufrufen, die an den Kubernetes API-Server gesendet wurden. Die Kubernetes-Audit-Logeinträge sind nützlich, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen oder Monitoringbenachrichtigungen für unerwünschte API-Aufrufe zu erstellen.
  • GKE-Audit-Logs: Ein Datensatz der Verwaltungs- und Zugriffsaktivitäten für die GKE API.

Weitere Informationen finden Sie in folgenden Dokumenten:

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die verwaltete Einschränkung für Organisationsrichtlinien constraints/container.managed.enableCloudLogging. Wenn Sie diese verwaltete Einschränkung in der Google Cloud Console prüfen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Ressourcen auf Sicherheitsprobleme überwachen

Verwenden Sie das GKE-Dashboard für den Sicherheitsstatus und Security Command Center, um Ihre Cluster und Arbeitslasten auf potenzielle Probleme zu überwachen. Mit diesen Diensten können Sie nach aktiven Sicherheitslücken, Bedrohungen und Sicherheitsbulletins suchen, die sich auf Ihre GKE-Infrastruktur auswirken.

Standardsicherheitskonfigurationen

In den folgenden Abschnitten werden Optionen beschrieben, die standardmäßig in neuen Clustern konfiguriert sind, um bestimmte Sicherheitsrisiken wie Sicherheitslücken oder Risiken zu minimieren. Sicherheitsingenieure und Plattformadministratoren sollten prüfen, ob diese Einstellungen für vorhandene Cluster verwendet werden.

Best Practices

Legacy-Authentifizierungsmethoden für Legacy-Clients aktiviert lassen

Empfohlen: Deaktivieren Sie Legacy-Authentifizierungsmethoden für API-Server wie statische Zertifikate und Passwörter.

Es gibt mehrere Methoden zur Authentifizierung beim Kubernetes API-Server. In GKE sind die unterstützten Methoden Inhabertokens für Dienstkonten, OAuth-Tokens und X.509-Clientzertifikate. Die gcloud CLI verwendet OAuth-Tokens, um Nutzer für GKE zu authentifizieren.

Alte Authentifizierungsmethoden wie statische Passwörter sind deaktiviert, da diese Methoden die Angriffsfläche für Cluster-Compromises vergrößern. In Autopilot-Clustern können Sie diese Authentifizierungsmethoden nicht aktivieren oder verwenden.

Verwenden Sie eine der folgenden Methoden, um sich beim Kubernetes API-Server zu authentifizieren:

  • Nutzer: Verwenden Sie die gcloud CLI, damit GKE Nutzer authentifizieren, OAuth-Zugriffstokens für den Cluster generieren und die Tokens auf dem neuesten Stand halten kann.
  • Anwendungen: Verwenden Sie die Identitätsföderation von Arbeitslasten, damit sich Anwendungen inGoogle Cloud oder in anderen Umgebungen in Ihrem Cluster authentifizieren können.

Weitere Informationen zur Authentifizierung und zum Deaktivieren älterer Authentifizierungsmethoden finden Sie unter Authentifizierung beim Kubernetes API-Server.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.disableLegacyClientCertificateIssuance-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud Console prüfen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

ABAC deaktiviert lassen

Empfohlen: Verwenden Sie IAM und RBAC, um den Zugriff in GKE zu steuern. Aktivieren Sie die attributbasierte Zugriffssteuerung (Attribute-Based Access Control, ABAC) nicht.

ABAC ist eine Legacy-Autorisierungsmethode, die in allen GKE-Clustern standardmäßig deaktiviert ist und in Autopilot-Clustern nicht aktiviert werden kann.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.disableABAC-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Konsole aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Admission-Controller DenyServiceExternalIPs aktiviert lassen

Empfohlen: Deaktivieren Sie den Admission-Controller „DenyServiceExternalIPs“ nicht.

Dieser Admission-Controller blockiert die Verwendung externer IP-Adressen durch Dienste und entschärft GCP-2020-015. Dieser Admission-Controller ist standardmäßig in Clustern aktiviert, die mit GKE-Version 1.21 und höher erstellt wurden. Aktivieren Sie für Cluster, die ursprünglich mit einer früheren GKE-Version erstellt wurden, den Admission-Controller:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.denyServiceExternalIPs-Einschränkung für verwaltete Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud Console prüfen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Nächste Schritte