Auf dieser Seite werden die Sicherheitsfunktionen von Google Distributed Cloud (nur Software) für VMware beschrieben, einschließlich der einzelnen Ebenen der Infrastruktur. Außerdem erfahren Sie, wie Sie diese Sicherheitsfunktionen entsprechend Ihren Anforderungen konfigurieren können.
Übersicht
Google Distributed Cloud (nur Software) für VMware bietet verschiedene Funktionen 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
Sie authentifizieren sich bei Ihren Clustern über OpenID Connect (OIDC) oder ein Kubernetes-Dienstkonto-Token ü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 die Kubernetes Engine deaktiviert Google Distributed Cloud die alte attributbasierte 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 GKE die Komponenten der Kubernetes-Steuerungsebene von Google verwaltet und gepflegt werden, verwalten lokale Administratoren die Komponenten der Steuerungsebene in Google Distributed Cloud.
In Google Distributed Cloud werden die Komponenten der Steuerungsebene in Ihrem Unternehmensnetzwerk ausgeführt. Sie können den Kubernetes API-Server mithilfe Ihrer vorhandenen Unternehmensnetzwerkrichtlinien und Firewalls schützen. Es ist auch möglich, dem API-Server eine interne IP-Adresse zuzuweisen und den Zugriff auf die Adresse zu beschränken.
Die gesamte Kommunikation in Google Distributed Cloud erfolgt über TLS-Kanäle, die von drei Zertifizierungsstellen (etcd, Cluster und Organisation) gesteuert werden:
- 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 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
Google Distributed Cloud stellt Ihre Arbeitslasten in VMware-Instanzen bereit, die als Knoten an Ihre Cluster angehängt sind. In den folgenden Abschnitten wird erläutert, wie Sie die verfügbaren Sicherheitsfeatures auf Knotenebene verwenden.
Ubuntu
Google Distributed Cloud 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 Google Distributed Cloud implementiert mehrere sicherheitsfördernde 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 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 Audit-Logging von Kubernetes können Administratoren Ereignisse in Ihren Google Distributed Cloud-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.
In Google Distributed Cloud werden standardmäßig Administratoraktivitäten protokolliert. 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 Cluster und Arbeitslasten über Cloud VPN sicher mit Google Cloud-Diensten verbunden sind, können Sie für die Schlüsselverwaltung den Cloud Key Management Service (Cloud KMS) 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 Secret-Ressourcen von Kubernetes werden vertrauliche Daten wie Passwörter, OAuth-Tokens und SSH-Schlüssel in Ihren Clustern gespeichert. Das Speichern vertraulicher Daten in Secrets ist sicherer als das Speichern in Klartext-ConfigMaps oder in Pod-Spezifikationen. Mithilfe von Secrets können Sie steuern, wie vertrauliche Daten verwendet werden, und das Risiko verringern, dass die Daten nicht autorisierten Nutzern zugänglich gemacht werden.