Cluster härten

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 Bereitstellungscheckliste enthält Best Practices zur Härtung Ihrer GKE-Clusterplattformbereitstellung. 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: Verwenden Sie ein vSphere-Administratorkonto mit minimalen Berechtigungen. Google Cloud-Dienstkonten sichern: Minimieren Sie die Berechtigungen für Google Cloud-Dienstkonten. OpenID Connect (OIDC) konfigurieren: Konfigurieren Sie OpenID Connect für die Nutzerauthentifizierung. Zugriff mit Kubernetes-Namespaces und RBAC einschränken: Verwenden Sie Namespaces mit RBAC für administrative Isolation und Mindestberechtigungen.
Datenschutz	vSphere-VMs verschlüsseln: Legen Sie vSphere fest, dass die von Google Distributed Cloud verwendeten Volumes verschlüsselt werden. Secrets verwalten: Verschlüsseln Sie inaktive Secrets.
Netzwerkschutz	Netzwerkzugriff auf Steuerungsebene und Knoten beschränken: Richten Sie Steuerelemente ein, um die Netzwerke und Knoten der Steuerungsebene zu isolieren und zu schützen. Netzwerkrichtlinien zur Beschränkung des Traffics verwenden: Sie können Netzwerkrichtlinien implementieren, um clusterinternen Traffic einzuschränken.
Deklarative Sicherheit	Policy Controller verwenden: Installieren Sie Policy Controller für deklarative Sicherheitsrichtlinien in Ihren Clustern.
Wartung	Upgrade von GKE Enterprise durchführen: Achten Sie darauf, dass Sie die neueste Version von GKE Enterprise für Ihre Plattform ausführen. Sicherheitsbulletins überwachen: In den GKE Enterprise-Sicherheitsbulletins finden Sie die neuesten Ratschläge und Anleitungen zur Versionsverwaltung.
Monitoring und Logging	Optionen für das Logging von GKE-Clustern festlegen: Logging muss aktiviert und in eine SIEM-Lösung eingebunden sein.

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 ausreichende Berechtigungen haben. Ein Nutzerkonto, dem die vCenter-Rolle „Administrator“ zugewiesen ist, hat beispielsweise Berechtigungen für den vollständigen Zugriff auf alle vCenter-Objekte und bietet einem Google Distributed Cloud-Clusteradministrator vollständigen Zugriff.

Es wird das Prinzip der geringsten Berechtigung empfohlen und es werden nur die erforderlichen Berechtigungen für die erfolgreiche Installation von GKE Enterprise gewährt. 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 Google Distributed Cloud sind drei Google Cloud-Dienstkonten erforderlich:

• Ein vordefiniertes Dienstkonto für den Zugriff auf die Google Distributed Cloud-Software. Sie erstellen ihn, wenn Sie GKE Enterprise kaufen.
• Ein registriertes Dienstkonto, das von Connect zum Registrieren von Google Distributed Cloud-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 Service.

Kubernetes-Namespaces und RBAC zum Einschränken des Zugriffs verwenden

Wenn Sie Teams Zugriff auf Kubernetes mit geringstmöglichen Berechtigungen 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 Google Distributed Cloud verwendet werden, gilt IAM nicht für Google Distributed Cloud-Cluster.

Weitere Informationen erhalten Sie in dieser Dokumentation:

• Dienstkonten und Schlüssel
• Überblick über die Installation
• vCenter-Nutzerkontoberechtigungen

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 der Anleitung unter VMware vSphere 7: Sicherheitskonfiguration und Härtung 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 Google Distributed Cloud-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 Google Kubernetes Engine als auch für Google Distributed Cloud funktioniert. Wenn Sie einen externen Secrets-Manager wie HashiCorp Vault verwenden möchten, richten Sie ihn vor der Einbindung Ihrer Google Distributed Cloud-Cluster ein.

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:

• vSphere-Anforderungen

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. Google Distributed Cloud-Clusterknoten werden standardmäßig 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. Wählen Sie diese Option aus, wenn Sie nach den grundlegenden Funktionen für die Zugriffssteuerung suchen, die von Kubernetes verwaltet werden.

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:

• vSphere-Netzwerk
• Proxy- und Firewallregeln

Deklarative Sicherheit

In diesem Abschnitt finden Sie Empfehlungen zur Sicherung Ihrer Cluster.

Policy Controller verwenden

Kubernetes-Admission-Controller sind Plug-ins, die die Verwendung eines Kubernetes-Clusters steuern und erzwingen. Zugangs-Controller sind ein wichtiger Bestandteil des Ansatzes "Defense-in-Depth" zur Härtung Ihres Clusters.

Es empfiehlt sich, Policy Controller zu verwenden. Policy Controller verwendet das OPA Constraint Framework, um eine Richtlinie 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:

• Pod-Sicherheit mithilfe von Einschränkungen durchsetzen

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 von vornherein 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 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:

• Prozess für zeitgerechte Patches und Upgrades der VMs einrichten
• Mit den neuesten VMware-Sicherheitshinweisen auf dem Laufenden bleiben
• 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 Google Cloud-Nummerierungsschema für Sicherheitslücken und sind auf der Hauptseite der Google Cloud-Bulletins und in den Versionshinweisen für Google Distributed Cloud 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:

• Upgrade für Google Distributed Cloud ausführen

Monitoring und Logging

Google Distributed Cloud 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 Google Distributed Cloud bereitgestellt wurden
• 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
• Monitoring von Google Distributed Cloud mit dem Elastic Stack
• Logs in GKE Enterprise mit Splunk Connect erfassen