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 Root-Anmeldung

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.

Sie können die Knoten in Ihrem Cluster manuell upgraden. GKE bietet aber auch eine automatische Upgradefunktion.

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-Knoten werden als Compute Engine-Instanzen ausgeführt und haben daher standardmäßig Zugriff auf Instanzmetadaten. Über Instanzmetadaten stellen Sie für die Knoten Anmeldedaten und Konfigurationen bereit, die für das Bootstrapping und das Herstellen einer Verbindung zu den Knoten der Steuerungsebene verwendet werden. Für einen auf einem Knoten ausgeführten Pod sind aber solche vertraulichen Daten wie etwa der Dienstkontoschlüssel des Knotens nicht unbedingt erforderlich. Sie können Pfade mit sensiblen Instanzmetadaten auch sperren. Dazu deaktivieren Sie Legacy-APIs und verwenden die Metadatenverbergung. Wenn Sie die Metadaten verbergen, können im Cluster ausgeführte Pods nicht mehr durch Filtern der Anfragen nach Feldern wie kube-env auf sensible Daten zugreifen.

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 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. Mit GKE können Sie 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 Einstellungen nicht im Pod oder Container, sondern auf der Clusterebene ändern möchten, implementieren Sie eine PodSecurityPolicy. Clusteradministratoren können mithilfe von Pod-Sicherheitsrichtlinien dafür sorgen, dass alle Pods in einem Cluster eine grundlegende Mindestrichtlinie erfüllen.

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.

Workload Identity ist die einfachste und sicherste Methode zur Autorisierung von Pods für den Zugriff auf Google Cloud-Ressourcen. Mit Workload Identity kann ein Kubernetes-Dienstkonto als Google Cloud-Dienstkonto ausgeführt werden. Pods, die als Kubernetes-Dienstkonto ausgeführt werden, haben die Berechtigungen des Google Cloud-Dienstkontos.

Workload Identity kann mit GKE Sandbox verwendet werden.

Node-Dienstkonto

Ihre Pods können auch mit den Anmeldedaten des Dienstkontos des Kubernetes-Clusters aus Metadaten in Google Cloud authentifiziert werden. Diese Anmeldedaten können jedoch von jedem im Cluster ausgeführten Pod abgerufen werden, wenn Workload Identity nicht aktiviert ist. Erstellen und konfigurieren Sie ein benutzerdefiniertes Dienstkonto mit der Mindestanzahl an IAM-Rollen, die für alle im Cluster ausgeführten Pods erforderlich sind.

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

JSON-Schlüssel für Dienstkonto

Eine dritte Möglichkeit zur Übermittlung von Anmeldedaten für Google Cloud-Ressourcen an Anwendungen ist die manuelle Verwendung des Dienstkontoschlüssels. Von diesem Ansatz wird dringend abgeraten, da es schwierig ist, Kontoschlüssel sicher zu verwalten.

Verwenden Sie nach Möglichkeit die Anmeldedaten anwendungsspezifischer Google Cloud-Dienstkonten. Anwendungen erhalten dadurch die minimal erforderlichen Berechtigungen. Jedem Dienstkonto sind nur die zum Ausführen der gekoppelten Anwendung benötigten IAM-Rollen zugewiesen. Wenn Sie das Dienstkonto mit einer bestimmten Anwendung verknüpfen, können Sie den Zugriff im Fall einer Manipulation leichter widerrufen, ohne dass sich dies auf andere Anwendungen auswirkt. Sobald 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 Container Registry oder einer anderen Container-Image-Registry an GKE bereitstellen. Mit 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.

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: