Sicherheit von Clustern erhöhen

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. Folgen Sie dem vSphere-Sicherheitsleitfaden und den Best Practices für die Verschlüsselung von VMs von VMware.

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 selbst dafür verantwortlich, Ihre GKE On-Prem-Cluster auf dem neuesten Stand zu halten. Lesen Sie bei jedem Release die Versionshinweise. Planen Sie jeden Monat die Aktualisierung auf neue Patchversionen und alle drei Monate die Aktualisierung auf Nebenversionen ein. 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:

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 bei 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.

Abgesehen von den Berechtigungen für Google Cloud-Dienstkonten, die zur Installation von GKE On-Prem 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 sind 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

Konfigurieren Sie einen Secrets-Manager, der in GKE On-Prem-Cluster eingebunden ist, um einen zusätzlichen Schutz für sensible Daten (wie in etcd gespeicherte Kubernetes-Secrets) zu bieten.

Sollten 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. Implementieren Sie Firewallregeln in Ihrem lokalen Netzwerk, 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:

  1. 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.
  2. Verwenden Sie Kubernetes-Netzwerkrichtlinien, um den L4-Traffic zwischen Pods zu steuern. Diese Option ermöglicht eine grundlegende Zugriffssteuerung über Kubernetes.

Sie können sowohl Istio als auch Kubernetes-Netzwerkrichtlinien aktivieren, nachdem Sie Ihre GKE On-Prem-Cluster erstellt haben. Es besteht auch die Möglichkeit, sie bei Bedarf gemeinsam zu 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. Zum automatischen Prüfen dieser Konfigurationen sollten Sie eine Lösung verwenden, die bei 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 für alle bereitgestellten Cluster eine einheitliche Logging-Strategie umsetzen. Die Operations-Suite von Google Cloud ist standardmäßig in GKE On-Prem eingebunden. Sie sollten die Operations-Suite von Google Cloud während der Installation aktivieren. Füllen Sie dazu die stackdriver-Spezifikation in der GKE On-Prem-Konfigurationsdatei aus.

Für alle GKE On-Prem-Cluster ist das 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.

In GKE On-Prem-Clustern kann Kubernetes-Audit-Logging mit Audit-Logs von Google Cloud und Cloud Logging kombiniert werden. 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 (Attribute-Based Access Control, ABAC) auf GKE On-Prem-Clustern deaktiviert und sollte nicht aktiviert werden.

Weitere Informationen