Einige oder alle Informationen auf dieser Seite gelten möglicherweise nicht für Cloud de Confiance von S3NS. Weitere Informationen finden Sie unter Unterschiede zu Google Cloud.

Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

Informationen zur GKE Control Plane Authority

Autopilot Standard

In diesem Dokument werden die Optionen beschrieben, die Google Kubernetes Engine (GKE) bietet, um die Transparenz und Kontrolle über die Sicherheit der verwalteten Steuerungsebene zu verbessern. Diese Optionen werden zusammen als GKE Control Plane Authority bezeichnet. Dieses Dokument 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üssen.

Informationen zu den Features von GKE Control Plane Authority

In GKE, Cloud de Confiance by S3NS verwaltet die Sicherheitskonfiguration von der Steuerungsebene vollständig, einschließlich der Verschlüsselung von inaktiven Daten, und der Konfiguration der Schlüssel und Zertifizierungsstellen (CAs), die Anmeldedaten in Ihren Clustern signieren und überprüfen. Die Knoten der Steuerungsebene für GKE-Cluster befinden sich in Projekten, die Cloud de Confiance vonverwaltet werden. Weitere Informationen zu den Aufgaben von Cloud de Confiance finden Sie unter Gemeinsame Verantwortung in GKE.

GKE Control Plane Authority ist eine optionale Reihe von Funktionen für Transparenz und Kontrolle, 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 dem Finanzwesen, dem Gesundheitswesen oder der öffentlichen Verwaltung mit spezifischen Compliance-Anforderungen tätig.
Sie verarbeiten sensible Daten, für die strenge Sicherheits- und Verschlüsselungsanforderungen gelten.
Sie möchten mehr Transparenz in GKE, um das Vertrauen bei der Ausführung kritischer Arbeitslasten zu stärken.
Sie müssen bestimmte Compliance- oder Audit-Anforderungen in Bezug auf Datenverschlüsselung, Softwareintegrität oder Logging 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 haben.
Sie möchten benutzerdefinierte Sicherheitsrichtlinien erzwingen, die bestimmte Anforderungen von Organisationen oder Vorschriften erfüllen.
Sie möchten mehr Transparenz und Einblick in Ihre GKE-Umgebungen, insbesondere in Bezug auf Aktionen, die Cloud de Confiance in der Steuerungsebene ausführt.

Vorteile von GKE Control Plane Authority

Die Funktionen von GKE Control Plane Authority sind ideal für stark regulierte Umgebungen mit strengen Sicherheitsrichtlinien oder strengen Audit-Anforderungen. Die Verwendung dieser Funktionen bietet Vorteile wie die folgenden:

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 gesetzliche und branchenspezifische Anforderungen mit detaillierten Audit-Logs und anpassbaren Sicherheitsrichtlinien.
Mehr Vertrauen und Transparenz: Erhalten Sie Einblicke in die Aktionen, die Cloud de Confiance in der Steuerungsebene ausführt, wenn Kundensupportfälle gelöst werden.
Risikominimierung: Erkennen Sie potenzielle Bedrohungen für die verwaltete Steuerungsebene proaktiv und reagieren Sie darauf.
Standardisierte CA- und Schlüsselverwaltung: Verwalten Sie Ihre GKE-Cluster-CAs mit Certificate Authority Service. So können Sie die Zertifikatsverwaltung an bestimmte Teams delegieren und CA-Richtlinien umfassend erzwingen. Verwalten Sie außerdem die Verschlüsselungsschlüssel für das Laufwerk der Steuerungsebene mit Cloud KMS, um die Verwaltung auf ähnliche Weise zu delegieren.

Verfügbarkeit von GKE Control Plane Authority

GKE Control Plane Authority ist in allen Cloud de Confiance Regionen verfügbar. Wenn Sie jedoch die Bootlaufwerke und etcd-Laufwerke Ihrer Steuerungsebene mit Ihren eigenen Schlüsseln verschlüsseln möchten, müssen Sie den Cluster in einer der folgenden Regionen erstellen:

asia-east1
asia-northeast1
asia-southeast1
europe-west1
europe-west4
us-central1
us-central2
us-east1
us-east4
us-east5
us-south1
us-west1
us-west3
us-west4

