GKE-Sicherheitsübersicht

Mit Google Kubernetes Engine (GKE) können Sie Ihre Arbeitslasten auf unterschiedliche Weise schützen. Der Schutz von Arbeitslasten in GKE umfasst verschiedene Ebenen des Stacks wie den Inhalt des Container-Images, die Containerlaufzeit, das Clusternetzwerk und den Zugriff auf den Cluster-API-Server.

Schützen Sie Ihre Cluster und Arbeitslasten nach Möglichkeit mit einem mehrschichtigen Ansatz. Sie können das Prinzip der geringsten Berechtigung auf die Zugriffsebene anwenden, die für Ihre Nutzer und Ihre Anwendung bereitgestellt wird. In jeder Ebene muss Ihre Organisation möglicherweise unterschiedliche Kompromisse eingehen, um das richtige Maß an Flexibilität und Sicherheit zu erreichen, damit Sie Ihre Arbeitslasten sicher bereitstellen und verwalten können. Beispielsweise sind einige Sicherheitseinstellungen möglicherweise zu restriktiv, damit bestimmte Arten von Anwendungen oder Anwendungsfälle ohne umfangreiche Refaktorierung funktionieren.

In diesem Dokument erhalten Sie einen Überblick über die verschiedenen Schichten Ihrer Infrastruktur. Es wird erläutert, wie Sie die Sicherheitsfeatures optimal entsprechend Ihren Anforderungen konfigurieren.

Dieses Dokument richtet sich an Sicherheitsexperten, die Richtlinien und Verfahren zum Schutz der Daten einer Organisation vor unbefugtem Zugriff definieren, verwalten und implementieren. Weitere Informationen zu gängigen Rollen und Beispielaufgaben, auf die wir in Cloud de Confiance by S3NS Inhalten verweisen, finden Sie unter Häufig verwendete GKE-Nutzerrollen und -Aufgaben.

Authentifizierung und Autorisierung

Kubernetes unterstützt zwei Arten der Authentifizierung:

  1. Nutzerkonten sind in Kubernetes bekannte Konten, die jedoch nicht von Kubernetes verwaltet werden. Sie können diese Konten beispielsweise nicht mit kubectl erstellen oder löschen.
  2. Dienstkonten sind in Kubernetes erstellte und verwaltete Konten. Sie können jedoch nur von in Kubernetes erstellten Entitäten wie etwa Pods verwendet werden.

In einem GKE-Cluster werden Kubernetes-Nutzerkonten von Cloud de Confiance by S3NSverwaltet und können einen der folgenden beiden Typen haben:

  1. Google-Konto
  2. Cloud de Confiance by S3NS Dienstkonto

Nach der Authentifizierung müssen Sie diese Identitäten autorisieren, damit sie Kubernetes-Ressourcen erstellen, lesen, aktualisieren oder löschen können.

Trotz der ähnlichen Namen sind Kubernetes-Dienstkonten und Cloud de Confiance -Dienstkonten unterschiedliche Entitäten. Kubernetes-Dienstkonten sind Teil des Clusters, in dem sie definiert wurden. Sie werden in der Regel in diesem Cluster verwendet. Im Gegensatz dazu sindCloud de Confiance -Dienstkonten Teil eines Cloud de Confiance -Projekts. Ihnen können ganz einfach Berechtigungen sowohl innerhalb von Clustern als auch für Cloud de Confiance -Projektcluster selbst sowie für alle Cloud de Confiance -Ressourcen mithilfe von Identity and Access Management (IAM) gewährt werden. Dadurch sind Cloud de Confiance Dienstkonten leistungsfähiger als Kubernetes-Dienstkonten. Um dem Sicherheitsprinzip der geringsten Berechtigung zu folgen, sollten Sie Cloud de Confiance Dienstkonten nur verwenden, wenn ihre Funktionen erforderlich sind.

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). Mit RBAC können Sie detaillierte Richtlinien erstellen, in denen Sie definieren, auf welche Vorgänge und Ressourcen Nutzer und Dienstkonten Zugriff haben. Mit RBAC können Sie den Zugriff für Google-Konten, Cloud de Confiance Dienstkonten und Kubernetes-Dienstkonten steuern. Um Ihre Authentifizierungs- und Autorisierungsstrategie für GKE weiter zu vereinfachen und zu optimieren, sollten Sie dafür sorgen, dass die attributbasierte Legacy-Zugriffssteuerung deaktiviert ist, sodass Kubernetes RBAC und IAM die Quellen der Wahrheit sind.

