Auf dieser Seite werden die Sicherheitsfeatures von Google Distributed Cloud beschrieben, einschließlich der einzelnen Infrastrukturebenen. Außerdem erfahren Sie, wie Sie diese Sicherheitsfeatures entsprechend Ihren Anforderungen konfigurieren können.
Überblick
GKE on VMware bietet verschiedene Features zum Schutz Ihrer Arbeitslasten, einschließlich des Inhalts Ihres Container-Images, der Containerlaufzeit, des Clusternetzwerks und des Zugriffs auf den Cluster-API-Server.
Schützen Sie Ihre Cluster und Arbeitslasten nach Möglichkeit mit einem mehrschichtigen Ansatz. Sie können den Grundsatz der geringsten Berechtigung auf die Zugriffsebene anwenden, die Sie für Ihre Nutzer und Arbeitslasten bereitstellen. Möglicherweise müssen Sie Kompromisse eingehen, um das richtige Maß an Flexibilität und Sicherheit zu erreichen.
Authentifizierung und Autorisierung
Die Authentifizierung bei GKE on VMware-Clustern erfolgt über OpenID Connect (OIDC) oder ein Kubernetes-Dienstkontotoken über die Cloud Console.
Zum Konfigurieren detaillierterer Zugriffsrechte für Kubernetes-Ressourcen auf der Clusterebene oder innerhalb von Kubernetes-Namespaces verwenden Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes. Mit RBAC lassen sich detaillierte Richtlinien erstellen. Diese Richtlinien definieren, für welche Vorgänge und Ressourcen Sie Nutzern und Dienstkonten Zugriff gewähren möchten. Mit RBAC können Sie den Zugriff für jede bereitgestellte validierte Identität steuern.
Zur weiteren Vereinfachung und Optimierung Ihrer Authentifizierungs- und Autorisierungsstrategie für Kubernetes Engine deaktiviert GKE on VMware die attributbasierte Legacy-Zugriffssteuerung (Attribute-Based Access Control, ABAC).
Sicherheit der Steuerungsebene
Die Komponenten der Steuerungsebene umfassen den Kubernetes API-Server, den Planer, die Controller und die etcd-Datenbank, in der Ihre Kubernetes-Konfiguration beibehalten wird. Während in Kubernetes Engine die Komponenten der Kubernetes-Steuerungsebene von Google verwaltet und gepflegt werden, verwalten lokale Administratoren die Komponenten der Steuerungsebene in GKE on VMware.
In GKE on VMware werden die Komponenten der Steuerungsebene in Ihrem Unternehmensnetzwerk ausgeführt. Sie können den API-Server von GKE on VMware mithilfe Ihrer vorhandenen Unternehmensnetzwerkrichtlinien und Firewalls schützen. Es ist auch möglich, dem API-Server eine private IP-Adresse zuzuweisen und den Zugriff auf die private Adresse zu beschränken.
Die gesamte Kommunikation in GKE on VMware erfolgt über TLS-Kanäle, die von drei Zertifizierungsstellen verwaltet werden: etcd, Cluster und Organisation:
- Die etcd-Zertifizierungsstelle sorgt für die Sicherheit der Kommunikation vom API-Server zu den etcd-Replikaten sowie des Traffics zwischen etcd-Replikaten. Diese Zertifizierungsstelle ist selbst signiert.
- Die Clusterzertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und allen internen Kubernetes API-Clients (Kubelets, Controller, Planer). Diese Zertifizierungsstelle ist selbst signiert.
- Die Organisationszertifizierungsstelle ist eine externe Zertifizierungsstelle, mit der die Kubernetes API für externe Nutzer bereitgestellt wird. Diese Zertifizierungsstelle wird von Ihnen verwaltet.
Bei Administrator-Steuerungsebenen werden Schlüssel im Knoten der Steuerungsebene gespeichert. Bei Nutzerclustern werden die Schlüssel als Kubernetes-Secrets in der Administrator-Steuerungsebene gespeichert. Der API-Server ist mit einem vom Nutzer bereitgestellten Zertifikat konfiguriert, das von der Organisationszertifizierungsstelle signiert ist. Der API-Server verwendet Server Name Indication (SNI), um zu bestimmen, ob der von der Clusterzertifizierungsstelle signierte Schlüssel oder der von der Organisationszertifizierungsstelle signierte Schlüssel verwendet werden soll.
Die Clusterauthentifizierung in GKE on VMware erfolgt über Zertifikate und Dienstkonto-Inhabertokens. Als Administrator authentifizieren Sie sich bei der Steuerungsebene mithilfe von OIDC oder mit dem Administratorzertifikat, das Sie für die anfängliche Erstellung von Rollenbindungen oder für Notfallzwecke verwenden.
Die Zertifikatsrotation wird so durchgeführt:
- Für den API-Server, die Steuerungsebenen und Knoten werden bei jedem Upgrade Zertifikate erstellt oder rotiert.
- Zertifizierungsstellen können selten oder bei Bedarf rotiert werden.
Knotensicherheit
GKE on VMware stellt Ihre Arbeitslasten in VMware-Instanzen bereit, die als Knoten an Ihre Cluster angehängt sind. In den folgenden Abschnitten wird gezeigt, wie Sie die in GKE on VMware verfügbaren Sicherheitsfeatures auf Knotenebene nutzen.
Ubuntu
GKE on VMware verwendet eine optimierte Version von Ubuntu als Betriebssystem für die Ausführung der Kubernetes-Steuerungsebene und -Knoten. Ubuntu bietet eine Vielzahl moderner Sicherheitsfeatures und GKE on VMware implementiert mehrere sicherheitssteigernde Features für Cluster, darunter:
- Images sind vorkonfiguriert, um die Standards von PCI DSS, NIST Baseline High und DoD Cloud Computing SRG Impact 2 zu erfüllen.
- Einen optimierten Satz von Paketen
- Einen Google Cloud-spezifischen Linux-Kernel
- Optionale automatische Betriebssystem-Sicherheitsupdates
- Eingeschränkte Nutzerkonten und eine deaktivierte Root-Anmeldung
Für Ubuntu sind zusätzliche Sicherheitsleitfäden verfügbar, z. B.:
Knotenupgrades
Sie sollten regelmäßig Upgrades Ihrer Knoten ausführen. Bei Sicherheitsproblemen in der Containerlaufzeit, in Kubernetes selbst oder im Betriebssystem des Knotens kann ein vorzeitiges Upgrade der Knoten erforderlich sein. Durch ein Upgrade des Clusters wird die Software der einzelnen Knoten auf die neueste Version aktualisiert.
Arbeitslasten sichern
Kubernetes bietet Nutzern die Möglichkeit, containerbasierte Arbeitslasten schnell bereitzustellen, zu skalieren und zu aktualisieren. In diesem Abschnitt werden Taktiken beschrieben, mit denen Administratoren und Nutzer die Auswirkungen der ausgeführten Container auf andere Container im Cluster, auf die Hosts, auf denen sie ausgeführt werden, und auf die im zugehörigen Projekt aktivierten Google Cloud-Dienste begrenzen können.
Verarbeitungsrechte für Podcontainer einschränken
Für die allgemeine Clustersicherheit es wichtig, die Berechtigungen von containerisierten Prozessen einzuschränken. Mit Kubernetes Engine können Sie sicherheitsrelevante Optionen über den Sicherheitskontext für Pods und Container festlegen. Sie haben dadurch die Möglichkeit, die Sicherheitseinstellungen von Prozessen wie die folgenden zu ändern:
- Nutzer und Gruppe für die Ausführung
- Verfügbare Linux-Funktionen
- Rechteausweitung
Das standardmäßige GKE on VMware-Knotenbetriebssystem Ubuntu wendet die standardmäßigen Docker AppArmor-Sicherheitsrichtlinien auf alle von Kubernetes gestarteten Container an. Sie können die Profilvorlage GitHub ansehen. Das Profil verweigert Containern unter anderem die folgenden Aktionen:
- Direktes Schreiben in Dateien in einem Prozess-ID-Verzeichnis (/proc/)
- Schreiben in Dateien, die sich nicht in "/proc/" befinden
- In Dateien in "/proc/sys" schreiben, die sich nicht im Verzeichnis "/proc/sys/kernel/shm*" befinden
- Bereitstellen von Dateisystemen
Audit-Logging
Mit Kubernetes-Audit-Logging können Administratoren Ereignisse in Ihren GKE on VMware-Umgebungen speichern, abfragen, verarbeiten und melden. Administratoren können die protokollierten Informationen für forensische Analysen und Echtzeitbenachrichtigungen verwenden oder katalogisieren, wie und von wem eine Gruppe von Kubernetes Engine-Clustern verwendet wird.
GKE on VMware protokolliert standardmäßig Administratoraktivitäten. Abhängig von der Art der für Sie relevanten Operationen haben Sie auch die Möglichkeit, Datenzugriffsereignisse zu protokollieren.
Der Connect-Agent kommuniziert nur mit dem lokalen API-Server, der lokal ausgeführt wird, und jeder Cluster muss eigene Audit-Logs haben. Alle Aktionen, die Nutzer in der Benutzeroberfläche über Connect ausführen, werden von diesem Cluster protokolliert.
Verschlüsselung
Wenn Ihre GKE on VMware-Cluster und -Arbeitslasten über Cloud VPN eine sichere Verbindung zu Google Cloud-Diensten herstellen, können Sie den Cloud Key Management Service (Cloud KMS) für die Schlüsselverwaltung verwenden. Cloud KMS ist ein in der Cloud gehosteter Schlüsselverwaltungsdienst, mit dem Sie kryptografische Schlüssel für Ihre Dienste verwalten können. Sie können kryptografische Schlüssel der Varianten AES-256, RSA-2048, RSA-3072, RSA-4096, EC P-256 und EC P-384 erstellen, verwenden, rotieren und löschen. Cloud KMS ist in Identity and Access Management (IAM) und Cloud-Audit-Logging eingebunden. So können Sie Berechtigungen für einzelne Schlüssel verwalten und die Verwendung der Schlüssel im Blick behalten. Verwenden Sie Cloud KMS zum Schützen von Secrets und anderen vertraulichen Daten, die Sie speichern müssen. Andernfalls können Sie eine der folgenden Alternativen nutzen:
- Kubernetes-Secrets
- HashiCorp Vault
- Thales-Luna-Netzwerk HSM
- Google Cloud Hardware Security Module (HSM)
Kubernetes-Secrets
In den Ressourcen von Kubernetes-Secrets werden sensible Daten wie Passwörter, OAuth-Tokens und SSH-Schlüssel in Ihren Clustern gespeichert. Das Speichern sensibler Daten in Secrets ist sicherer als das Speichern in ConfigMaps im Klartext oder in Pod-Spezifikationen. Mit Secrets können Sie steuern, wie sensible Daten verwendet werden, und das Risiko verringern, die Daten nicht autorisierten Nutzern zugänglich zu machen.
HashiCorp Vault
Hardwaresicherheitsmodul
- Verschlüsseln Sie die Nutzercluster-Secrets mit HSM-basierter Secret-Verschlüsselung auf dem Thales-Lina-Netzwerk-MHD.
- Google Cloud HSM