Funktionsweise von GKE Control Plane Authority

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

Schlüssel- und Anmeldedatenverwaltung: Steuern Sie die Schlüssel, die GKE verwendet, um inaktive Daten in der Steuerungsebene zu verschlüsseln und Identitäten im Cluster auszustellen und zu überprüfen.
Zugriffs- und Identitätsausstellungsprotokolle: Verwenden Sie Protokolle aus dem Netzwerk, der VM, und Access Transparency, um den Zugriff auf die GKE-Steuerungsebene anhand mehrerer Quellen zu überprüfen. Verwenden Sie Protokolle zur Identitätsausstellung in Cloud KMS und CA Service, um zu sehen, wann Identitäten mit Schlüsseln und CAs erstellt werden, die Sie verwalten. Verwenden Sie detaillierte Protokolle zur Kubernetes API-Nutzung, um zu verfolgen, was diese Identitäten im Cluster tun.

Schlüssel- und Anmeldedatenverwaltung

Standardmäßig Cloud de Confiance verwaltet die Schlüssel und CAs in Ihren GKE-Clustern für Sie. Optional können Sie Cloud KMS und CA Service verwenden, um eigene Schlüssel und CAs einzurichten, die Sie dann beim Erstellen eines neuen Clusters verwenden.

GKE verwendet diese Schlüssel und CAs anstelle der Cloud de Confiance Standardeinstellungen, um Identitäten in Ihrem Cluster auszustellen und zu überprüfen und Daten in Ihren VMs der Steuerungsebene zu verschlüsseln. Wenn Sie die Kontrolle über Ihre Schlüssel zur Identitätsausstellung und Datenverschlüsselung behalten, können Sie Folgendes tun:

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

Selbstverwaltete CAs und Dienstkontoschlüssel

Sie können die GKE-Steuerungsebene so konfigurieren, dass sie Cloud KMS-Schlüssel und CA Service-CAs verwendet, die Sie verwalten. 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-Inhabertokensauszustellen.

Sie erstellen die folgenden Ressourcen, die GKE bei der Ausstellung von Identitäten verwenden soll:

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 erleichtern.
Bestätigungsschlüssel für Dienstkonten: Überprüfen Sie die Kubernetes-Dienstkonto- JWTs. Dieser Schlüssel ist normalerweise derselbe wie der Signierschlüssel, wird aber separat konfiguriert, damit Sie Ihre Schlüssel sicherer rotieren können.
Cluster-CA: Stellen Sie signierte Zertifikate für Zwecke wie Anfragen zur Zertifikatssignierung (Certificate Signing Requests, CSRs) und die kubelet-Kommunikation aus.
etcd-Peer-CA: Stellen Sie signierte Zertifikate für die Kommunikation zwischen etcd-Instanzen im Cluster aus.
etcd-API-CA: Stellen Sie signierte Zertifikate für die Kommunikation mit dem etcd API-Server aus.
Aggregations-CA: Stellen Sie 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 Logs können Sie ausgestellte Identitäten während ihres gesamten Lebenszyklus verfolgen.

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

Verschlüsselung von Bootlaufwerk und etcd 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 sind.
Die Cloud de Confiance by S3NS interne betriebliche Sicherung von etcd.

Bei dieser Standardverschlüsselung werden Verschlüsselungsschlüssel verwendet, die Cloud de Confiance vonverwaltet werden. Weitere Informationen zu dieser Standardverschlüsselung finden Sie unter Verschlü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 betriebliche Sicherung von etcd: Die interne Cloud de Confiance Sicherung von etcd, die für betriebliche Zwecke wie die Notfallwiederherstellung verwendet wird.

Diese Sicherung ist eine Notfallmaßnahme, die intern von Cloud de Confianceausgeführt wird. Wenn Sie Ihre Cluster sichern und wiederherstellen möchten, verwenden Sie Backup for GKE stattdessen.

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 in Bezug auf die Steuerung der Verschlüsselungsmittel in Ihrer Steuerungsebene des Clusters erfüllen müssen. 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 Kundenverwaltete Verschlüsselungsschlüssel (CMEK) verwenden.