Weitere Informationen:

Sicherheit der Steuerungsebene

In GKE werden die Kubernetes-Komponenten der Steuerungsebene von Google verwaltet und gepflegt. Die Komponenten der Steuerungsebene hosten die Software, die die Kubernetes-Steuerungsebene ausführt, einschließlich des API-Servers, des Schedulers, des Controller-Managers und der etcd API. Wenn der Cluster etcd-Datenbankinstanzen auf den VMs der Steuerungsebene ausführt, werden diese Instanzen auch von Google verwaltet und gewartet.

Sie können über einen DNS-basierten Endpunkt (empfohlen), IP-basierte Endpunkte oder beides auf die Steuerungsebene zugreifen. Wenn Sie IP-basierte Endpunkte verwenden, können Sie den Kubernetes API-Server mit autorisierten Netzwerken schützen und den externen Endpunkt der Steuerungsebene nicht aktivieren. So können Sie der Steuerungsebene eine interne IP-Adresse zuweisen und den Zugriff über die externe IP-Adresse deaktivieren. Wenn Sie einen DNS-basierten Endpunkt verwenden, können Sie den Zugriff auf die Steuerungsebene mit IAM und VPC Service Controls mit identitäts- und netzwerkbezogenen Richtlinien schützen.

Für die Clusterauthentifizierung in Google Kubernetes Engine können Sie IAM als Identitätsanbieter verwenden. Informationen zur Authentifizierung finden Sie unter Authentifizierung beim Kubernetes API-Server.

Eine weitere Möglichkeit, die Steuerungsebene zu schützen, besteht darin, regelmäßig eine Rotation von Anmeldedaten durchzuführen. Wenn die Rotation von Anmeldedaten initiiert wird, werden die SSL-Zertifikate und die Cluster-Zertifizierungsstelle rotiert. Dieser Vorgang wird von GKE automatisiert und trägt auch dazu bei, dass die IP-Adresse der Steuerungsebene rotiert.

Weitere Informationen:

Knotensicherheit

GKE stellt Ihre Arbeitslasten auf Compute Engine-Instanzen bereit, die in Ihrem Cloud de Confiance -Projekt ausgeführt werden. Diese Instanzen werden Ihrem GKE-Cluster als Knoten angehängt. In den folgenden Abschnitten wird erläutert, wie Sie die in Cloud de Confianceverfügbaren Sicherheitsfeatures auf Knotenebene nutzen.

Container-Optimized OS

Standardmäßig wird auf GKE-Knoten als Betriebssystem für die Ausführung von Kubernetes und dessen Komponenten Container-Optimized OS von Google verwendet. Container-Optimized OS implementiert verschiedene erweiterte Features zur Verbesserung der Sicherheit von GKE-Clustern. Hierzu zählen:

  • Eine gesperrte Firewall
  • Nach Möglichkeit ein schreibgeschütztes Dateisystem
  • Eingeschränkte Nutzerkonten und eine deaktivierte Rootanmeldung

GKE Autopilot-Knoten verwenden immer Container-Optimized OS als Betriebssystem.

Knotenupgrades

Eine bewährte Methode besteht darin, Ihr Betriebssystem regelmäßig zu patchen. Gelegentlich können Sicherheitsprobleme in der Containerlaufzeit, in Kubernetes selbst oder im Betriebssystem des Knotens ein vorzeitiges Upgrade der Knoten erforderlich machen. Durch ein Upgrade des Knotens wird die Knotensoftware auf die neueste Version aktualisiert.

