Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfeatures zur Verfügung. In diesem Dokument wird beschrieben, wie Sie Ihre Google Distributed Cloud-Cluster härten.
In diesem Leitfaden werden wichtige Sicherheitsmaßnahmen priorisiert, die beim Erstellen des Clusters eine Aktion von Ihnen erfordern. Weniger zentrale Features, sichere Standardeinstellungen sowie Einstellungen, die nach der Clustererstellung aktiviert werden können, werden weiter unten in diesem Dokument behandelt. Eine allgemeine Übersicht über Sicherheitsthemen finden Sie unter Sicherheit.
Checkliste
Die folgende Checkliste für die Bereitstellung enthält Best Practices zur Härtung Ihrer GKE-Cluster-Plattformbereitstellung. Weitere Informationen zu den einzelnen Vorgehensweisen finden Sie in den Abschnitten in diesem Dokument.
| Checkliste für die Bereitstellung | Beschreibung |
|---|---|
| Identitäts- und Zugriffssteuerung | vSPS-Kontoberechtigungen verwenden: Google Cloud-Dienstkonten sichern: OpenID Connect (OIDC) konfigurieren: Zugriff mit Kubernetes-Namespaces und RBAC einschränken: |
| Datenschutz | Virtuelle vSphere-Maschinen verschlüsseln: Secrets verwalten: |
| Netzwerkschutz | Netzwerkzugriff auf Steuerungsebene und Knoten beschränken: Netzwerkrichtlinien zur Beschränkung des Traffics verwenden: |
| Deklarative Sicherheit | Policy Controller verwenden: |
| Wartung | Upgrade für GKE Enterprise ausführen: Sicherheitsbulletins überwachen: |
| Monitoring und Logging | Optionen für das Logging von GKE-Clustern festlegen: |
Identitäts- und Zugriffssteuerung
Dieser Abschnitt enthält Informationen zum Steuern des Zugriffs auf Ihre Cluster.
vSphere-Kontoberechtigungen verwenden
Das vCenter-Nutzerkonto, mit dem Sie Google Distributed Cloud installieren, muss entsprechende Berechtigungen haben. Ein Nutzerkonto, dem die vCenter-Administratorrolle zugewiesen ist, verfügt beispielsweise über Berechtigungen für den vollständigen Zugriff auf alle vCenter-Objekte und bietet einem Google Distributed Cloud-Clusteradministrator Vollzugriff.
Es wird empfohlen, das Prinzip der geringsten Berechtigung zu verwenden und nur die notwendigen Berechtigungen für die erfolgreiche Installation von GKE Enterprise zu gewähren. Wir haben die Mindestanzahl von Berechtigungen vordefiniert, die für die Installation erforderlich sind, sowie die Befehle, die zum Erteilen dieser Berechtigungen erforderlich sind.
Google Cloud-Dienstkonten sichern
Google Distributed Cloud benötigt drei Google Cloud-Dienstkonten:
- Ein vordefiniertes Dienstkonto für den Zugriff auf die Google Distributed Cloud-Software. Sie erstellen dieses Konto beim Erwerb von GKE Enterprise.
- Ein Registrierungsdienstkonto, das von Connect zum Registrieren von Google Distributed Cloud-Clustern mit Google Cloud verwendet werden soll.
- Ein Cloud Logging-Dienstkonto zum Erfassen von Clusterlogs, die von Cloud Logging verwendet werden.
Während der Installation binden Sie Identity and Access Management-Rollen an diese Dienstkonten. Diese Rollen gewähren den Dienstkonten in Ihrem Projekt bestimmte Berechtigungen und können während der Installation generiert werden.
Authentifizierung für Clusternutzer konfigurieren
Zur Konfiguration der Nutzerauthentifizierung für Ihren Cluster können Sie OpenID Connect (OIDC) oder Lightweight Directory Access Protocol (LDAP) verwenden.
Weitere Informationen finden Sie unter GKE Identity Service.
Kubernetes-Namespaces und RBAC zum Einschränken des Zugriffs verwenden
Wenn Sie Teams mithilfe geringster Berechtigungen den Zugriff auf Kubernetes gewähren möchten, erstellen Sie Kubernetes-Namespaces oder umgebungsspezifische Cluster. Weisen Sie jedem Namespace Kostenstellen und entsprechende Labels für Rechnungslegung und Rückbuchungen zu. Gewähren Sie Entwicklern nur jenen Zugriff auf ihre Namespaces, den sie benötigen, um ihre Anwendungen bereitzustellen und zu verwalten, insbesondere in der Produktion.
Ordnen Sie die Aufgaben zu, die Nutzer für den Cluster ausführen müssen, und definieren Sie die Berechtigungen, die zum Ausführen der einzelnen Aufgaben erforderlich sind. Um Berechtigungen auf Cluster- und Namespaceebene zu gewähren, verwenden Sie RBAC.
Abgesehen von den Berechtigungen für Google Cloud-Dienstkonten, die zur Installation von Google Distributed Cloud verwendet werden, gilt IAM nicht für Google Distributed Cloud-Cluster.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Datenschutz
Dieser Abschnitt enthält Informationen zum Schutz Ihrer Daten.
Virtuelle vSphere-Maschinen verschlüsseln
Google Distributed Cloud-Clusterknoten werden auf virtuellen Maschinen (VMs) in Ihrem vSphere-Cluster ausgeführt. Google empfiehlt dringend, alle inaktiven Daten zu verschlüsseln. Folgen Sie dazu auf vSphere dem Leitfaden zur Sicherheitskonfiguration und -härtung von VMware vSphere 7 und den Best Practices für die Verschlüsselung von VMs.
Dies muss vor der Installation von GKE Enterprise erfolgen.
Secrets verwalten
Konfigurieren Sie einen Secrets-Manager, der in Google Distributed Cloud-Cluster auf VMware-Cluster eingebunden ist, um einen zusätzlichen Schutz für vertrauliche Daten (wie in etcd gespeicherte Kubernetes-Secrets) zu bieten.
Wenn Sie Arbeitslasten in mehreren Umgebungen ausführen, bevorzugen Sie möglicherweise eine Lösung, die sowohl für Google Kubernetes Engine als auch für Google Distributed Cloud funktioniert. Wenn Sie einen externen Secrets-Manager wie HashiCorp Vault verwenden möchten, sollten Sie ihn einrichten, bevor Sie Ihre Google Distributed Cloud-Cluster einbinden.
Für die Verwaltung von Secrets stehen mehrere Möglichkeiten zur Verfügung:
- Sie können Kubernetes-Secrets nativ in Google Distributed Cloud verwenden. Wir gehen davon aus, dass Cluster wie zuvor beschrieben die vSphere-Verschlüsselung für VMs verwenden, die eine grundlegende Verschlüsselung inaktiver Daten für Secrets bietet. Secrets werden standardmäßig nicht weiter verschlüsselt.
- Sie haben die Möglichkeit, einen externen Secrets-Manager wie HashiCorp Vault zu verwenden. Sie können sich mit einem Kubernetes-Dienstkonto oder einem Google Cloud-Dienstkonto bei HashiCorp authentifizieren.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Netzwerkschutz
Dieser Abschnitt enthält Informationen zum Schutz Ihres Netzwerks.
Netzwerkzugriff auf Steuerungsebene und Knoten einschränken
Sichtbarkeit der Steuerungsebene und Knoten Ihres Clusters im Internet beschränken. Diese Einstellungen können nach dem Erstellen des Clusters nicht mehr geändert werden. Standardmäßig werden Google Distributed Cloud-Clusterknoten mit RFC 1918-Adressen erstellt. Es empfiehlt sich, dies nicht zu ändern. Firewallregeln in Ihrem lokalen Netzwerk implementieren, um den Zugriff auf die Steuerungsebene einzuschränken.
Traffic mithilfe von Netzwerkrichtlinien einschränken
Standardmäßig können alle Dienste in einem Google Distributed Cloud-Cluster miteinander kommunizieren. Informationen zur Steuerung der Dienst-zu-Dienst-Kommunikation je nach Arbeitslast finden Sie in den folgenden Abschnitten.
Die Beschränkung des Netzwerkzugriffs auf Dienste erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Sie bietet Diensten außerdem einen gewissen Schutz vor versehentlichen oder absichtlichen "Denial-of-Service"-Angriffen. Es gibt zwei empfohlene Methoden zur Steuerung des Traffics:
- Verwenden Sie Istio, um den L7-Traffic zu Ihren Anwendungsendpunkten zu steuern. Wählen Sie diese Option aus, wenn Sie an Load-Balancing, Dienstautorisierung, Drosselung, Kontingenten und Messwerten interessiert sind.
- Verwenden Sie Kubernetes-Netzwerkrichtlinien, um den L4-Traffic zwischen Pods zu steuern. Diese Option bietet eine einfache Möglichkeit der Zugriffssteuerung mit Kubernetes.
Sie können sowohl Istio- als auch Kubernetes-Netzwerkrichtlinien aktivieren, nachdem Sie Ihre Google Distributed Cloud-Cluster erstellt haben. Es besteht auch die Möglichkeit, sie bei Bedarf gemeinsam zu verwenden.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Deklarative Sicherheit
Dieser Abschnitt enthält Empfehlungen zum Sichern Ihrer Cluster.
Policy Controller verwenden
Kubernetes-Zugangs-Controller sind Plug-ins, die steuern und durchsetzen, wie ein Kubernetes-Cluster verwendet wird. Zugangs-Controller sind ein wichtiger Bestandteil des Ansatzes "Defense-in-Depth" zur Härtung Ihres Clusters.
Als Best Practice wird empfohlen, Policy Controller zu verwenden. Policy Controller verwendet das OPA Constraint Framework, um Richtlinien als CRDs zu beschreiben und durchzusetzen. Die Einschränkungen, die Sie auf Ihre Cluster anwenden möchten, sind in den Einschränkungsvorlagen definiert, die in Ihren Clustern bereitgestellt werden.
Informationen dazu, wie Sie Einschränkungen von Policy Controller verwenden, um viele der Schutzmaßnahmen wie PodSecurityPolicies mit der zusätzlichen Möglichkeit, Ihre Richtlinien vor der Erzwingung zu testen, finden Sie unter Pod-Sicherheit mithilfe von Einschränkungen durchsetzen.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Möglichkeit einschränken, dass sich Arbeitslasten selbst ändern
Bestimmte Kubernetes-Arbeitslasten, insbesondere Systemarbeitslasten, haben die Berechtigung, sich selbst zu ändern. Beispielsweise werden einige Arbeitslasten automatisch vertikal skaliert. Dies ist zwar praktisch, kann einem Angreifer, der bereits einen Knoten manipuliert hat, aber auch die Möglichkeit bieten, im Cluster weiter zu eskalieren. Ein Angreifer kann beispielsweise dafür sorgen, dass sich eine Arbeitslast auf dem Knoten selbst ändert, um als ein privilegierteres Dienstkonto ausgeführt zu werden, das im selben Namespace vorhanden ist.
Idealerweise sollten Arbeitslasten nicht die Berechtigung erhalten, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, können Sie die Berechtigungen einschränken, indem Sie Gatekeeper- oder Policy Controller-Einschränkungen anwenden, z. B. NoUpdateServiceAccount aus der Open-Source-Gatekeeper-Bibliothek, die mehrere nützliche Sicherheitsrichtlinien bietet.
Wenn Sie Richtlinien bereitstellen, müssen die Controller, die den Clusterlebenszyklus verwalten, normalerweise die Richtlinien und die Logging- und Monitoring-Pipelines umgehen. Dies ist erforderlich, damit die Controller Änderungen am Cluster vornehmen können, z. B. durch das Anwenden von Clusterupgrades. Wenn Sie beispielsweise die Richtlinie NoUpdateServiceAccount in Google Distributed Cloud bereitstellen, müssen Sie die folgenden Parameter in Constraint festlegen:
parameters:
allowedGroups:
- system:masters
allowedUsers:
- system:serviceaccount:kube-system:monitoring-operator
- system:serviceaccount:kube-system:stackdriver-operator
- system:serviceaccount:kube-system:metrics-server-operator
- system:serviceaccount:kube-system:logmon-operator
Wartung
Dieser Abschnitt enthält Informationen zum Verwalten Ihrer Cluster.
Upgrade für GKE Enterprise durchführen
Kubernetes implementiert regelmäßig neue Sicherheits-Features und bietet Sicherheitspatches.
Sie sind selbst dafür verantwortlich, Ihre Google Distributed Cloud-Cluster auf dem neuesten Stand zu halten. Lesen Sie für jede Version die Versionshinweise. Planen Sie außerdem jeden Monat die Aktualisierung auf neue Patchversionen und alle drei Monate auf Nebenversionen ein. Informieren Sie sich, wie Sie Upgrades Ihrer Cluster ausführen.
Sie sind auch für Upgrades und Sicherungen in der vSphere-Infrastruktur verantwortlich:
- Festlegen eines Prozesses, der zeitnahes Patching und Upgrades Ihrer VMs durchführt
- Bleiben Sie mit den neuesten VMware-Sicherheitshinweisen auf dem Laufenden.
- Folgen Sie der Anleitung unter Patches auf Hosts anwenden.
Sicherheitsbulletins überwachen
Das Sicherheitsteam von GKE Enterprise veröffentlicht Sicherheitsbulletins für Sicherheitslücken mit hohem und kritischem Schweregrad.
Diese Bulletins folgen einem gängigen Schema zur Sicherheitslückennummer für Google Cloud und sind über die Hauptseite der Google Cloud-Bulletins und die Google Distributed Cloud-Versionshinweise verknüpft. Jede Sicherheitsbulletin-Seite verfügt über einen RSS-Feed, über den Nutzer Updates abonnieren können.
Wenn Kunden Maßnahmen ergreifen müssen, um diese Sicherheitslücken mit hohem und kritischem Schweregrad zu adressieren, kontaktiert Google Kunden per E-Mail. Darüber hinaus kann Google Kunden mit Supportverträgen auch über Supportkanäle kontaktieren.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Monitoring und Logging
Google Distributed Cloud bietet mehrere Optionen für das Cluster-Logging und -Monitoring, darunter cloudbasierte verwaltete Dienste, Open-Source-Tools und validierte Kompatibilität mit kommerziellen Lösungen von Drittanbietern:
- Cloud Logging und Cloud Monitoring, aktiviert von In-Cluster-Agents, die mit Google Distributed Cloud bereitgestellt werden
- Validierte Konfigurationen mit Lösungen von Drittanbietern
Unabhängig von der Logging-Lösung, die Sie je nach Geschäftsanforderungen ausgewählt haben, empfehlen wir Ihnen dringend, vorwärts-relevante Ereignisse und Benachrichtigungen an einen zentralen SIEM-Dienst (Security Information and Event Management) zur Verwaltung von Sicherheitsvorfällen zu senden.
Weitere Informationen erhalten Sie in dieser Dokumentation:
- Logging und Monitoring
- Logging und Monitoring verwenden
- Logging und Monitoring für Anwendungen
- Google Distributed Cloud mit dem Elastic Stack überwachen
- Logs von GKE Enterprise mit Splunk Connect erfassen