Diese Seite wurde von der Cloud Translation API übersetzt.

GKE Control Plane Authority

Autopilot Standard

Auf dieser Seite werden die Optionen beschrieben, die die Google Kubernetes Engine (GKE) bietet, um die Transparenz 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 Informationssicherheitsbeauftragte, Compliance-Administratoren und Analysten, die strenge Datenschutz- und Sicherheitsanforderungen beim Umgang mit sensiblen Daten erfüllen möchten.

GKE Control Plane Authority-Funktionen

In GKE wird die Google Cloud Sicherheitskonfiguration der Kontrollebene vollständig verwaltet, einschließlich der Verschlüsselung des ruhenden Speichers 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 zu den Funktionen von Google Cloud finden Sie unter Geteilte Verantwortung in GKE.

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

Sie sind in einer stark regulierten Branche wie Finanzen, Gesundheitswesen oder Behörden mit speziellen Compliance-Anforderungen tätig.
Sie verarbeiten vertrauliche Daten, für die strenge Sicherheits- und Verschlüsselungsanforderungen gelten.
Sie möchten mehr Transparenz in GKE, um bei der Ausführung kritischer Arbeitslasten sicherer zu sein.
Sie müssen bestimmte Compliance- oder Prüfanforderungen im Zusammenhang mit der Datenverschlüsselung, Softwareintegrität oder Protokollierung erfüllen.
Sie haben hochsensible Arbeitslasten, in denen kritische Daten verarbeitet werden, und möchten die Verschlüsselung und den Zugriff auf diese Daten im Blick behalten.
Sie möchten benutzerdefinierte Sicherheitsrichtlinien erzwingen, die bestimmten organisatorischen oder rechtlichen Anforderungen entsprechen.
Sie möchten mehr Transparenz und Einblick in Ihre GKE-Umgebungen, insbesondere in Bezug auf Aktionen, dieGoogle Cloud auf der Steuerungsebene ausführt.

Vorteile der GKE-Steuerungsebene

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

Mehr Transparenz und Kontrolle: Sie können zusätzliche Funktionen für Transparenz, Kontrolle und Verschlüsselung für Ihre GKE-Steuerungsebene verwenden.
Optimierte Compliance: Mit detaillierten Prüfprotokollen und anpassbaren Sicherheitsrichtlinien können Sie behördliche und branchenspezifische Anforderungen erfüllen.
Mehr Vertrauen und Transparenz: Sie erhalten Einblicke in die Aktionen, dieGoogle Cloud in der Kontrollebene bei der Lösung von Kundensupportanfragen ausführt.
Risikobewältigung: Mit umfassenden Protokollen potenzielle Bedrohungen für die verwaltete Steuerebene proaktiv erkennen und darauf reagieren.
Standardisierte Zertifizierungsstellen- und Schlüsselverwaltung: Sie können Ihre GKE-Cluster-Zertifizierungsstellen mit Certificate Authority Service verwalten. So können Sie die Zertifikatsverwaltung an bestimmte Teams delegieren und Zertifizierungsstellenrichtlinien umfassend erzwingen. Verwalten Sie außerdem die Laufwerkverschlüsselungsschlüssel der Kontrollebene mit Cloud KMS, um die Verwaltung zu delegieren.

Funktionsweise der GKE Control Plane Authority

Die Funktionen, die Sie mit der Steuerebene verwenden können, werden nach der gewünschten Art der Steuerung kategorisiert: Je nach Ihren Anforderungen können Sie eine oder mehrere dieser Funktionen verwenden.

Schlüssel- und Anmeldedatenverwaltung: Sie können die Schlüssel steuern, mit denen GKE ruhende Daten in der Steuerungsebene verschlüsselt und Identitäten im Cluster ausstellt und überprüft.
Zugriffsprotokolle und Protokolle zur Identitätsausstellung: Verwenden Sie Protokolle aus dem Netzwerk, der VM und Access Transparency, um den Zugriff auf die GKE-Steuerungsebene mithilfe mehrerer Quellen zu überprüfen. Anhand der Protokolle zur Identitätsausstellung in Cloud KMS und CA Service können Sie sehen, wann Identitäten mit von Ihnen verwalteten Schlüsseln und Zertifizierungsstellen erstellt werden. Verwenden Sie detaillierte Nutzungsprotokolle der Kubernetes API, 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 für Sie. Sie können optional Cloud KMS und den Zertifizierungsstellendienst verwenden, um eigene Schlüssel und Zertifizierungsstellen einzurichten, die Sie dann beim Erstellen eines neuen Clusters verwenden.

GKE verwendet diese Schlüssel und Zertifizierungsstellen anstelle der Google CloudStandards, um Identitäten in Ihrem Cluster auszustellen und zu überprüfen und Daten in Ihren Control Plane-VMs zu verschlüsseln. Wenn Sie die Kontrolle über die Ausweisausgabe und die Datenverschlüsselungsschlüssel behalten, haben Sie folgende Möglichkeiten:

