Sicherheit

Auf dieser Seite wird die Sicherheitsarchitektur von GKE on AWS beschrieben, einschließlich der Verschlüsselung und Knotenkonfiguration.

GKE-Cluster bieten verschiedene Funktionen zum Schutz Ihrer Arbeitslasten, darunter den Inhalt des Container-Images, die Containerlaufzeit, das Clusternetzwerk und den Zugriff auf den Cluster-API-Server.

Wenn Sie GKE-Cluster verwenden, stimmen Sie damit zu, bestimmte Aufgaben für Ihre Cluster zu übernehmen. Weitere Informationen finden Sie unter Gemeinsame Verantwortlichkeiten von GKE-Clustern.

AWS-KMS-Verschlüsselung

GKE on AWS verwendet vom Kunden verwaltete symmetrische Schlüssel (AWS Key Management Service (KMS) zum Verschlüsseln:

Für Produktionsumgebungen empfehlen wir die Verwendung unterschiedlicher Schlüssel für die Konfiguration und die Volume-Verschlüsselung. Um das Risiko weiter zu minimieren, wenn ein Schlüssel manipuliert ist, können Sie auch für jeden der folgenden Schlüssel unterschiedliche Schlüssel erstellen:

Für zusätzliche Sicherheit können Sie eine AWS-KMS-Schlüsselrichtlinie erstellen, die nur den minimal erforderlichen Satz von Berechtigungen zuweist. Weitere Informationen finden Sie unter KMS-Schlüssel mit bestimmten Berechtigungen erstellen.

Verschlüsselung inaktiver Daten

Die Verschlüsselung inaktiver Daten ist die Verschlüsselung gespeicherter Daten, im Gegensatz zu den Daten bei der Übertragung. Standardmäßig verschlüsselt GKE on AWS die Daten in etcd- und Speicher-Volumes im Ruhezustand mit von der AWS-Plattform verwalteten Schlüsseln.

GKE on AWS-Cluster speichern Daten in AWS EBS-Volumes (Elastic Block Storage). Diese EBS-Volumes werden immer mit inaktiven AWS-KMS-Schlüsseln (AWS Key Management System) verschlüsselt. Beim Erstellen von Clustern und Knotenpools können Sie einen vom Kunden verwalteten KMS-Schlüssel (Customer-Managed KMS Key, CMK) bereitstellen, um die zugrunde liegenden EBS-Volumes zu verschlüsseln. Wenn Sie keinen Schlüssel angeben, verwendet AWS den von AWS verwalteten Standardschlüssel in der AWS-Region, in der der Cluster ausgeführt wird.

Darüber hinaus ermöglichen alle GKE-Cluster die Verschlüsselung von Secrets auf Anwendungsebene für sensible Daten wie Kubernetes Secret-Objekte, die in etcd gespeichert werden. Selbst wenn Angreifer Zugriff auf das zugrunde liegende Volume erhalten, in dem etcd-Daten gespeichert sind, werden diese Daten verschlüsselt.

Wenn Sie einen Cluster erstellen, müssen Sie einen AWS KMS-Schlüssel an das Feld --database-encryption-kms-key-arn übergeben. Dieser Schlüssel wird für die Umschlagverschlüsselung von Anwendungsdaten verwendet. Da dieses Ressourcenfeld unveränderlich ist und nach der Erstellung des Clusters nicht mehr geändert werden kann, empfehlen wir die Verwendung eines KMS-Schlüsselalias. Mit einem Schlüsselalias können Sie die Schlüssel, die für die Verschlüsselung inaktiver Daten verwendet werden, während des gesamten Lebenszyklus des Clusters rotieren.

Verschlüsselung auf Anwendungsebene

Kubernetes bietet eine Verschlüsselung auf Anwendungsebene mit einer Technik, die als Umschlagverschlüsselung bezeichnet wird. Zum Verschlüsseln eines Secrets wird ein lokaler Schlüssel verwendet. Dieser wird im Allgemeinen als Data Encryption Key (DEK) bezeichnet. Der DEK selbst wird dann mit einem zweiten Schlüssel, dem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK), verschlüsselt. Der KEK wird nicht von Kubernetes gespeichert. Wenn Sie ein neues Kubernetes-Secret erstellen, führt der Cluster folgende Schritte aus:

  1. Der Kubernetes API-Server generiert mit einem Zufallszahlengenerator einen eindeutigen DEK für das Secret.

  2. Der Kubernetes API-Server verschlüsselt das Secret lokal mit dem DEK.

  3. Der Kubernetes API-Server sendet den DEK zur Verschlüsselung an AWS KMS.

  4. AWS KMS verwendet einen vorab generierten KEK, um den DEK zu verschlüsseln, und gibt den verschlüsselten DEK an das AWS KMS-Plug-in des Kubernetes API-Servers zurück.

  5. Der Kubernetes API-Server speichert das verschlüsselte Secret und den verschlüsselten DEK in etcd. Der Klartext-DEK wird nicht auf dem Laufwerk gespeichert.

  6. Der Kubernetes API-Server erstellt einen In-Memory-Cache-Eintrag, um den verschlüsselten DEK dem Klartext-DEK zuzuordnen. Dadurch kann der API-Server kürzlich aufgerufene Secrets entschlüsseln, ohne den AWS KMS abzufragen.