Wenn Sie 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. Diese Konfiguration ändert nichts an den Standard-Bootlaufwerken Ihrer Worker-Knoten.

Rotation von vom Kunden verwalteten Anmeldedaten

Mit GKE Control Plane Authority können Sie Cluster so konfigurieren, dass sie vom Kunden verwaltete CAs und Schlüssel anstelle der von Google verwalteten Ressourcen verwenden, die GKE standardmäßig verwendet. Eine Rotation von Anmeldedaten ist ein Vorgang, den Sie ausführen, um eine oder mehrere dieser Ressourcen in einem Cluster zu aktualisieren. Sie können eine Anmeldedatenrotation ausführen, um beispielsweise den Ablauf der CA zu vermeiden oder die Anforderungen Ihrer Organisation an die Anmeldedatenverwaltung zu erfüllen.

Um eine Rotation von Anmeldedaten für einen Cluster durchzuführen, der GKE Control Plane Authority verwendet, erstellen Sie neue CAs, Signierschlüssel und Verschlüsselungsschlüssel. Anschließend aktualisieren Sie Ihren Cluster, um diese neuen Ressourcen zu verwenden.

Weitere Informationen finden Sie auf den folgenden Seiten:

Zugriffs- und Identitätsausstellungsprotokolle

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

Direkter Zugriff: Mit Logs zu direkten Zugriffsversuchen (z. B. SSH) auf Knoten der GKE-Steuerungsebene können Sie überprüfen, ob die VM-SSH- Logs und VM-Netzwerkverbindungen mit den SSH-Einträgen in den Access Transparency- Logs übereinstimmen.
Ausstellung und Überprüfung von Identitäten: Logs zu Identitäten, die mit CAs 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 auf dem Kubernetes API-Server ausführen.
Access Transparency: Logs zu Verbindungen zur Steuerungsebene und Aktionen, die von Cloud de Confiance Mitarbeitern auf der Steuerungsebene ausgeführt werden. Wenn die erweiterte Zugriffsgenehmigung aktiviert ist, erhalten Sie eine höhere Granularität für die Zugriffssteuerung, einschließlich Details zu SSH-Befehlen in Access Transparency-Logs und für Genehmigungsanfragen. Weitere Informationen zu Berechtigung und Registrierung erhalten Sie von Ihrem Cloud de Confiance by S3NS Account-Management-Team.

Diese Logs können Ihnen helfen, Folgendes zu tun:

Umfassende Audit-Trails aller Zugriffs- und Identitätsereignisse der Steuerungsebene für Compliance und Sicherheit führen.
Zusätzlich zu den integrierten Google-Schutzmaßnahmen können Sie Ihr eigenes Monitoring erstellen, um verdächtige Aktivitäten in der Steuerungsebene zu erkennen und zu untersuchen.
Überprüfen, ob nur autorisierte Entitäten auf Ihren GKE-Cluster zugreifen und mit ihm interagieren, wodurch Ihr Sicherheitsstatus verbessert wird.
Anhand von Protokollen zur Identitätsausstellung in Cloud KMS und CA Service sehen, wann Identitäten mit Schlüsseln und CAs erstellt werden, die Sie verwalten. Verwenden Sie detaillierte Protokolle zur Kubernetes API-Nutzung, um zu verfolgen, was diese Identitäten im Cluster tun.

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

Zusätzliche Ressourcen zur Sicherheit der Steuerungsebene

In diesem Abschnitt werden weitere Methoden beschrieben, mit denen Sie das Vertrauen in die Sicherheit Ihrer Steuerungsebene stärken können. Sie müssen GKE Control Plane Authority nicht verwenden, um die folgenden Ressourcen zu nutzen:

Integrität des VM-Images der Steuerungsebene: GKE fügt Cloud Logging detaillierte Logs für die Erstellung von Knoten-VMs und Bootereignisse 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 Ausführen der VM-Integritätsprüfung finden Sie unter Integrität der VM der GKE-Steuerungsebene überprüfen.
Integrierte Sicherheitsmaßnahmen der Steuerungsebene: GKE führt verschiedene Härtungsmaßnahmen auf der verwalteten Steuerungsebene durch. Weitere Informationen finden Sie unter Sicherheit der Steuerungsebene.