GKE Control Plane Authority

.

Auf dieser Seite werden die Optionen beschrieben, die Google Kubernetes Engine (GKE) bietet, um die Sichtbarkeit und Kontrolle über die Sicherheit der verwalteten Steuerungsebene zu verbessern. Diese Optionen werden zusammenfassend als GKE Control Plane Authority bezeichnet. Diese Seite richtet sich an Führungskräfte im Bereich Informationssicherheit, Compliance-Administratoren und Analysten, die strenge Datenschutz- und Sicherheitsanforderungen für den Umgang mit sensiblen Daten erfüllen möchten.

Funktionen der GKE Control Plane Authority

In GKE verwaltet Google Cloud die Sicherheitskonfiguration der Steuerungsebene vollständig, einschließlich der Verschlüsselung von Daten im Ruhezustand und der Konfiguration der Schlüssel und Zertifizierungsstellen (CAs), die Anmeldedaten in Ihren Clustern signieren und bestätigen. Die Knoten der Steuerungsebene für GKE-Cluster befinden sich in Projekten, die von Google Cloud verwaltet werden. Weitere Informationen dazu, was Google Cloud tut, finden Sie unter GKE-Modell der geteilten Verantwortung.

Die GKE Control Plane Authority ist eine optionale Reihe von Sichtbarkeits- und Steuerungsfunktionen, mit denen Sie bestimmte Aspekte dieser vollständig verwalteten Knoten der Steuerungsebene überprüfen und verwalten können. Diese Funktionen sind ideal, wenn Sie Anforderungen wie die folgenden haben:

  • Sie sind in einer stark regulierten Branche wie der Finanzbranche, dem Gesundheitswesen oder Behörden tätig und müssen bestimmte Compliance-Anforderungen erfüllen.
  • Sie verarbeiten vertrauliche Daten, für die strenge Sicherheits- und Verschlüsselungsanforderungen gelten.
  • Sie möchten eine bessere Sichtbarkeit von GKE, um das Vertrauen beim Ausführen kritischer Arbeitslasten zu stärken.
  • Sie müssen bestimmte Compliance- oder Prüfanforderungen in Bezug auf Datenverschlüsselung, Softwareintegrität oder Protokollierung erfüllen.
  • Sie haben hochsensible Arbeitslasten, die kritische Daten verarbeiten, und Sie möchten Einblick in die Verschlüsselung und den Zugriff auf diese Daten erhalten.
  • Sie möchten benutzerdefinierte Sicherheitsrichtlinien erzwingen, die bestimmte organisatorische oder behördliche Anforderungen erfüllen.
  • Sie möchten mehr Transparenz und Einblick in Ihre GKE-Umgebungen, insbesondere in Bezug auf Aktionen, dieGoogle Cloud in der Steuerungsebene ausführt.

Vorteile der GKE Control Plane Authority

Die Funktionen der GKE Control Plane Authority eignen sich ideal für stark regulierte Umgebungen mit strengen Sicherheitsrichtlinien oder strengen Prüfanforderungen. Die Nutzung dieser Funktionen bietet folgende Vorteile:

  • Mehr Transparenz und Kontrolle: Nutzen Sie zusätzliche Funktionen für Transparenz, Kontrolle und Verschlüsselung für Ihre GKE-Steuerungsebene.
  • Optimierte Compliance: Erfüllen Sie behördliche und branchenspezifische Anforderungen mit detaillierten Audit-Logs und anpassbaren Sicherheitsrichtlinien.
  • Mehr Vertrauen und Transparenz: Sie erhalten Einblick in die Aktionen, dieGoogle Cloud in der Steuerungsebene ausführt, um Kundensupportanfragen zu bearbeiten.
  • Risikominderung: Mit umfassenden Logs potenzielle Bedrohungen der verwalteten Steuerungsebene proaktiv erkennen und darauf reagieren.
  • Standardisierte CA- und Schlüsselverwaltung: Sie können Ihre GKE-Cluster-CAs mit Certificate Authority Service verwalten und die Zertifikatsverwaltung an bestimmte Teams delegieren. Außerdem können Sie CA-Richtlinien umfassend erzwingen. Außerdem können Sie die Verschlüsselungsschlüssel für die Steuerungsebene mit Cloud KMS verwalten, um eine ähnliche Verwaltungsdelegierung zu erreichen.