Wenn ein Client ein Secret vom Kubernetes API-Server anfordert, passiert Folgendes:

  1. Der Kubernetes API-Server ruft das verschlüsselte Secret und den verschlüsselten DEK aus etcd ab.

  2. Der Kubernetes API-Server prüft den Cache auf einen vorhandenen Zuordnungseintrag und, falls einer gefunden wird, entschlüsselt das Secret damit.

  3. Wenn kein übereinstimmender Cache-Eintrag vorhanden ist, sendet der API-Server den DEK an AWS KMS zur Entschlüsselung mithilfe des KEK. Der entschlüsselte DEK wird dann zur Entschlüsselung des Secrets verwendet.

  4. Der Kubernetes API-Server gibt das entschlüsselte Secret an den Client zurück.

Schlüsselrotation

Im Gegensatz zur Zertifikatsrotation ist die Schlüsselrotation der Vorgang, bei dem das zugrunde liegende kryptografische Material in einem Schlüsselverschlüsselungsschlüssel (Key Encryption Key, KEK) geändert wird. Sie kann automatisch im Rahmen einer geplanten Rotation oder manuell ausgelöst werden, normalerweise nach einem Sicherheitsvorfall, bei dem Schlüssel möglicherweise manipuliert wurden. Bei der Schlüsselrotation wird nur das einzelne Feld im Schlüssel ersetzt, das die Rohdaten zum Verschlüsselungs-/Entschlüsselungsschlüssel enthält.

KMS-Schlüsselrotation

AWS KMS unterstützt die automatische Rotation von KMS-Schlüsseln. Wenn diese Option aktiviert ist, generiert AWS einmal pro Jahr automatisch neues kryptografisches Schlüsselmaterial für Ihren Schlüssel. Es sind keine manuellen Maßnahmen erforderlich.

Weitere Informationen finden Sie unter Schlüsselrotation.

Cluster Trust

Bei der gesamten Clusterkommunikation wird Transport Layer Security (TLS) verwendet. Jeder Cluster wird mit den folgenden selbst signierten Stamm-CAs (Certificate Authorities, Zertifizierungsstelle) bereitgestellt:

  • Die Stammzertifizierungsstelle des Clusters wird zur Validierung von Anfragen verwendet, die an den API-Server gesendet werden.
  • Die etcd-Stamm-CA wird verwendet, um Anfragen zu validieren, die an etcd-Replikate gesendet werden.

