Sicherheit

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 hinsichtlich der Zugriffsrechte Ihrer Nutzer und Ihrer Anwendung den Grundsatz der geringsten Berechtigung anwenden. Dabei sind in den verschiedenen Schichten mitunter unterschiedliche Kompromisse einzugehen, um das richtige Maß an Flexibilität für die sichere Bereitstellung und Verwaltung der Arbeitslasten Ihrer Organisation zu gewährleisten. Die Einschränkungen durch gewisse Sicherheitseinstellungen können bei bestimmten Anwendungstypen oder Anwendungsfällen beispielsweise so hoch sein, dass sie nur nach einer umfassenden 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.

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.

Kubernetes-Nutzerkonten werden von Google Cloud in einem GKE-Cluster verwaltet. Dies gilt für zwei Arten von Konten:

  1. Google-Konto
  2. Google Cloud-Dienstkonto

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

Die Konten in Kubernetes und GCP sind beides Dienstkonten, aber unterschiedliche Entitäten. Kubernetes-Dienstkonten sind Teil des Clusters, in dem sie definiert wurden. Sie werden in der Regel in diesem Cluster verwendet. Google Cloud-Dienstkonten hingegen gehören zu einem Google Cloud-Projekt. Ihnen können sowohl in Clustern als auch in Google Cloud-Projektclustern sowie in allen Google Cloud-Ressourcen mit Identity and Access Management (IAM) Berechtigungen zugewiesen werden. Google Cloud-Dienstkonten sind daher leistungsfähiger als Kubernetes-Dienstkonten. Gemäß dem Sicherheitsprinzip der geringsten Berechtigung sollten Sie Google Cloud-Dienstkonten nur verwenden, wenn deren Funktionen explizit 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 haben Sie die Möglichkeit, den Zugriff auf Google-Konten, Google Cloud-Dienstkonten und Kubernetes-Dienstkonten zu steuern. Sie können Ihre Authentifizierungs- und Autorisierungsstrategie für GKE weiter vereinfachen und optimieren. Wichtig ist dabei, dass die attributbasierte Legacy-Zugriffssteuerung deaktiviert ist, damit Kubernetes-RBAC und IAM verwendet werden.

Weitere Informationen:

Sicherheit der Steuerungsebene

In GKE werden die Kubernetes-Komponenten der Steuerungsebene von Google verwaltet und gepflegt. Auf den Komponenten der Steuerungsebene wird die Software für die Ausführung der Kubernetes-Steuerungsebene gehostet. Sie beinhaltet den API-Server, den Planer, den Controller-Manager und die etcd-Datenbank, in der Ihre Kubernetes-Konfiguration gespeichert ist.

Für die Komponenten der Steuerungsebene werden standardmäßig öffentliche IP-Adressen verwendet. Sie haben die Möglichkeit, den Kubernetes API-Server mit autorisierten Netzwerken und privaten Clustern zu schützen. Dadurch können Sie der Steuerungsebene eine private IP-Adresse zuweisen und den Zugriff auf die öffentliche IP-Adresse deaktivieren.

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 zum Schutz der Steuerungsebene bietet die regelmäßige Rotation der Anmeldedaten. In diesem Fall werden die SSL-Zertifikate und die Cluster-Zertifizierungsstelle rotiert. Dieses Verfahren erfolgt in GKE automatisch, um die Rotation Ihrer IP-Adresse der Steuerungsebene zu gewährleisten.

Weitere Informationen:

Knotensicherheit

GKE stellt Ihre Arbeitslasten auf Compute Engine-Instanzen bereit, die in Ihrem Google Cloud-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 Google Cloud verfügbaren Sicherheitsfeatures auf Knotenebene anwenden.

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. 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 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 haben die Möglichkeit, die zu den Pods in einem Namespace aufgebauten ein- und ausgehenden Verbindungen mithilfe von Netzwerkrichtlinien zu 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:

Traffic mit Load-Balancing 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.

Arbeitslasten sichern

Kubernetes bietet Nutzern die Möglichkeit, containerbasierte Arbeitslasten schnell bereitzustellen, zu skalieren und zu aktualisieren. In diesem Abschnitt werden Vorgehensweisen gezeigt, 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 Projekten der Nutzer aktivierten Google Cloud-Dienste beschränken können.

Verarbeitungsrechte für Podcontainer einschränken

Für die allgemeine Clustersicherheit es wichtig, die Berechtigungen von containerisierten Prozessen einzuschränken. GKE Autopilot-Cluster beschränken immer bestimmte Berechtigungen, wie unter Autopilot-Sicherheitsfunktionen 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 und nicht auf 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. Sie können benutzerdefinierte Pod-Sicherheitsrichtlinien auch mithilfe von Gatekeeper auf Clusterebene festlegen.

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 Google Cloud-Ressourcen gewähren

Ihre Container und Pods benötigen möglicherweise Zugriff auf andere Ressourcen in Google Cloud. Dafür gibt es drei Möglichkeiten.

Die sicherste Methode zur Autorisierung von Pods für den Zugriff auf Google Cloud-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 bei Google Cloud 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.

Mit dem Dienstkontoschlüssel können Sie Anwendungen Anmeldedaten für Google Cloud-Ressourcen zuweisen. 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. Gewähren Sie jedem Dienstkonto die IAM-Mindestrollen, die zum Ausführen 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.

Binärautorisierung verwenden

Die Binärautorisierung ist ein Dienst in der Cloud Console, der Softwarelieferkettensicherheit für Anwendungen in der Cloud bietet. Die Binärautorisierung funktioniert mit Images, die Sie von Artifact Registry oder einer anderen Container-Image-Registry an GKE bereitstellen.

Mit der Durchsetzung der Binärautorisierung werden interne Prozesse, die die Qualität und Integrität Ihrer Software gewährleisten, erfolgreich abgeschlossen, bevor eine Anwendung in Ihrer Produktionsumgebung bereitgestellt wird. Weitere Informationen zum Erstellen eines Clusters mit aktivierter Binärautorisierung finden Sie in der Dokumentation zur Binärautorisierung unter Cluster erstellen.

Mit der kontinuierlichen Validierung (Binärautorisierung, CV) können Sie sicherstellen, dass Container-Images, die mit Pods verknüpft sind, regelmäßig überwacht werden, um sicherzustellen, dass sie Ihren sich ändernden internen Prozessen entsprechen.

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.

GKE protokolliert standardmäßig Logs zur Administratoraktivität. 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 Patchen einer Arbeitslast ausführen, validiert ein Zulassungs-Webhook mit dem Namen GKE Warden Ihre Anfrage anhand einer Reihe von eingeschränkten Vorgängen und entscheidet, ob die Anfrage zugelassen wird.

Sicherheitsmaßnahmen für Autopilot-Cluster

Autopilot-Cluster wenden mehrere Sicherheitseinstellungen anhand unserer Expertise und Best Practices der Branche an. Weitere Informationen finden Sie unter Sicherheitsmaßnahmen in Autopilot.

Sicherheitsmaßnahmen für Standardcluster

Standardcluster sind standardmäßig toleranter als Autopilot-Cluster. GKE-Standardcluster haben die folgenden Sicherheitseinstellungen:

  • Sie können das Dienstkonto, das von von GKE verwalteten Systemarbeitslasten verwendet wird, wie Arbeitslasten im Namespace kube-system nicht aktualisieren.
  • Sie können die Standard-ClusterRole cluster-admin nicht an die Gruppen system:anonymous, system:unauthenticated oder system:authenticated binden.