Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfeatures zur Verfügung. In diesem Dokument wird beschrieben, wie Sie Ihre GKE on VMware-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
In der folgenden Bereitstellungscheckliste werden Best Practices zum Härten der Plattformbereitstellung von GKE-Clustern hervorgehoben. 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
vSphere-Kontoberechtigungen verwenden
Das vCenter-Nutzerkonto, mit dem Sie GKE on VMware installieren, muss ausreichende Berechtigungen haben. Beispiel: Ein Nutzerkonto, dem die Administratorrolle von vCenter zugewiesen ist, hat Berechtigungen für den vollständigen Zugriff auf alle vCenter-Objekte und bietet einem GKE on VMware-Clusteradministrator mit uneingeschränktem Zugriff.
Es wird das Prinzip der geringsten Berechtigung empfohlen, bei dem nur die Berechtigungen gewährt werden, die für die erfolgreiche Installation von GKE Enterprise erforderlich sind. 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
Für GKE on VMware sind drei Google Cloud-Dienstkonten erforderlich:
- Ein vordefiniertes Dienstkonto für den Zugriff auf die GKE on VMware-Software. Sie erstellen diesen, wenn Sie GKE Enterprise erwerben.
- Ein Registrierungsdienstkonto, das von Connect zum Registrieren von GKE on VMware-Clustern bei 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-Dienst.
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 Kubernetes RBAC.
Abgesehen von den Berechtigungen für Google Cloud-Dienstkonten, die zur Installation von GKE on VMware verwendet werden, gilt IAM nicht für GKE on VMware-Cluster.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Datenschutz
Virtuelle vSphere-Maschinen verschlüsseln
GKE on VMware-Clusterknoten werden auf virtuellen Maschinen (VMs) in Ihrem vSphere-Cluster ausgeführt. Google empfiehlt dringend, alle inaktiven Daten zu verschlüsseln. Folgen Sie dazu der Anleitung unter VMware vSphere 7 Security Configuration and Hardening Guide 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 Secret-Manager, der in GKE on VMware-Cluster eingebunden ist, um einen zusätzlichen Schutz für sensible 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 die Google Kubernetes Engine als auch für GKE on VMware funktioniert. Wenn Sie einen externen Secrets-Manager wie HashiCorp Vault verwenden möchten, richten Sie diesen vor der Einbindung Ihrer GKE on VMware-Cluster ein.
Für die Verwaltung von Secrets stehen mehrere Möglichkeiten zur Verfügung:
- Sie können Kubernetes-Secrets nativ in GKE on VMware 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
Netzwerkzugang zu Steuerungsebene und Knoten beschrä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 GKE on VMware-Clusterknoten mit RFC 1918-Adressen erstellt. Es wird empfohlen, diese Einstellung 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 GKE on VMware-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 GKE on VMware-Cluster erstellt haben. Es besteht auch die Möglichkeit, sie bei Bedarf gemeinsam zu verwenden.
Weitere Informationen erhalten Sie in dieser Dokumentation:
Deklarative Sicherheit
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.
Die Best Practice ist die Verwendung von Policy Controller. 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 GKE on VMware 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
Upgrade für GKE Enterprise durchführen
Kubernetes implementiert regelmäßig neue Sicherheits-Features und bietet Sicherheitspatches.
Sie sind dafür verantwortlich, Ihre GKE on VMware-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
- Mit den neuesten VMware-Sicherheitshinweisen auf dem Laufenden bleiben
- Folgen Sie der Anleitung zum Anwenden von Patches auf Hosts.
Sicherheitsbulletins überwachen
Das GKE Enterprise-Sicherheitsteam veröffentlicht Sicherheitsbulletins zu Sicherheitslücken mit hohem und kritischem Schweregrad.
Diese Bulletins entsprechen einem gängigen Google Cloud-Schema zur Nummerierung von Sicherheitslücken und sind über die Hauptbulletinseite von Google Cloud und die Versionshinweise für GKE on VMware verlinkt. 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
Optionen für das Logging von GKE-Clustern festlegen
GKE on VMware bietet mehrere Optionen für das Cluster-Logging und -Monitoring, einschließlich cloudbasierter verwalteter Dienste, Open-Source-Tools und validierter Kompatibilität mit kommerziellen Lösungen von Drittanbietern:
- Cloud Logging und Cloud Monitoring, die durch clusterinterne Agents aktiviert werden, die mit GKE on VMware 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
- Anthos Anthos-Cluster auf VMware mit dem Elastic Stack überwachen
- Logs in GKE Enterprise mit Splunk Connect erfassen