Verfügbarkeit der GKE Control Plane Authority

Die Regionen und Zonen, in denen Sie die GKE Control Plane Authority verwenden können, hängen davon ab, ob Sie auch bestimmte Funktionen verwenden möchten:

  • Wenn Sie die Bootlaufwerke der Steuerungsebene mit einem vom Kunden verwalteten Verschlüsselungsschlüssel verschlüsseln möchten, muss sich Ihr Cluster in einer der folgenden Regionen befinden:
    • asia-east1
    • asia-northeast1
    • asia-southeast1
    • europe-west1
    • europe-west4
    • us-central1
    • us-east1
    • us-east4
    • us-east5
    • us-south1
    • us-west1
    • us-west3
    • us-west4
  • Wenn Sie Confidential GKE Nodes mit der GKE-Steuerungsebene verwenden möchten, muss sich Ihr Cluster in einer Region befinden, die den vertraulichen Modus für Hyperdisk Balanced unterstützt.

Wenn Sie diese Funktionen nicht verwenden, können Sie die GKE Control Plane Authority an einem beliebigen Google Cloud -Standort verwenden.

Funktionsweise der GKE Control Plane Authority

Die Funktionen, die Sie mit der Steuerungsebene verwenden können, sind nach der Art der gewünschten Steuerung kategorisiert. Je nach Ihren spezifischen Anforderungen können Sie eine oder mehrere dieser Funktionen nutzen.

  • Schlüssel- und Anmeldedatenverwaltung: Sie können die Schlüssel steuern, die GKE zum Verschlüsseln inaktiver Daten in der Steuerungsebene und zum Ausstellen und Überprüfen von Identitäten im Cluster verwendet.
  • Zugriffs- und Identitätsausstellungslogs: Verwenden Sie Logs aus dem Netzwerk, der VM und Access Transparency, um den Zugriff auf die GKE-Steuerungsebene anhand mehrerer Quellen zu überprüfen. Mit den Protokollen zur Identitätsausstellung in Cloud KMS und CA Service können Sie sehen, wann Identitäten mit Schlüsseln und Zertifizierungsstellen erstellt werden, die Sie verwalten. Verwenden Sie detaillierte Kubernetes API-Nutzungslogs, um zu verfolgen, was diese Identitäten im Cluster tun.

Schlüssel- und Anmeldedatenverwaltung

Standardmäßig verwaltet Google Cloud die Schlüssel und Zertifizierungsstellen in Ihren GKE-Clustern. Optional können Sie Cloud KMS und den CA-Dienst verwenden, um Ihre eigenen Schlüssel und Zertifizierungsstellen einzurichten, die Sie dann beim Erstellen eines neuen Clusters verwenden.

GKE verwendet diese Schlüssel und CAs anstelle der Google CloudStandardeinstellungen, um Identitäten in Ihrem Cluster auszustellen und zu bestätigen und Daten in Ihren Steuerungsebene-VMs zu verschlüsseln. Wenn Sie die Kontrolle über die Ausstellung Ihrer Identität und die Datenverschlüsselungsschlüssel behalten, können Sie Folgendes tun:

  • Einhaltung von Vorschriften zu Datenhoheit und Datenschutz, die eine ausschließliche Kontrolle über Schlüssel vorschreiben
  • Verschlüsselung kritischer sensibler Daten in Kubernetes durch Verwalten eigener Verschlüsselungsschlüssel steuern
  • Passen Sie Ihre Datenverschlüsselungsstrategie an die Richtlinien und Anforderungen Ihrer Organisation an, z. B. an die Anforderung, hardwaregestützte Schlüssel zu verwenden.

Selbstverwaltete CAs und Dienstkontoschlüssel

Sie können die GKE-Steuerungsebene so konfigurieren, dass von Ihnen verwaltete Cloud KMS-Schlüssel und CA Service-Zertifizierungsstellen verwendet werden. GKE verwendet diese Ressourcen, um Identitäten in Ihrem Cluster auszustellen und zu überprüfen. GKE verwendet beispielsweise CAs und Schlüssel, um Kubernetes-Clientzertifikate und Kubernetes-Dienstkonto-Inhabertokens auszustellen.

