Sicherheit Ihres Clusters erhöhen

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

Sie sollten bereits mit Folgendem vertraut sein:

In neuen GKE-Clustern werden viele der Best Practices in diesem Dokument standardmäßig implementiert. Cluster im Autopilot-Modus haben eine strengere Standardsicherheitskonfiguration 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 suchen Sie nach anderen häufigen Fehlkonfigurationen.
  • Organization Policy Service: Erzwingt 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 -Konsole, über die Sie verwaltete Einschränkungen für diese Empfehlungen anwenden können.

Google Cloud Umweltgestaltung

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 der Google Cloud Architektur berücksichtigen.

Best Practices

Ressourcenstruktur planen Google Cloud

Empfohlen: Implementieren Sie den Blueprint für Unternehmensgrundlagen. Er bietet eine vollständige Grundlage für Ihre Unternehmensumgebung, die auf unseren Best Practices basiert.

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:

Ressourcen mit Tags gruppieren Google Cloud

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

Tags sind Metadaten, die Sie an Ressourcen in Ihren Organisationen, Ordnern und Projekten anhängen 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 Organisationsrichtlinien, IAM-Richtlinien oder Firewallrichtlinien bedingt anzuwenden.

Weitere Informationen finden Sie in folgenden Dokumenten:

VPC-Netzwerke planen

Empfohlen: Implementieren Sie Google Cloud und GKE-Best Practices 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:

Reaktionsplan für Vorfälle entwerfen

Empfohlen: Erstellen und pflegen Sie einen Reaktionsplan für Vorfälle, 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.

Freigegebene 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 Backend-Compute Engine-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 von unberechtigtem Zugriff oder störenden Fehlern 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-Knoten-Dienstkonten mit minimalen 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. Dies 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 der Identitätsföderation von Arbeitslasten für GKE bereit.

Wenn Sie diese Empfehlung in Ihrer Organisation erzwingen möchten, verwenden Sie die constraints/container.managed.disallowDefaultComputeServiceAccount verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console 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 das 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 Knotenintegritätsmonitoring und Secure Boot sind in Autopilot-Clustern immer aktiviert. Gehen Sie in Standardclustern so vor:

  • Deaktivieren Sie Shielded GKE-Knoten nicht in Ihren Clustern.
  • 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 constraints/container.managed.enableShieldedNodes verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console 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. Der kubelet-Prozess 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Zugriffssteuerung

In den folgenden Abschnitten finden Sie Empfehlungen zum Einschränken des unbefugten Zugriffs auf Ihren Cluster. Sicherheitsingenieure und Identitäts- und Kontoadministratoren sollten diese Empfehlungen anwenden, um die Angriffsfläche zu verkleinern und die Auswirkungen eines unbefugten Zugriffs 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 wenig restriktiven Satz von Standardrollen für die API-Erkennung. Diese Standardrollen bieten verschiedenen Standardgruppen, z. B. system:authenticated, einen breiten 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 verwenden

Empfohlen: Gewähren Sie Entwicklern nur den Zugriff, den sie benötigen, um Anwendungen in ihrem Namespace bereitzustellen und zu verwalten, insbesondere in Produktionsumgebungen. Wenn Sie Ihre Richtlinien zur Zugriffssteuerung entwerfen, planen Sie die Aufgaben, 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:

Mit der Identitätsföderation von Arbeitslasten für GKE auf Google Cloud APIs zugreifen

Empfohlen: Verwenden Sie die Identitätsföderation von Arbeitslasten für GKE, um von Ihren GKE-Arbeitslasten aus auf Google Cloud Ressourcen zuzugreifen.

Die Workload Identity-Föderation für 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 Authentifizierungsablauf 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 die Identitätsföderation von Arbeitslasten für GKE ab.
  • Verwenden Sie für jede Arbeitslast, die eine eigene Identität benötigt, einen separaten Namespace und ein separates Dienstkonto. Bestimmten Dienstkonten IAM-Berechtigungen 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Zugriff mit Gruppen verwalten

Empfohlen: Weisen Sie in Ihren Zugriffsrichtlinien Berechtigungen Nutzergruppen anstelle von einzelnen Nutzern zu.

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 constraints/container.managed.enableGoogleGroupsRBAC verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console 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 dem Nutzer system:anonymous und der Gruppe system:unauthenticated anonyme Anfragen an Clusterendpunkte zu. Wenn Ihre RBAC-Richtlinien diesem Nutzer oder dieser Gruppe zusätzliche Berechtigungen erteilen, 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 Anzahl der Endpunkte, die durch anonyme Anfragen erreicht werden können, auf die Kubernetes API-Server-Systemdiagnose-Endpunkte /healthz, /livez und /readyz beschränken. Für den anonymen Zugriff auf diese Systemdiagnose-Endpunkte ist erforderlich, dass 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.

Wenn Sie diese Empfehlung in Ihrer Organisation, Ihrem Ordner oder Ihrem Projekt mit 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 Einheiten 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 DNS-basierten Endpunkt verwenden (empfohlen): Aktivieren Sie den DNS-basierten Endpunkt für die Steuerungsebene und deaktivieren Sie interne und externe IP-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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen 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 ist gut geeignet, wenn Sie keine bestehende VPN-Infrastruktur haben oder wenn Remote-Nutzer oder Zweigstellen über das öffentliche Internet auf Ihre Cluster zugreifen.

In den meisten Fällen 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 für Clients im Internet erreichbar ist. 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Netzwerk-Traffic zwischen Pods einschränken