Jeder Cluster hat eine eindeutige Stamm-CA. Wenn die Zertifizierungsstelle eines Clusters gehackt wurde, ist keine Zertifizierungsstelle eines anderen Clusters betroffen. Alle Stamm-CAs haben eine Gültigkeitsdauer von 30 Jahren.

Knotensicherheit

GKE on AWS stellt Ihre Arbeitslasten in Knotenpools von AWS EC2-Instanzen bereit. Im folgenden Abschnitt werden Sicherheitsfeatures von Knoten erläutert.

Ubuntu

Auf Ihren Knoten wird eine optimierte Version des Ubuntu ausgeführt, um die Kubernetes-Steuerungsebene und -Knoten auszuführen. Weitere Informationen finden Sie unter Sicherheitsfeatures in der Ubuntu-Dokumentation.

GKE-Cluster implementieren mehrere Sicherheitsfunktionen, darunter:

Für Ubuntu sind zusätzliche Sicherheitsleitfäden verfügbar, z. B.:

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 Sie die Nebenwirkungen der Ausführung von Containern in Clustern und Google Cloud Diensten begrenzen können.

Verarbeitungsrechte für Podcontainer einschränken

Für die Sicherheit des Clusters ist es wichtig, die Berechtigungen von containerisierten Prozessen einzuschränken. Sie können sicherheitsrelevante Optionen mit einem Sicherheitskontext festlegen. Sie haben dadurch die Möglichkeit, die Sicherheitseinstellungen etwa von folgenden Prozessen zu ändern:

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

Das standardmäßige GKE on AWS-Knotenbetriebssystem Ubuntu verwendet standardmäßige Docker AppArmor-Sicherheitsrichtlinien für alle Container. Sie können die Profilvorlage auf GitHub ansehen. Dieses Profil verweigert unter anderem Containern die folgenden Aktionen:

  • 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 außer /proc/sys/kernel/shm*
  • Bereitstellen von Dateisystemen

Möglichkeit einschränken, dass sich Arbeitslasten selbst ändern

Bestimmte Kubernetes-Arbeitslasten, insbesondere Systemarbeitslasten, haben die Berechtigung, sich selbst zu ändern. Beispielsweise werden einige Arbeitslasten automatisch vertikal skaliert. Dies ist zwar praktisch, kann einem Angreifer, der bereits einen Knoten manipuliert hat, aber auch die Möglichkeit bieten, im Cluster weiter zu eskalieren. Ein Angreifer kann beispielsweise dafür sorgen, dass sich eine Arbeitslast auf dem Knoten selbst ändert, um als ein privilegierteres Dienstkonto ausgeführt zu werden, das im selben Namespace vorhanden ist.

Idealerweise sollten Arbeitslasten nicht die Berechtigung erhalten, sich selbst zu ändern. Wenn eine Selbständerung erforderlich ist, können Sie die Berechtigungen einschränken, indem Sie Policy Controller oder Gatekeeper in Ihrem Cluster installieren. Wenden Sie Einschränkungen an, z. B. NoUpdateServiceAccount aus der Open-Source-Gatekeeper-Bibliothek, die mehrere nützliche Sicherheitsrichtlinien bietet.

Wenn Sie Richtlinien bereitstellen, müssen die Controller, die den Clusterlebenszyklus verwalten, normalerweise die Möglichkeit haben, die Richtlinien zu umgehen. Dies ist erforderlich, damit die Controller Änderungen am Cluster vornehmen können, indem sie z. B. Clusterupgrades anwenden. Wenn Sie beispielsweise die Richtlinie NoUpdateServiceAccount in GKE on AWS bereitstellen, müssen Sie die folgenden Parameter in der Constraint festlegen:

parameters:
  allowedGroups: []
  allowedUsers:
  - service-PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com

Ersetzen Sie PROJECT_NUMBER durch die Nummer (nicht die ID) des Projekts, in dem der Cluster gehostet wird.

Binärautorisierung verwenden

