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

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: 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	Virtuelle vSphere-Maschinen verschlüsseln: Stellen Sie vSphere so ein, 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 eine deklarative Sicherheitsrichtlinie in Ihren Clustern.
Wartung	Upgrade für GKE Enterprise ausführen: Prüfen Sie, ob Sie die neueste Version von GKE Enterprise für Ihre Plattform verwenden. Sicherheitsbulletins überwachen: Die neuesten Ratschläge und Anleitungen zur Versionsverwaltung finden Sie in den GKE Enterprise-Sicherheitsbulletins.
Monitoring und Logging	Optionen für das Logging von GKE-Clustern festlegen: Achten Sie darauf, dass Logging aktiviert und in eine SIEM-Lösung eingebunden ist.

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. 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 Google Distributed Cloud-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 Google Distributed Cloud sind drei Google Cloud-Dienstkonten erforderlich:

• Ein vordefiniertes Dienstkonto für den Zugriff auf die Google Distributed Cloud-Software. Sie erstellen diesen, wenn Sie GKE Enterprise erwerben.
• Ein Registrierungsdienstkonto, 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-Dienst.

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

Wenn Sie Teams Zugriff auf Kubernetes nach dem Prinzip der geringsten Berechtigung 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 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 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 die 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 diesen 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. Standardmäßig werden Google Distributed Cloud-Clusterknoten mit RFC 1918-Adressen erstellt. Es empfiehlt sich, 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 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 die grundlegenden von Kubernetes verwalteten Zugriffssteuerungsfunktionen verwenden möchten.

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

Dieser Abschnitt enthält Empfehlungen zum Sichern Ihrer Cluster.

Policy Controller verwenden

Kubernetes-Admission-Controller sind Plug-ins, die steuern und erzwingen, 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:

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

• Richten Sie einen Prozess ein, um zeitgerechte Patches und Upgrades Ihrer VMs durchzuführen.
• 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 richten sich nach einem gängigen Schema für die Nummerierung von Google Cloud-Sicherheitslücken und sind über die Hauptbulletinseite von Google Cloud und in den Versionshinweisen von 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 durchfü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 von clusterinternen 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
• Google Distributed Cloud mit dem Elastic Stack überwachen
• Logs in GKE Enterprise mit Splunk Connect erfassen