GKE-Cluster unterstützen automatische Upgrades. In Autopilot-Clustern sind automatische Upgrades immer aktiviert. Sie können die Knoten auch in einem Standardcluster manuell aktualisieren.

Knoten vor nicht vertrauenswürdigen Arbeitslasten schützen

Für Cluster mit unbekannter oder nicht vertrauenswürdiger Arbeitslast wird empfohlen, das Betriebssystem auf dem Knoten vor der nicht vertrauenswürdigen Arbeitslast zu schützen, die in einem Pod ausgeführt wird.

Beispielsweise führen mehrmandantenfähige Cluster wie Software-as-a-Service-Anbieter (SaaS) häufig unbekannten Code aus, der von ihren Nutzern gesendet wurde. Sicherheitsforschung ist eine weitere Anwendung, bei der Arbeitslasten möglicherweise eine stärkere Isolierung benötigen als von Knoten standardmäßig angeboten.

Sie können GKE Sandbox in Ihrem Cluster aktivieren, um nicht vertrauenswürdige Arbeitslasten in Sandboxes auf dem Knoten zu isolieren. GKE Sandbox wird auf Basis des Open-Source-Projekts gVisor entwickelt.

Instanzmetadaten schützen

GKE verwendet Instanzmetadaten aus den zugrunde liegenden Compute Engine-Instanzen, um Knoten Anmeldedaten und Konfigurationen zur Verfügung zu stellen, die zum Bootstrapping von Knoten und zum Herstellen einer Verbindung zur Steuerungsebene verwendet werden. Diese Metadaten enthalten vertrauliche Informationen, auf die Pods auf dem Knoten nicht zugreifen müssen, wie z. B. den Dienstkontoschlüssel des Knotens.

Sie können Pfade mit sensiblen Instanzmetadaten auch sperren. Dazu verwenden Sie die Workload Identity-Föderation für GKE. Die Workload Identity-Föderation für GKE aktiviert den GKE-Metadatenserver in Ihrem Cluster, der Anfragen nach sensiblen Feldern wie kube-env filtert.

Die Workload Identity-Föderation für GKE ist in Autopilot-Clustern immer aktiviert. In Standardclustern haben Pods Zugriff auf Instanzmetadaten, es sei denn, Sie aktivieren die Workload Identity-Föderation für GKE manuell.

Netzwerksicherheit

Die meisten in GKE ausgeführten Arbeitslasten müssen mit anderen Diensten kommunizieren, die entweder innerhalb oder außerhalb des Clusters ausgeführt werden. Sie können den in Ihren Clustern und deren Pods zulässigen Traffic auf verschiedene Weise kontrollieren.

Kommunikation zwischen Pods einschränken

Standardmäßig sind alle in einem Cluster befindlichen Pods anhand ihrer Pod-IP-Adresse über das Netzwerk erreichbar. Ebenso sind bei ausgehendem Traffic ausgehende Verbindungen zu jeder zugänglichen IP-Adresse in der VPC, in der der Cluster bereitgestellt wurde, standardmäßig zulässig.

Clusteradministratoren und -nutzer können die eingehenden und ausgehenden Verbindungen, die zu und von den Pods in einem Namespace erstellt werden, mithilfe von Netzwerkrichtlinien sperren. Wenn keine Netzwerkrichtlinien definiert sind, wird der gesamte ein- und ausgehende Traffic zu und von allen Pods zugelassen. Durch Netzwerkrichtlinien können Sie den in Ihren Pods zulässigen Traffic mithilfe von Tags definieren.

Sobald Sie in einem Namespace eine Netzwerkrichtlinie anwenden, wird der gesamte Traffic zu und von Pods, der nicht mit den konfigurierten Labels übereinstimmt, gelöscht. Sie können beim Erstellen von Clustern und/oder Namespaces den gesamten ein- und ausgehenden Traffic jedes Pods standardmäßig ablehnen. Dies gewährleistet, dass alle dem Cluster neu hinzugefügten Arbeitslasten den erforderlichen Traffic explizit autorisieren müssen.