Empfohlen: Steuern Sie den Pod-zu-Pod-Netzwerktraffic mit NetworkPolicies, einem Service Mesh oder beidem.

Standardmäßig kann jeder Pod in Ihrem Cluster mit jedem anderen Pod kommunizieren. Die Beschränkung des Netzwerkzugriffs zwischen Diensten erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Ihre Dienste sind außerdem besser vor versehentlichen oder absichtlichen Denial-of-Service-Angriffen 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. Sicherheitsingenieure und Plattformadministratoren sollten diese Empfehlungen anwenden, um das Risiko eines unbeabsichtigten Zugriffs auf kritische Daten zu verringern.

Best Practices

Aktive Arbeitslastdaten verschlüsseln

Mit Confidential GKE Nodes können Sie hardwarebasierte Arbeitsspeicherverschlüsselung verwenden, um aktive Daten Ihrer Arbeitslasten zu schützen. Sie können eine Confidential Computing-Technologie entsprechend 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 vertrauliche Daten wie API-Schlüssel außerhalb Ihres Clusters zu speichern.

In Kubernetes können Sie sensible Daten in Secrets in Ihrem Cluster speichern. Sie können Secrets verwenden, um Anwendungen vertrauliche Daten zur Verfügung zu 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 eines beliebigen Secrets in diesem Namespace lesen.
  • Jeder mit RBAC- oder IAM-Zugriff zum Lesen aller Kubernetes API-Objekte kann 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 Abrufen Ihrer vertraulichen 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 der Identitätsföderation von Arbeitslasten für 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 für Ihre Pods als eingebundene Volumes 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 Secret-Verwaltung: Drittanbietertools wie HashiCorp Vault bieten Funktionen zur Secret-Verwaltung für Kubernetes-Arbeitslasten. Diese Tools erfordern mehr anfängliche Konfiguration als Secret Manager, sind aber eine sicherere Option als das Erstellen von Secrets im Cluster. Informationen zum Konfigurieren eines Drittanbieter-Tools 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 zum Speichern der Daten des Tools.
    • 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. Sicherheitsexperten 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 Privilegienerweiterungsangriffe 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 den folgenden Szenarien:

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

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

Empfohlen: Verwenden Sie Zulassungs-Controller, um zu verhindern, dass Arbeitslasten sich selbst ändern oder dass riskante Arbeitslastattribute wie ServiceAccounts geändert werden.

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 in einem Namespace selbst ändert, um als ein privilegierteres Dienstkonto im selben Namespace ausgeführt zu werden.

Erteilen Sie Pods nur bei Bedarf die Berechtigung zur Selbständerung. Wenn einige Pods sich selbst ändern müssen, verwenden Sie Policy Controller, um einzuschränken, was die Arbeitslasten ändern können. Sie können beispielsweise die Einschränkungsvorlage NoUpdateServiceAccount verwenden, um zu verhindern, dass Pods ihr Dienstkonto ändern. Wenn Sie eine Richtlinie erstellen, schließen Sie alle Clusterverwaltungs-Komponenten aus Ihren Einschränkungen aus, wie im folgenden Beispiel:

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

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. Verschiedene Produkte veröffentlichen Google Cloud verwaltete Einschränkungen, mit denen Sie Best Practices 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 bei der Zulassung 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 können die folgenden Methoden für die Zugangssteuerung in GKE-Clustern verwenden:

Clusterverwaltung

In den folgenden Abschnitten finden Sie Empfehlungen für die Verwaltung Ihrer Cluster im Laufe der Zeit, z. B. für das Upgraden, Monitoring und Konfigurieren 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 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 Sicherheits-Patch-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. Die automatische Knotenaktualisierung ist standardmäßig für Cluster aktiviert, die ab Juni 2019 mit derGoogle Cloud Console erstellt wurden, und für Cluster, die ab 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, für die keine automatischen Knotenupgrades verwendet werden, sollten Sie die Knotenpools mindestens einmal im Monat nach eigenem 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console 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. Sie können optional die Erfassung zusätzlicher Logtypen konfigurieren. Zusätzlich zu System- und Arbeitslast-Logs 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 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-Audit-Logs: Eine Aufzeichnung von Administrator- 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 constraints/container.managed.enableCloudLogging verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen 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 Ihre GKE-Infrastruktur betreffen.

Standardsicherheitskonfigurationen

In den folgenden Abschnitten werden Optionen beschrieben, die in neuen Clustern standardmäßig konfiguriert sind, um bestimmte Sicherheitsrisiken wie Schwachstellen oder Risiken zu minimieren. Sicherheitsexperten und Plattformadministratoren sollten prüfen, ob in vorhandenen Clustern diese Einstellungen verwendet werden.

Best Practices

Legacy-Authentifizierungsmethoden für Legacy-Clients aktiviert lassen

Empfohlen: Deaktivieren Sie alte API-Server-Authentifizierungsmethoden wie statische Zertifikate und Passwörter.

Es gibt mehrere Methoden zur Authentifizierung beim Kubernetes API-Server. Die unterstützten Methoden in GKE sind 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-Manipulationen 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: Mit der Identitätsföderation von Arbeitslasten können sich Anwendungen inGoogle Cloud oder in anderen Umgebungen in Ihrem Cluster authentifizieren.

Weitere Informationen zur Authentifizierung und zum Deaktivieren von Legacy-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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console 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 verwaltete Einschränkung für Organisationsrichtlinien. Wenn Sie diese verwaltete Einschränkung in der Google Cloud -Console aufrufen möchten, rufen Sie die Seite Richtliniendetails auf.

Zu den Richtliniendetails

Nächste Schritte