Sie erstellen die folgenden Ressourcen, die von GKE beim Ausstellen von Identitäten verwendet werden:

  1. Signierschlüssel für Dienstkonten: Signieren Sie die Inhabertokens für Kubernetes-Dienstkonten für Dienstkonten im Cluster. Diese Inhabertokens sind JSON Web Tokens (JWTs), die die Pod-Kommunikation mit dem Kubernetes API-Server ermöglichen.
  2. Bestätigungsschlüssel für Dienstkonten: Bestätigen Sie die JWTs des Kubernetes-Dienstkontos. Dieser Schlüssel ist normalerweise derselbe wie der Signaturschlüssel, wird aber separat konfiguriert, damit Sie Ihre Schlüssel sicherer rotieren können.
  3. Cluster-CA: Stellt signierte Zertifikate für Zwecke wie Zertifikatsignierungsanfragen (Certificate Signing Requests, CSRs) und die Kubelet-Kommunikation aus.
  4. etcd-Peer-CA: stellt signierte Zertifikate für die Kommunikation zwischen etcd-Instanzen im Cluster aus.
  5. etcd API CA: Stellt signierte Zertifikate für die Kommunikation mit dem etcd API-Server aus.
  6. Aggregation CA: stellt signierte Zertifikate aus, um die Kommunikation zwischen dem Kubernetes API-Server und Erweiterungsservern zu ermöglichen.

Wenn GKE Identitäten im Cluster ausstellt, werden die entsprechenden Audit-Logs in Cloud Logging angezeigt. Sie können damit ausgestellte Identitäten während ihres gesamten Lebenszyklus verfolgen.

Weitere Informationen finden Sie unter Eigene Zertifizierungsstellen und Signaturschlüssel in GKE ausführen.

Bootlaufwerk und etcd-Verschlüsselung der Steuerungsebene

Standardmäßig verschlüsselt GKE das Bootlaufwerk einer VM der Steuerungsebene. Wenn auf der Steuerungsebene etcd-Datenbankinstanzen ausgeführt werden, verschlüsselt GKE auch Folgendes:

  • Das Laufwerk, auf dem etcd-Daten gespeichert werden.
  • Die Google Cloud interne operative Sicherung von etcd.

Bei dieser Standardverschlüsselung werden Verschlüsselungsschlüssel verwendet, die von Google Cloud verwaltet werden. Weitere Informationen zu dieser Standardverschlüsselung finden Sie unter Standardverschlüsselung ruhender Daten.

Sie können optional Ihre eigenen Verschlüsselungsschlüssel verwenden, die Sie mit Cloud KMS verwalten, um die folgenden Ressourcen zu verschlüsseln:

  • Bootlaufwerk der Steuerungsebene: Das Compute Engine-Laufwerk, das jede VM der Steuerungsebene zum Booten verwendet.
  • etcd-Laufwerk: Das Compute Engine-Laufwerk, das an jede VM der Steuerungsebene angehängt ist und Daten für etcd-Instanzen im Cluster speichert.

  • Interne etcd-Sicherung für den Betrieb: Die interne Google Cloud Sicherung von etcd, die für betriebliche Zwecke wie die Notfallwiederherstellung verwendet wird.

    Diese Sicherung ist eine interne Notfallmaßnahme von Google Cloud. Wenn Sie Ihre Cluster sichern und wiederherstellen möchten, verwenden Sie stattdessen Backup for GKE.

Eine Anleitung finden Sie unter etcd- und Bootlaufwerke der Steuerungsebene verschlüsseln.