Weitere Informationen:

Load-Balancing-Traffic filtern

Für das Load-Balancing Ihrer Kubernetes-Pods mit einem Netzwerk-Load-Balancer müssen Sie einen Dienst vom Typ LoadBalancer erstellen, der mit den Labels Ihres Pods übereinstimmt. Sie erhalten zu dem erstellten Dienst eine von außen erreichbare IP-Adresse, die den Ports Ihrer Kubernetes-Pods zugeordnet ist. Die Filterung des autorisierten Traffics erfolgt auf Knotenebene mit kube-proxy nach IP-Adresse.

Verwenden Sie die loadBalancerSourceRanges-Konfiguration des Dienstobjekts, um die Filterung zu konfigurieren. Mit diesem Konfigurationsparameter können Sie eine Liste von CIDR-Bereichen für den Zugriff auf den Dienst bereitstellen. Wenn Sie loadBalancerSourceRanges nicht konfigurieren, können alle Adressen über die externe IP-Adresse auf den Dienst zugreifen.

Wenn kein externer Zugriff auf den Dienst erforderlich ist, kann ein interner Load-Balancer von Vorteil sein. Der interne Load-Balancer berücksichtigt loadBalancerSourceRanges auch, wenn Traffic in der VPC herausgefiltert werden muss.

Weitere Informationen finden Sie in der Anleitung zum internen Load-Balancing.

Traffic außerhalb des Clusters filtern

Um den Fluss des Netzwerkverkehrs zwischen externen Entitäten und Ihrem Cluster zu steuern, verwenden Sie die Cloud Next Generation Firewall. Mit Firewallkonfigurationen können Sie beispielsweise ausgehenden Traffic von Ihren Pods zu nicht genehmigten Zielen blockieren.

Firewallkonfigurationen reichen nicht aus, um zu steuern, aus welchen Registries die Container-Images in Ihrem Cluster stammen. Informationen zum Beschränken von Container-Image-Pulls auf eine Reihe genehmigter Registries finden Sie unter Container-Images aus nicht genehmigten Registries blockieren.

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 eines ausgeführten Containers auf andere Container im selben Cluster, auf die Knoten, auf denen Container ausgeführt werden können, und auf die in den Projekten der Nutzer aktivierten Cloud de Confiance-Dienste begrenzen können.

Berechtigungen für containerisierte Pod-Prozesse einschränken

Für die allgemeine Clustersicherheit es wichtig, die Berechtigungen von containerisierten Prozessen einzuschränken. In GKE Autopilot-Clustern werden immer bestimmte Berechtigungen eingeschränkt, wie unter Sicherheitsfunktionen von Autopilot beschrieben.

Mit GKE können Sie auch für Pods und Container sicherheitsrelevante Optionen über den Sicherheitskontext festlegen. Sie haben dadurch die Möglichkeit, die Sicherheitseinstellungen etwa von folgenden Prozessen zu ändern:

  • Nutzer und Gruppe für die Ausführung
  • Verfügbare Linux-Funktionen
  • Eskalation von Berechtigungen

Wenn Sie diese Einschränkungen auf Clusterebene anstelle von Pod- oder Containerebene erzwingen möchten, verwenden Sie den PodSecurityAdmission-Controller. Clusteradministratoren können mithilfe von PodSecurityAdmission dafür sorgen, dass alle Pods in einem Cluster oder Namespace einer vordefinierten Richtlinie in den Pod-Sicherheitsstandards entsprechen.

Die GKE-Knotenbetriebssysteme, sowohl Container-Optimized OS als auch Ubuntu, wenden die standardmäßigen AppArmor-Sicherheitsrichtlinien von Docker 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:

  • Dateien direkt in /proc/ schreiben
  • In Dateien schreiben, die sich nicht in einem Prozess-ID-Verzeichnis befinden (/proc/<number>)
  • In Dateien in /proc/sys schreiben, die sich nicht im Verzeichnis /proc/sys/kernel/shm* befinden
  • Dateisysteme bereitstellen