Eine weitere Möglichkeit zum Schützen Ihrer Arbeitslasten besteht darin, die Binärautorisierung zu aktivieren. Die Binärautorisierung ist eine Sicherheitsfunktion, die dafür sorgt, dass nur vertrauenswürdige Container-Images in GKE-Clustern bereitgestellt werden.

So funktioniert der Vorgang:

  1. Administratoren erstellen eine Richtlinie, in der die Anforderungen für die Bereitstellung eines Images definiert werden. Dazu gehören die Angabe der vertrauenswürdigen und autorisierten Entitäten (Attestatoren), die Bilder signieren können, und möglicherweise auch andere Kriterien, die ein Bild erfüllen muss, um als sicher für die Bereitstellung eingestuft zu werden.

  2. Ein Attester (z. B. ein Entwickler oder ein automatisiertes System) verwendet einen kryptografischen Algorithmus, um ein Schlüsselpaar (private und öffentliche Schlüssel) zu generieren.

  3. Der private Schlüssel, der geheim gehalten wird, wird verwendet, um eine digitale Signatur (d. h. eine eindeutige Zeichenfolge) für ein Bild zu generieren. Diese Signatur dient als Gütesiegel und ist ein Zeichen dafür, dass das Bild alle erforderlichen Prüfungen und Validierungen bestanden hat.

  4. Die digitale Signatur wird dann an das Bild angehängt. Mit anderen Worten: Die Signatur wird in den Metadaten des Bildes gespeichert, normalerweise in der Bildregistrierung.

  5. Der öffentliche Schlüssel wird dann beim Binärautorisierungssystem registriert, damit das System den öffentlichen Schlüssel zur Signaturprüfung verwenden kann.

  6. Wenn eine Bereitstellungsanfrage für einen Container gestellt wird, ruft das Binärautorisierungssystem die digitale Signatur ab, die dem Image in der Registry zugeordnet ist.

  7. Das Binärautorisierungssystem verwendet den registrierten öffentlichen Schlüssel, um die digitale Signatur zu überprüfen, die dem Image zugeordnet ist. Außerdem wird geprüft, ob das Bild alle anderen in der Richtlinie definierten Kriterien erfüllt. Wenn die digitale Signatur mit dem öffentlichen Schlüssel und den Imagedaten erfolgreich überprüft werden kann und das Image alle anderen in der Richtlinie definierten Kriterien erfüllt, ermöglicht das Binärautorisierungssystem die Bereitstellung des Containers. Wenn die digitale Signatur nicht mit dem öffentlichen Schlüssel und den Image-Daten verifiziert werden kann oder das Image nicht die anderen in der Richtlinie definierten Kriterien erfüllt, lehnt das Binärautorisierungssystem die Containerbereitstellung ab.

Weitere Informationen zur Funktionsweise der Binärautorisierung finden Sie unter Überblick über die Binärautorisierung.

Informationen zum Aktivieren der Binärautorisierung für einen vorhandenen Cluster oder beim Erstellen eines Clusters finden Sie unter Binärautorisierung aktivieren.

Arbeitslasten auf dedizierten Knotenpools isolieren

Sie können Kubernetes-Markierungen und ‑Toleranzen verwenden, um bestimmte Knotenpools für die Ausführung bestimmter Arten von Arbeitslasten zuzuweisen. Sie können beispielsweise angeben, dass Nutzerarbeitslasten von den meisten systemverwalteten Arbeitslasten getrennt geplant werden sollen, oder Arbeitslasten mit unterschiedlichen Vertrauensstufen in verschiedenen Knotenpools platzieren.

Die Arbeitslastisolierung mit Markierungen und Toleranzen ist keine garantierte Sicherheitsmaßnahme. Verwenden Sie diese Funktion nur in Kombination mit den anderen Härtungsmaßnahmen, die GKE on AWS bietet.

Weitere Informationen finden Sie unter Arbeitslasten in dedizierten Knotenpools isolieren.

Nächste Schritte