Diese zusätzliche optionale Verschlüsselung ist ideal, wenn Sie bestimmte gesetzliche oder Compliance-Anforderungen erfüllen müssen, die sich auf die Kontrolle der Verschlüsselungsmittel in der Steuerungsebene Ihres Clusters beziehen. Sie können Ihre eigenen Schlüssel separat verwenden, um die Bootlaufwerke und Speicherlaufwerke von Worker-Knoten in Ihrem Cluster zu verschlüsseln. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Wenn Sie die GKE Control Plane Authority verwenden, um die Bootlaufwerke Ihrer Steuerungsebene zu verschlüsseln, verwenden die VMs der GKE-Steuerungsebene automatisch den Modus „Vertraulich“ für Hyperdisk Balanced auf den Bootlaufwerken. Durch diese Konfiguration werden die Standard-Boot-Laufwerke Ihrer Worker-Knoten nicht geändert.

Zugriffs- und Identitätsausstellungslogs

Sie können Logs für alle Ereignisse im Zusammenhang mit Zugriff und Identität in der Steuerungsebene in Logging ansehen, einschließlich der folgenden Ereignisse:

  • Direkter Zugriff: Mit Logs zu Versuchen, direkt auf GKE-Steuerungsebenenknoten zuzugreifen (z. B. über SSH), können Sie prüfen, ob die VM-SSH-Logs und VM-Netzwerkverbindungen mit den SSH-Einträgen in den Access Transparency-Logs übereinstimmen.
  • Ausstellung und Bestätigung von Identitäten: Logs zu Identitäten, die mit Zertifizierungsstellen und Schlüsseln ausgestellt wurden, die Sie in CA Service und Cloud KMS verwalten.
  • Identitätsnutzung in Kubernetes: Logs zu den Aktionen, die bestimmte Identitäten für den Kubernetes API-Server ausführen.
  • Access Transparency: Protokolle zu Verbindungen zur Steuerungsebene und Aktionen, die von Google Cloud -Mitarbeitern auf der Steuerungsebene ausgeführt wurden.

Diese Logs können Ihnen bei Folgendem helfen:

  • Umfassende Audit-Trails für den gesamten Zugriff auf die Steuerungsebene und alle Identitätsereignisse für Compliance und Sicherheit aufrechterhalten.
  • Zusätzlich zum integrierten Google-Schutz können Sie eigene Überwachungsfunktionen erstellen, um verdächtige Aktivitäten in der Steuerungsebene zu erkennen und zu untersuchen.
  • Prüfen Sie, ob nur autorisierte Entitäten auf Ihren GKE-Cluster zugreifen und mit ihm interagieren. So verbessern Sie Ihren Sicherheitsstatus.
  • Anhand von Protokollen zur Identitätsausstellung in Cloud KMS und CA Service können Sie sehen, wann Identitäten mit Schlüsseln und Zertifizierungsstellen erstellt werden, die Sie verwalten. Verwenden Sie detaillierte Kubernetes API-Nutzungslogs, um zu verfolgen, was diese Identitäten im Cluster tun.

In den folgenden Dokumenten erfahren Sie, wie Sie die verschiedenen Arten von Logs der Steuerungsebene ansehen und verarbeiten:

Zusätzliche Ressourcen zur Sicherheit der Steuerungsebene

In diesem Abschnitt werden weitere Methoden beschrieben, mit denen Sie die Sicherheit Ihrer Steuerungsebene verbessern können. Sie müssen die GKE Control Plane Authority nicht verwenden, um auf die folgenden Ressourcen zuzugreifen:

  • Integrität von VM-Images der Steuerungsebene: GKE fügt Cloud Logging detaillierte Logs für die Erstellung von Knoten-VMs und Boot-Ereignisse hinzu. Außerdem veröffentlichen wir auf GitHub SLSA-VSAs, die den Maschinen-Images für die Steuerungsebene und die Worker-Knoten entsprechen. Sie können prüfen, ob Ihre VMs Betriebssystem-Images verwenden, die entsprechende VSAs haben, und die Integrität beim Booten jeder Steuerungsebene-VM prüfen.

    Informationen zum Prüfen der VM-Integrität finden Sie unter Integrität der GKE-Steuerungsebene-VMs prüfen.

  • Integrierte Sicherheitsmaßnahmen für die Steuerungsebene: GKE führt verschiedene Härtungsmaßnahmen für die verwaltete Steuerungsebene durch. Weitere Informationen finden Sie unter Sicherheit der Steuerungsebene.

Nächste Schritte