Weitere Informationen:

Pods Zugriff auf Cloud de Confiance Ressourcen gewähren

Ihre Container und Pods benötigen möglicherweise Zugriff auf andere Ressourcen inCloud de Confiance. Dafür gibt es drei Möglichkeiten.

Die sicherste Methode zur Autorisierung von Pods für den Zugriff auf Cloud de Confiance -Ressourcen ist die Workload Identity-Föderation für GKE. Mit der Workload Identity-Föderation für GKE kann ein Kubernetes-Dienstkonto als IAM-Dienstkonto ausgeführt werden. Pods, die als Kubernetes-Dienstkonto ausgeführt werden, haben die Berechtigungen des IAM-Dienstkontos.

Die Workload Identity-Föderation für GKE kann mit GKE Sandbox verwendet werden.

Node-Dienstkonto

In Standardclustern können sich Ihre Pods auch beiCloud de Confiance mit den Anmeldedaten des Dienstkontos authentifizieren, das von der Compute Engine-VM (virtuelle Maschine) des Knotens verwendet wird.

Dieser Ansatz ist nicht mit GKE Sandbox kompatibel, da GKE Sandbox den Zugriff auf den Compute Engine-Metadatenserver blockiert.

Sie können Anwendungen mithilfe des Dienstkontoschlüssels Anmeldedaten für Cloud de Confiance -Ressourcen gewähren. Von diesem Ansatz wird dringend abgeraten, da es schwierig ist, Kontoschlüssel sicher zu verwalten.

Wenn Sie sich für diese Methode entscheiden, verwenden Sie für jede Anwendung benutzerdefinierte IAM-Dienstkonten, damit Anwendungen die minimal erforderlichen Berechtigungen haben. Weisen Sie jedem Dienstkonto die minimalen IAM-Rollen zu, die für die erfolgreiche Ausführung der gekoppelten Anwendung erforderlich sind. Bei anwendungsspezifischen Dienstkonten können Sie den Zugriff im Falle einer Manipulation leichter widerrufen, ohne Auswirkungen auf andere Anwendungen. Nachdem Sie Ihrem Dienstkonto die richtigen IAM-Rollen zugewiesen haben, können Sie einen JSON-Dienstkontoschlüssel erstellen und diesen mit einem Kubernetes-Secret in Ihrem Pod bereitstellen.

Audit-Logging

Mit Audit-Logging können Administratoren Ereignisse in Ihren GKE-Umgebungen speichern, abfragen, verarbeiten und melden. Sie können anhand der Loginformationen forensische Analysen ausführen, Benachrichtigungen in Echtzeit senden oder die Verwendung einer Reihe von GKE-Clustern unter Angabe des Zwecks und des Nutzers katalogisieren.

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

Weitere Informationen:

Integrierte Sicherheitsmaßnahmen

GKE erzwingt bestimmte Einschränkungen dafür, was man mit Systemobjekten in Ihren Clustern tun kann. Wenn Sie einen Vorgang wie das Erstellen oder Patchen einer Arbeitslast ausführen, wird Ihre Anfrage von einem Zulassungs-Webhook namens warden-validating anhand einer Reihe eingeschränkter Vorgänge validiert. Anschließend wird entschieden, ob die Anfrage zulässig ist.

Zugangsfehler, die durch diese Richtlinie verursacht werden, sehen in etwa so aus:

GKE Warden rejected the request because it violates one or more constraints.

Sicherheitsmaßnahmen für Autopilot-Cluster

In Autopilot-Clustern werden mehrere Sicherheitseinstellungen basierend auf unserem Fachwissen und Best Practices der Branche angewendet. Weitere Informationen finden Sie unter Sicherheitsmaßnahmen in Autopilot.