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.

Übersicht

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

Authentifizierung und Autorisierung

Sie authentifizieren sich bei GKE On-Prem-Clustern mit OpenID Connect (OIDC) (über kubectl) oder dem 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.

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

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 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 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 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 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 GCP-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

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

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

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
  • Hardwaresicherheitsmodul (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.

HashiCorp Vault

Hardwaresicherheitsmodul

Zurück
Speicher
Weiter
Authentifizierung