Sie betrachten die Dokumentation für eine frühere Version von GKE On-Prem. Sehen Sie sich die aktuelle Dokumentation an.

Sicherheit

Auf dieser Seite werden die Sicherheitsfunktionen von GKE On-Prem beschrieben, einschließlich der einzelnen Ebenen der Infrastruktur. Außerdem erfahren Sie, wie Sie diese Sicherheitsfunktionen entsprechend Ihren Anforderungen konfigurieren können.

Überblick

GKE On-Prem 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 gewährleisten.

Authentifizierung und Autorisierung

Sie authentifizieren sich bei GKE On-Prem-Clustern mit OpenID Connect (OIDC) (über kubectl) oder Kubernetes-Dienstkontotoken über die Cloud Console.

Wenn Sie einen genauer definierten Zugriff auf Kubernetes-Ressourcen auf Clusterebene oder in Kubernetes-Namespaces konfigurieren möchten, verwenden Sie die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) von Kubernetes. Mit RBAC können Sie detaillierte Richtlinien erstellen, die 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.

Um Ihre Authentifizierungs- und Autorisierungsstrategie für Kubernetes Engine weiter zu vereinfachen und zu optimieren, deaktiviert GKE On-Prem die alte attributbasierte Zugriffssteuerung (Attribute Based Access Control, ABAC).

Weitere Informationen finden Sie unter Kubernetes Engine-Umgebung für die Produktion vorbereiten.

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

In GKE On-Prem werden die Komponenten der Steuerungsebene in Ihrem Unternehmensnetzwerk ausgeführt. Sie können den API-Server von GKE On-Prem mit Ihren vorhandenen Unternehmensnetzwerkrichtlinien und Firewalls schützen. Sie können dem API-Server auch eine private IP-Adresse zuweisen und den Zugriff auf die private Adresse beschränken.

Die gesamte Kommunikation in GKE On-Prem erfolgt über TLS-Kanäle, die von drei Zertifizierungsstellen (etcd, Cluster und Organisation) gesteuert werden:

  • Die etcd-Zertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und den etcd-Replikaten sowie den Traffic zwischen etcd-Replikaten. Diese Zertifizierungsstelle (CA) ist selbstsigniert.
  • Die Clusterzertifizierungsstelle sichert die Kommunikation zwischen dem API-Server und allen internen Kubernetes API-Clients (Kubelets, Controller, Planer). Diese Zertifizierungsstelle (CA) ist selbstsigniert.
  • Die Organisationszertifizierungsstelle ist eine externe Zertifizierungsstelle, die die Kubernetes API für externe Nutzer bereitstellt. Sie verwalten diese Zertifizierungsstelle.

Bei Administratorsteuerungsebenen werden Schlüssel im Knoten der Steuerungsebene gespeichert. Bei Nutzerclustern werden die Schlüssel als Kubernetes-Secrets in der Administratorsteuerungsebene 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 Cluster-CA signierte Schlüssel oder der von der Organisations-CA signierte Schlüssel verwendet werden soll.

Die Clusterauthentifizierung in GKE On-Prem 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 erstmalige 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 nur selten oder bei Bedarf rotiert werden.

Knotensicherheit

GKE On-Prem stellt Ihre Arbeitslasten in VMware-Instanzen bereit, die als Knoten an Ihre Cluster angehängt sind. In den folgenden Abschnitten erfahren Sie, wie Sie die Sicherheitsfunktionen auf Knotenebene in GKE On-Prem nutzen können.

Ubuntu

GKE On-Prem verwendet eine optimierte Version von Ubuntu als Betriebssystem für die Ausführung der Kubernetes-Steuerungsebene und -Knoten. Ubuntu bietet eine Vielzahl moderner Sicherheitsfunktionen und GKE On-Prem implementiert mehrere Funktionen zum Steigern der Sicherheit für Cluster, darunter:

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 Knotensoftware 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 verhindern können, dass die ausgeführten Container andere Container im Cluster, die Hosts, auf denen sie ausgeführt werden, und die in ihrem Projekt aktivierten GCP-Dienste beeinflussen.

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. Mit diesen Einstellungen können Sie die Sicherheitseinstellungen Ihrer Prozesse ändern:

  • Nutzer und Gruppe für die Ausführung
  • Verfügbare Linux-Funktionen
  • Rechteausweitung.

Wenn Sie diese Einstellungen auf Clusterebene statt auf Pod- oder Containerebene ändern möchten, müssen Sie eine PodSecurityPolicy-Ressource erstellen. Pod-Sicherheitsrichtlinien stellen sicher, dass alle Pods in einem Cluster einer von Ihnen definierten grundlegenden Mindestrichtlinie entsprechen.

Das standardmäßige GKE On-Prem-Knotenbetriebssystem Ubuntu wendet die standardmäßigen Docker AppArmor-Sicherheitsrichtlinien auf alle von Kubernetes gestarteten Container an. Sie können die Profilvorlage auf GitHub ansehen. Mit diesem Profil können unter anderem die folgenden Aktionen von Containern nicht ausgeführt werden:

  • Direktes Schreiben in Dateien in einem Prozess-ID-Verzeichnis (/proc/)
  • Schreiben in Dateien, die sich nicht in /proc/ befinden
  • Schreiben in Dateien in /proc/sys mit Ausnahme von /proc/sys/kernel/shm*
  • Abhängen von Dateisystemen

Audit-Logging

Kubernetes-Audit-Logging bietet Administratoren die Möglichkeit, Ereignisse in Ihren GKE On-Prem-Umgebungen zu speichern, abzufragen, zu verarbeiten und entsprechende Benachrichtigungen auszugeben. 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.

Standardmäßig erfasst GKE On-Prem Administratoraktivitäten in Logs. Abhängig von der Art der für Sie relevanten Operationen haben Sie auch die Möglichkeit, Datenzugriffsereignisse zu loggen.

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 in Logs erfasst.

Verschlüsselung

Der Google Cloud Key Management Service (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-P256 und EC-P384 generieren, verwenden, rotieren und löschen. Cloud KMS ist in Cloud IAM und Cloud Audit Logging eingebunden. Sie haben dadurch die Möglichkeit, Berechtigungen für einzelne Schlüssel zu verwalten und die Verwendung dieser Schlüssel zu überwachen. Verwenden Sie Cloud KMS zum Schützen von Secrets und anderen sensiblen Daten, die Sie speichern müssen.

Wenn Ihre GKE On-Prem-Cluster und -Arbeitslasten über Cloud VPN sicher mit Google Cloud-Diensten verbunden sind, können Sie Cloud KMS für die Schlüsselverwaltung verwenden. Andernfalls können Sie eine der folgenden Alternativen verwenden:

  • Kubernetes-Secrets
  • HashiCorp Vault
  • Hardware Security Module (HSM)

Kubernetes-Secrets

Kubernetes-Secrets-Ressourcen speichern vertrauliche Daten wie Passwörter, OAuth-Tokens und SSH-Schlüssel in Ihren Clustern. 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 sensible Daten verwendet werden, und das Risiko verringern, dass die Daten nicht autorisierten Nutzern zugänglich gemacht werden.

HashiCorp Vault

Hardwaresicherheitsmodul