Einhaltung von Bestimmungen zur Datenhoheit und zum Datenschutz, die eine ausschließliche Kontrolle über Schlüssel vorschreiben
Verschlüsselung kritischer sensibler Daten in Kubernetes steuern, indem Sie Ihre eigenen Verschlüsselungsschlüssel verwalten
Passen Sie Ihre Datenverschlüsselungsstrategie an die Richtlinien und Anforderungen Ihrer Organisation an, z. B. an die Anforderungen zur Verwendung hardwaregestützter Schlüssel.

Selbstverwaltete Zertifizierungsstellen 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 bestätigen. In GKE werden beispielsweise Zertifizierungsstellen und Schlüssel verwendet, um Kubernetes-Clientzertifikate und Kubernetes-Dienstkonto-Inhabertoken auszustellen.

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

Signaturschlüssel für Dienstkonten: Damit werden die Kubernetes-Inhabertokens für Dienstkonten im Cluster signiert. Diese Inhabertokens sind JSON Web Tokens (JWTs), die die Pod-Kommunikation mit dem Kubernetes API-Server erleichtern.
Bestätigungsschlüssel für Dienstkonten: Hiermit werden die JWTs des Kubernetes-Dienstkontos bestätigt. Dieser Schlüssel ist normalerweise mit dem Signaturschlüssel identisch, wird aber separat konfiguriert, damit Sie Ihre Schlüssel sicherer rotieren können.
Cluster-Zertifizierungsstelle: Stellt signierte Zertifikate für Zwecke wie Anfragen zur Zertifikatssignatur (Certificate Signing Requests, CSRs) und kubelet-Kommunikation aus.
etcd-Peer-CA: Stellt signierte Zertifikate für die Kommunikation zwischen etcd-Instanzen im Cluster aus.
etcd API-CA: Stellt signierte Zertifikate für die Kommunikation mit dem etcd API-Server aus.
Aggregations-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. Mit diesen können Sie die ausgestellten Identitäten während ihrer Lebensdauer im Blick behalten.

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

Verschlüsselung des Bootlaufwerks und von etcd auf der Steuerungsebene

Standardmäßig verschlüsselt GKE das Bootlaufwerk einer VM der Steuerungsebene, das Laufwerk, auf dem Daten in etcd gespeichert werden, und die Google Cloud interne Betriebssicherung von etcd mithilfe von Verschlüsselungsschlüsseln, die Google Cloudvon GKE verwaltet werden. Weitere Informationen zu dieser Standardverschlüsselung finden Sie unter Standardverschlüsselung ruhender Daten.

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

Bootlaufwerk der Steuerungsebene: Das Compute Engine-Laufwerk, das jede VM der Steuerungsebene zum Starten 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 Betriebssicherung von etcd: 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 Steuerungsebenen-Bootlaufwerke verschlüsseln.

Diese zusätzliche optionale Verschlüsselung ist ideal, wenn Sie bestimmte rechtliche oder Compliance-Anforderungen im Zusammenhang mit der Steuerung der Verschlüsselungsmethoden in Ihrer Cluster-Steuerungsebene erfüllen müssen. Sie können Ihre eigenen Schlüssel verwenden, um die Boot- und Speicherlaufwerke der Worker-Knoten in Ihrem Cluster separat zu verschlüsseln. Weitere Informationen finden Sie unter Vom Kunden verwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Wenn Sie die GKE Control Plane Authority zum Verschlüsseln der Bootlaufwerke der Steuerungsebene verwenden, verwenden GKE-VMs für die 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ätsausgabeprotokolle

In den Logs finden Sie Protokolle für alle Ereignisse im Zusammenhang mit Zugriff und Identität in der Steuerebene, einschließlich der folgenden:

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

Mit diesen Protokollen können Sie Folgendes tun:

Erstellen Sie umfassende Audit-Trails für alle Zugriffs- und Identitätsereignisse auf der Steuerungsebene, um die Compliance und Sicherheit zu gewährleisten.
Zusätzlich zu den integrierten Google-Schutzmaßnahmen können Sie eigene Monitoring-Systeme einrichten, um verdächtige Aktivitäten in der Kontrollebene zu erkennen und zu untersuchen.
Prüfen Sie, ob nur autorisierte Entitäten auf Ihren GKE-Cluster zugreifen und mit ihm interagieren. So lässt sich die Sicherheit verbessern.
Sie können mithilfe von Identitätsausstellungsprotokollen in Cloud KMS und CA Service nachsehen, wann Identitäten mit von Ihnen verwalteten Schlüsseln und Zertifizierungsstellen erstellt werden. Mit detaillierten Logs zur Nutzung der Kubernetes API können Sie nachvollziehen, was diese Identitäten im Cluster tun.

In den folgenden Dokumenten wird beschrieben, wie Sie die verschiedenen Arten von Steuerebenenprotokollen aufrufen und verarbeiten:

Weitere Ressourcen zur Sicherheit der Steuerungsebene

In diesem Abschnitt werden weitere Methoden beschrieben, mit denen Sie die Sicherheit der Steuerebene verbessern können. Für die folgenden Ressourcen ist keine GKE Control Plane Authority erforderlich:

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

Informationen zum Prüfen der VM-Integrität finden Sie unter Integrität der GKE-Steuerungsebene 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.