Durch die kontinuierliche Weiterentwicklung von Kubernetes stehen häufig neue Sicherheitsfunktionen zur Verfügung. Diese Seite führt Sie durch die Implementierung unserer aktuellen Anleitung zur Härtung von GKE On-Prem-Clustern.
In diesem Leitfaden werden wichtige Sicherheitsmaßnahmen priorisiert, die beim Erstellen des Clusters eine Aktion von Ihnen erfordern. Weniger kritische Features, standardmäßig sichere Einstellungen und Einstellungen, die nach dem Erstellen des Clusters aktiviert werden können, werden weiter unten beschrieben. Eine allgemeine Übersicht über Sicherheitsthemen finden Sie unter Sicherheit.
vSphere-VMs verschlüsseln
GKE On-Prem-Clusterknoten werden auf virtuellen Maschinen (VMs) in Ihrem vSphere-Cluster ausgeführt. Befolgen Sie den VMware-vSphere-Sicherheitsleitfaden und Best Practices für die Verschlüsselung von VMs.
Upgrades der Infrastruktur zeitnah ausführen
Kubernetes erhält regelmäßig neue Sicherheitsfeatures und bietet Sicherheitspatches. Informationen zu Sicherheitspatches finden Sie in den GKE On-Prem-Sicherheitsbulletins.
Sie sind dafür verantwortlich, Ihre GKE On-Prem-Cluster auf dem neuesten Stand zu halten. Lesen Sie für jede Version die Versionshinweise. Planen Sie jeden Monat die Aktualisierung auf neue Patchversionen und die Aktualisierung auf Nebenversionen alle drei Monate. Informieren Sie sich, wie Sie Upgrades Ihrer Cluster ausführen.
Sie sind auch für das Ausführen von Upgrades und Sicherungen in der vSphere-Infrastruktur verantwortlich:
- Erstellen Sie einen Prozess für das rechtzeitige Ausführen von Patches und Upgrades auf Ihren virtuellen Maschinen.
- Aktuelle Sicherheitshinweise für VMware
- Folgen Sie der Anleitung unter Patches auf Hosts anwenden.
OpenID Connect konfigurieren
Wenn Sie die Nutzerauthentifizierung für Ihre Cluster konfigurieren möchten, verwenden Sie OpenID Connect (OIDC).
Außerdem sollten Sie OIDC-Gruppen nutzen, wenn Sie den Zugriff über rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) gewähren. Dadurch müssen Sie Ihre RBAC-Konfiguration nicht manuell aktualisieren, wenn die Rollen von Nutzern geändert werden müssen.
Grundsatz der geringsten Berechtigung für Google Cloud-Dienstkonten anwenden
GKE On-Prem benötigt vier Google Cloud-Dienstkonten:
- Ein Dienstkonto auf der weißen Liste für den Zugriff auf die GKE On-Prem-Software. Sie erstellen dieses Konto beim Erwerb von Anthos.
- Ein Registrierungsdienstkonto, das von Connect für die Registrierung von GKE On-Prem-Clustern mit Google Cloud verwendet werden soll.
- Ein Verbindungsdienstkonto, das von Connect zum Herstellen einer Verbindung zwischen GKE On-Prem-Clustern und Google Cloud verwendet werden soll.
- Ein Cloud Logging-Dienstkonto zum Erfassen von Clusterlogs zur Verwendung durch Cloud Logging.
Während der Installation binden Sie Identity and Access Management-Rollen an diese Dienstkonten. Diese Rollen gewähren den Dienstkonten bestimmte Berechtigungen innerhalb Ihres Projekts. Sie sollten diese Dienstkonten nach dem Grundsatz der geringsten Berechtigung konfigurieren: Gewähren Sie nur jene Berechtigungen, die für die jeweiligen Rollen der Dienstkonten zum Ausführen ihrer Aufgaben erforderlich sind.
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 Zugriff auf die Namespaces, die sie benötigen, um ihre Anwendungen bereitzustellen und zu verwalten, insbesondere in der Produktion.
Planen Sie die Aufgaben, die Ihre 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.
Neben den Berechtigungen für Google Cloud-Dienstkonten, die zum Installieren von GKE On-Preem verwendet werden, gilt IAM nicht für GKE On-Prem-Cluster.
RBAC-Berechtigungen für die Clustererkennung einschränken
Kubernetes stattet Cluster standardmäßig mit einem wenig eingeschränkten Satz von ClusterRoleBindings zur Erkennung aus. Diese ermöglichen einen breiten Zugriff auf Informationen zu den APIs eines Clusters, einschließlich jener von CustomResourceDefinitions (CRDs). Diese Berechtigungen werden in Kubernetes 1.14 reduziert, das ab GKE On-Prem-Version 1.2 verfügbar ist. Wenn es erforderlich ist, den Zugriff einzuschränken, sollten Sie Ihre lokale Firewall entsprechend konfigurieren.
Secret-Verwaltung
Um einen zusätzlichen Schutz für sensible Daten (wie in etcd gespeicherte Kubernetes-Secrets) zu bieten, konfigurieren Sie einen Secrets-Manager, der in GKE On-Prem-Cluster eingeschlossen ist.
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 GKE On-Prem funktioniert. Wenn Sie einen externen Secrets-Manager wie HashiCorp Vault verwenden möchten, müssen Sie ihn einrichten, bevor Sie Ihre GKE On-Prem-Cluster erstellen.
Für die Verwaltung von Secrets stehen mehrere Möglichkeiten zur Verfügung.
- Sie können Kubernetes-Secrets nativ in GKE On-Prem 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. Zum Verschlüsseln dieser Secrets auf Anwendungsebene können Sie die EncryptionConfig-Datei bearbeiten und ein Key Management Service-Plug-in verwenden.
- 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.
Netzwerkzugang zu Steuerungsebene und Knoten beschränken
Sie sollten die Sichtbarkeit der Steuerungsebene und Knoten Ihres Clusters im Internet einschränken. Diese Einstellungen können nach dem Erstellen des Clusters nicht mehr geändert werden.
Standardmäßig werden GKE On-Prem-Clusterknoten mit RFC 1918-Adressen erstellt. Dies sollten Sie nicht ändern. Sie sollten Firewallregeln in Ihrem lokalen Netzwerk implementieren, um den Zugriff auf die Steuerungsebene einzuschränken.
Mit Netzwerkrichtlinien den Traffic zwischen Pods einschränken
Standardmäßig können alle Dienste in einem GKE On-Prem-Cluster miteinander kommunizieren. Sie sollten die Kommunikation zwischen Diensten je nach Bedarf für Ihre Arbeitslasten steuern.
Das Einschränken des Netzwerkzugriffs auf Dienste erschwert es Angreifern, sich innerhalb des Clusters seitlich zu bewegen. Es 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 von Kubernetes.
Sie können sowohl Istio- als auch Kubernetes-Netzwerkrichtlinien aktivieren, nachdem Sie Ihre GKE On-Prem-Cluster erstellt haben. Sie können sie bei Bedarf auch gemeinsam verwenden.
Richtlinien-Controller von Anthos Config Management verwenden
Kubernetes-Zugangs-Controller sind Plug-ins, die steuern und durchsetzen, wie ein Kubernetes-Cluster verwendet wird. Sie müssen Zugangs-Controller aktivieren, um die erweiterten Sicherheitsfeatures von Kubernetes zu verwenden. Zugangs-Controller sind ein wichtiger Bestandteil des Ansatzes "Defense-in-Depth" zur Härtung Ihres Clusters.
Es empfiehlt sich, Richtlinien-Controller von Anthos Config Management zu verwenden. Richtlinien-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.
Clusterkonfiguration überwachen
Es wird empfohlen, Ihre Clusterkonfigurationen auf Abweichungen von Ihren definierten Einstellungen zu prüfen. Um diese Konfigurationen automatisch zu prüfen, sollten Sie eine Lösung verwenden, die mit Ihren GKE On-Prem-Clustern unabhängig vom Ort ihrer Bereitstellung funktioniert. Siehe Anthos-Partner.
Deaktivierung der Legacy-Methoden zur Clientauthentifizierung beibehalten (Standardeinstellung)
Es gibt mehrere Methoden zur Authentifizierung beim Kubernetes API-Server. OIDC ist der empfohlene Authentifizierungsmechanismus. Die Basisauthentifizierung ist standardmäßig deaktiviert. Verwenden Sie für die Authentifizierung kein x509-Zertifikat.
Aktivierung von Cloud Logging beibehalten (Standardeinstellung)
Zur Reduzierung des operativen Aufwands und zur Bereitstellung einer konsolidierten Ansicht Ihrer Logs sollten Sie eine einheitliche Logging-Strategie für alle bereitgestellten Cluster implementieren. GKE On-Prem ist standardmäßig in die Operations-Suite von Google Cloud eingebunden. Sie sollten die Operations-Suite von Google Cloud während der Installation aktivieren. Füllen Sie dazu die Spezifikation stackdriver in der GKE On-Prem-Konfigurationsdatei aus.
Für alle GKE On-Prem-Cluster ist Kubernetes Audit-Logging standardmäßig aktiviert. Das Audit-Logging speichert eine chronologische Aufzeichnung der Aufrufe, die an den Kubernetes API-Server gesendet wurden. Einträge im Audit-Log sind nützlich, um verdächtige API-Anfragen zu untersuchen, Statistiken zu erfassen und Monitoring-Benachrichtigungen für unerwünschte API-Aufrufe zu erstellen.
GKE On-Prem-Cluster kombinieren Kubernetes-Audit-Logging mit Google Cloud-Audit-Logs und Cloud Logging. GKE On-Prem kann auch von Logging an Ihr eigenes Logging-System weiterleiten.
Die Operations-Suite von Google Cloud erfasst und aggregiert Logs von Ihren Clustern. Wenn Sie die Operations-Suite von Google Cloud aktivieren, erhalten Sie besseren Support von Google. Weitere Informationen finden Sie unter Logging und Monitoring.
Deaktivierung des Kubernetes-Dashboards beibehalten (Standardeinstellung)
Das Kubernetes-Dashboard wird von einem Kubernetes-Dienstkonto mit umfangreichen Berechtigungen unterstützt und wurde in mehreren bekannten Angriffen auf Kubernetes ausgenutzt. Die Google Cloud Console ist die empfohlene Weboberfläche für GKE On-Prem. Sie hat nahezu dieselben Funktionen, unterstützt IAM und Kubernetes RBAC ohne erhöhte Berechtigungen und bietet Anthos-Funktionen wie die Multi-Cluster-Verwaltung.
Das Kubernetes-Dashboard ist nicht in GKE On-Prem enthalten.
Deaktivierung der attributbasierten Zugriffssteuerung beibehalten (Standardeinstellung)
In Kubernetes verwenden Sie RBAC, um auf Cluster- und Namespace-Ebene Berechtigungen für Ressourcen zu erteilen. Mit RBAC können Sie Rollen mit Regeln definieren, die eine Reihe von Berechtigungen enthalten.
Standardmäßig ist die attributbasierte Zugriffssteuerung (ABAC) auf GKE On-Prem-Clustern deaktiviert und sie sollte nicht aktiviert werden.