In diesem Dokument werden die in Connect integrierten Sicherheitsmaßnahmen erläutert.
Eine effektive Multi-Cloud-Hybridplattform bietet zentrale Verwaltung, Sichtbarkeit und Zugriff auf Dienste in allen Umgebungen. GKE Enterprise bietet eine einheitliche und umfassende Oberfläche für diese Funktionen, unabhängig davon, welchen Kubernetes-Anbieter Sie nutzen. Connect ist ein einfacher Agent, der die folgenden Vorteile für Skaleneffekte und bei allen Anbietern bietet:
- Multi-Cluster-Verwaltung und Cluster-Sichtbarkeit
- Deployment von Anwendungsdiensten und Lebenszyklusverwaltung
In diesem Dokument wird Folgendes behandelt:
- So stellt das Design von Connect Sicherheit an erster Stelle
- Best Practices für das Deployment des Connect-Agents
- So verbessern Sie den Sicherheitsstatus des Kubernetes-Deployments
Architektur von Connect
Mit Connect können Endnutzer und Google Cloud-Dienste auf Kubernetes API-Server zugreifen, die nicht über das öffentliche Internet verfügbar sind. Der Connect-Agent wird im Kubernetes-Cluster ausgeführt (ein Agent pro Cluster) und stellt eine Verbindung zu einem Connect-Proxy her. Google Cloud-Dienste, die mit dem Kubernetes-Cluster interagieren müssen, stellen eine Verbindung zum Proxy her, der Anfragen an den Agent weiterleitet. Der Agent wiederum leitet sie an den Kubernetes API-Server weiter. Dies wird im folgenden Diagramm dargestellt:
Wenn der Agent bereitgestellt wird, wird eine dauerhafte TLS 1.2+-Verbindung zu Google Cloud hergestellt, um auf Anfragen zu warten. Google Cloud-Dienste können, sofern von Administratoren aktiviert, Anfragen für die Kubernetes-Cluster erstellen. Diese Anfragen können auch von einer direkten Nutzerinteraktion mit der Google Cloud Console, Connect Gateway oder anderen Google-Diensten stammen.
Der Google Cloud-Dienst sendet die Anfrage an den Proxy. Der Proxy leitet die Anfrage dann an den bereitgestellten Agent weiter, der für einen Cluster zuständig ist. Der Agent leitet die Anfrage schließlich an den Kubernetes API-Server weiter. Der Kubernetes API-Server wendet Kubernetes-Richtlinien für Authentifizierung, Autorisierung und Audit-Logging an und gibt eine Antwort zurück. Die Antwort wird über den Agent und den Proxy an den Google Cloud-Dienst zurückgegeben. Bei jedem Schritt führen die Komponenten eine Authentifizierung und Autorisierung pro Verbindung und pro Anfrage durch.
Der Kubernetes API-Server wendet dieselben Richtlinien für Authentifizierung, Autorisierung und Audit-Logging auf alle Anfragen an, einschließlich Anfragen über Connect. Dadurch haben Sie immer die Kontrolle über den Zugriff auf Ihren Cluster.
Connect und gestaffelte Sicherheitsebenen
Gestaffelte Sicherheitsebenen sind in alle Aktionen von Google Cloud im Rahmen seiner Infrastruktur- und Sicherheitspraktiken integriert. Wir verfolgen einen mehrschichtigen Ansatz, um unsere Organisation und unsere Kunden, insbesondere wertvolle Daten, Informationen und Nutzer zu schützen. Nach diesem Prinzip haben wir Connect entwickelt.
Zusätzlich zu der Strategie und dem Design von Google für gestaffelte Sicherheitsebenen sollten Sie neben Ihrem Sicherheitsstatus und Ihren Standards den hier bereitgestellten Inhalt berücksichtigen. In diesem Abschnitt werden zusätzliche Maßnahmen aufgeführt, die Sie zusätzlich zu den Best Practices zur Erhöhung der Sicherheit von Kubernetes ergreifen können
Sicherheit von Komponente zu Komponente
Jede Komponente einer Connect-Anfrage authentifiziert ihre Peers und gibt nur Daten für Peers frei, die für diese Daten authentifiziert und autorisiert sind, wie im folgenden Diagramm dargestellt.
Jede Komponente einer Connect-Anfrage verwendet Folgendes, um sich gegenseitig zu authentifizieren:
- Transport Layer Security (TLS)
- Application Layer Transport Security (ALTS)
- OAuth
Jede Komponente einer Connect-Anfrage verwendet Folgendes, um sich gegenseitig zu autorisieren:
- Identitäts- und Zugriffsverwaltung
- Zulassungslisten
Jede Verbindung zwischen dem Kubernetes-Cluster und Google Cloud ist verschlüsselt und mindestens ein Peer jeder Verbindung verwendet eine zertifikatbasierte Authentifizierung. Dadurch wird sichergestellt, dass alle Token-Anmeldedaten bei der Übertragung verschlüsselt und nur von authentifizierten und autorisierten Peers empfangen werden.
Nutzerauthentifizierung für Google Cloud
In der Google Cloud Console folgen Nutzer dem Standardablauf der Google-Anmeldung. Google Cloud stellt ein TLS-Zertifikat bereit, das vom Browser des Nutzers authentifiziert wird. Der Nutzer meldet sich in einem Google Cloud- oder Google Workspace-Konto an, um sich bei Google Cloud zu authentifizieren.
Der Zugriff auf ein Projekt über die Google Cloud Console oder andere APIs wird durch IAM-Berechtigungen gesteuert.
Google Cloud-Dienst-zu-Dienst-Authentifizierung
Google Cloud verwendet ALTS für die interne Dienst-zu-Dienst-Authentifizierung. Mit ALTS können Google Cloud-Diensten wie der Proxy eine authentifizierte, integritätsgeschützte Verbindung herstellen.
Google Cloud-Dienste müssen intern autorisiert sein, um mit dem Proxy eine Verbindung mit einer Remote-Connect-Instanz herzustellen, da der Proxy eine Zugriffsliste mit Dienstidentitäten zur Beschränkung des Zugriffs verwendet.
Google Cloud authentifizieren
Der Agent authentifiziert und verschlüsselt jede Verbindung mit TLS. Der Agent authentifiziert Google Cloud TLS-Zertifikate mithilfe einer Reihe von in das Binärprogramm integrierten Root-Zertifikaten, um zu verhindern, dass versehentlich dem Container des Agents hinzugefügte Zertifikate als vertrauenswürdig eingestuft werden. Der Agent führt API-Aufrufe nur bei ordnungsgemäß authentifizierten Endpunkten aus. Dadurch wird sichergestellt, dass Dienstkontozertifikate und die Kubernetes API-Anfragen von Google Cloud gesendet werden und dass alle Antworten nur an Google Cloud gesendet werden.
Die Liste der Domains, mit denen der Agent während des normalen Betriebs kommuniziert, finden Sie unter Netzwerkverbindung gewährleisten.
Sie können den Agent für die Verbindung mit Google Cloud über einen HTTP-Proxy konfigurieren. In dieser Konfiguration verwendet der Agent HTTP/1.1
CONNECT für den HTTP-Proxy und stellt eine TLS-Verbindung zu Google Cloud her. Der HTTP-Proxy sieht nur den verschlüsselten Traffic zwischen dem Agent und Google Cloud. Die End-to-End-Integrität und die Sicherheit der Verbindung zwischen dem Agent und Google Cloud sind davon nicht betroffen.
Agent authentifizieren
Der Agent authentifiziert sich bei Google Cloud mit einem von Ihnen erstellten Google Cloud-Dienstkonto. Wenn der Clusteradministrator den Agent bereitstellt, stellt er einen privaten Schlüssel für dieses Dienstkonto bereit und übernimmt die Verantwortung für den Datenschutz des Schlüssels. Wenn der Agent eine Verbindung zu Google Cloud herstellt, authentifiziert er sich bei diesem Dienstkonto und fordert Anfragen für das konfigurierte Projekt an.
Google Cloud authentifiziert die Anmeldedaten des Dienstkontos und prüft außerdem, ob das Google Cloud-Dienstkonto die IAM-Berechtigung gkehub.endpoints.connect im Projekt hat. Diese Berechtigung wird normalerweise über die Rolle gkehub.connect erteilt. Ohne diese Berechtigung wird die Anfrage des Agents abgelehnt und es können keine Anfragen von Google Cloud empfangen werden.
Kubernetes API-Server
Der Agent stellt mit der Kubernetes-Clientbibliothek eine TLS-Verbindung zum Kubernetes API-Server her. Die Kubernetes-Laufzeit stellt dem Agent-Container ein Zertifikat der TLS-Zertifizierungsstelle (CA) zur Verfügung, mit dem der Agent den API-Servers authentifiziert.
Der API-Server authentifiziert jede Anfrage einzeln, wie im nächsten Abschnitt beschrieben.
Anfragesicherheit
Jede Anfrage, die von Google Cloud über Connect gesendet wird, enthält Anmeldedaten, mit denen der Absender identifiziert wird: der Google Cloud-Dienst, der die Anfrage generiert hat, und (falls zutreffend) der Endnutzer, für den die Anfrage gesendet wird. Mit diesen Anmeldedaten kann der Kubernetes API-Server für jede Anfrage Autorisierungs- und Auditing-Steuerelemente bereitstellen.
Authentifizierung von Dienst zu Agent
Jede Anfrage, die an den Agent gesendet wird, enthält ein kurzlebiges Token, das den Google Cloud-Dienst identifiziert, der die Anfrage gesendet hat. Dies ist im folgenden Diagramm dargestellt.
Das Token wird von einem Google Cloud-Dienstkonto signiert, das ausschließlich mit dem Google Cloud-Dienst verknüpft ist. Der Agent ruft die öffentlichen Schlüssel des Dienstkontos ab, um das Token zu validieren. Dieses Token wird nicht an den API-Server weitergeleitet.
Der Agent validiert Google Cloud-Zertifikate mithilfe von CA-Roots, die in dem Binärprogramm eingebettet sind. Dadurch empfängt er nur authentische und unveränderte Anfragen von Google Cloud.
Endnutzerauthentifizierung
Google Cloud-Dienste, die im Auftrag eines Nutzers auf Cluster zugreifen, benötigen die Anmeldedaten des Nutzers für die Authentifizierung beim API-Server. Dies ist im folgenden Diagramm dargestellt.
Mit dieser Richtlinie wird sichergestellt, dass beim Zugriff über Connect dieselben Berechtigungen angewendet werden. Einige Google Cloud-Dienste authentifizieren sich im Auftrag eines Nutzers beim API-Server. Ein Nutzer kann beispielsweise auf die Google Cloud Console zugreifen, um Arbeitslasten in flottenregistrierten Clustern abzurufen. Wenn ein Nutzer auf diese Dienste zugreift, stellt er Anmeldedaten bereit, die der Kubernetes API-Server erkennt: alle Token, die vom Kubernetes API-Server unterstützt werden.
In der Google Cloud Console werden diese Anmeldedaten als Teil des Nutzerprofils gespeichert. Diese Anmeldedaten werden im inaktiven Zustand verschlüsselt, sind nur mit den Google Cloud- oder Google Arbeitsbereich-Anmeldedaten des Nutzers zugänglich und werden nur für Verbindungen über Connect verwendet. Diese Anmeldedaten können nicht noch einmal heruntergeladen werden. Die Anmeldedaten werden gelöscht, wenn der Nutzer sich aus dem Cluster abmeldet, wenn die Clusterregistrierung in Google Cloud gelöscht wird, wenn das Projekt gelöscht wird oder wenn das Nutzerkonto gelöscht wird. Weitere Informationen finden Sie unter Datenlöschung auf der Google Cloud.
Wenn ein Nutzer mit der Google Cloud Console interagiert, erstellt sie Anfragen für den Kubernetes API-Server. Der Dienst sendet die Anmeldedaten des Nutzers zusammen mit der Anfrage über Connect. Der Agent stellt die Anfrage und die Anmeldedaten dann dem Kubernetes API-Server zur Verfügung.
Der Kubernetes API-Server authentifiziert die Anmeldedaten des Nutzers, führt die Autorisierung für die Nutzeridentität durch, erzeugt, wenn konfiguriert, ein Auditereignis für die Aktion und gibt das Ergebnis zurück. Da die vom Nutzer bereitgestellten Anmeldedaten zur Authentifizierung der Anfrage verwendet werden, wendet der Kubernetes API-Server die gleichen Autorisierungs- und Audit-Richtlinien für Connect-Anfragen wie für andere Anfragen an.
Authentifizierung von Dienst zu Kubernetes
Google Cloud-Dienste, die außerhalb des Nutzerkontexts auf den Kubernetes API-Server zugreifen, verwenden den Kubernetes-Identitätswechsel, um sich beim Kubernetes API-Server zu authentifizieren. Dadurch kann der Kubernetes API-Server Autorisierungsprüfungen und Audit-Logs für einzelne Dienste bereitstellen. Dies ist im folgenden Diagramm dargestellt.
Dienste in Google Cloud können Connect außerhalb des Nutzerkontexts verwenden. Beispielsweise kann ein Multicluster-Ingress-Dienst eingehenden Traffic automatisch clusterübergreifend synchronisieren. Diese Dienste haben keine Anmeldedaten, die vom Kubernetes API-Server authentifiziert werden können. Die meisten API-Server sind nicht für die Authentifizierung der Anmeldedaten des Google Cloud-Dienstes konfiguriert. Ein API-Server kann jedoch eingeschränkte Authentifizierungsberechtigungen über einen Identitätswechsel an einen anderen Dienst delegieren und der Agent kann Google Cloud-Dienste authentifizieren, die Anfragen über Connect senden. Zusammen ermöglicht dies, dass der Agent sich als Google Cloud-Dienstkonten authentifiziert.
Wenn ein Google Cloud-Dienst eine Anfrage im eigenen Namen sendet und nicht im Nutzerkontext, fügt der Agent der Anfrage eigene Kubernetes-Anmeldedaten und Kubernetes-Identitätswechsel-Header, die den Google Cloud-Dienst identifizieren, hinzu. Die Identitätswechsel-Header fordern einen Nutzernamen des Google Cloud-Dienstkontos an, das vom Agent authentifiziert wurde.
Der Kubernetes API-Server authentifiziert die Anmeldedaten des Agents und prüft auch, ob der Agent einen Identitätswechsel des Google Cloud-Dienstkontos durchführen kann. Die Möglichkeit zum Identitätswechsel wird in der Regel durch rollenbasierte Zugriffssteuerung (Role Based Access Control, RBAC) gesteuert und kann auf bestimmte Identitäten beschränkt werden, z. B. auf Google Cloud-Dienstkonten.
Wenn der Agent autorisiert ist, die angeforderte Identität zu verwenden, führt der API-Server Autorisierungsprüfungen für das Google Cloud-Dienstkonto durch und liefert die Anfrage. Das Audit-Log für die Anfrage enthält sowohl die Identität des Agents als auch die angenommene Identität des Google Cloud-Dienstkontos.
Sicherheit in Clustern
Der Agent sendet Kubernetes API-Anfragen an den Kubernetes API-Server, wie im folgenden Diagramm dargestellt.
Der Kubernetes API-Server authentifiziert, autorisiert und protokolliert diese Anfragen wie alle anderen Anfragen, die er bereitstellt.
Als Proxy für diese Anfragen hat der Agent Zugriff auf sensible Daten wie Anmeldedaten, Anfragen und Antworten. Kubernetes und das Kubernetes-System stellen eine Reihe von Tools bereit, mit denen verhindert werden kann, dass andere Nutzer Zugriff erhalten. Außerdem soll der Agent nur auf das zugreifen können, auf das er eigentlich zugreifen soll.
Kubernetes-Authentifizierung
Der Kubernetes API-Server authentifiziert den Absender jeder eingehenden Anfrage, um bestimmen, welche Berechtigungen in der Autorisierungsphase angewendet werden sollen. Wie zuvor beschrieben, enthält die Anfrage entweder die Anmeldedaten eines Nutzers oder die Kubernetes-Anmeldedaten und die Identitätswechsel-Header des Agents.
Clusteradministratoren behalten die Kontrolle über Authentifizierungsmechanismen, die vom Kubernetes API-Server erkannt werden. Administratoren können möglicherweise die Anmeldedaten eines Nutzers widerrufen und die Berechtigung für die Anmeldedaten des Agenten widerrufen oder einschränken.
Kubernetes-Autorisierung
Der Kubernetes API-Server prüft, ob die authentifizierte Identität die angeforderte Aktion für die angeforderte Ressource ausführen darf.
Der Clusteradministrator kann mit einem der Kubernetes-Autorisierungsmechanismen Autorisierungsregeln konfigurieren. Connect führt keine Autorisierungsprüfungen im Namen des Clusters durch.
Agent-Sicherheit
Der Agent hat Zugriff auf seine eigenen Anmeldedaten (von Kubernetes und Google Cloud) sowie auf die Anmeldedaten, Anfragen und Antworten, die ihn durchlaufen. Daher nimmt der Agent eine vertrauenswürdige Position in einem verbundenen Cluster ein.
Der Agent verfügt über die folgenden Sicherheitsgrundlagen:
- Der Agent wird in Go geschrieben, wodurch Arbeitsspeicherverwaltung mit automatisierter Speicherbereinigung ermöglicht wird und viele unsichere Speichervorgänge verhindert werden.
- Der Agent wird in einem distroless-Container-Image bereitgestellt. Das Image des Agents enthält keine Shell, libc oder anderen Code, der nicht zum Ausführungspfad des Agents gehört.
- Das Image des Agents wird von der gemeinsam genutzten Build-Infrastruktur von Google aus eingechecktem Code erstellt. Nur dieses Build-System kann Agent-Images in Container Registry bereitstellen. Google Cloud-Entwickler können neue Images nicht selbst bereitstellen. Dadurch wird sichergestellt, dass alle Änderungen an der Quelle des Agents auf einen Autor und Prüfer für Nachweisbarkeit zurückgeführt werden können.
Der Agent wird als Standardbereitstellung in einem Kubernetes-Cluster ausgeführt, der zum Zeitpunkt der Cluster-Registrierung bereitgestellt wird.
Aus diesem Grund stehen dem Agent alle Optionen und Best Practices zum Monitoring und Sichern von Bereitstellungen, ReplicaSets, und Pods zur Verfügung.
Diese Mechanismen sind so konzipiert, dass es schwierig ist, den Agent-Container zu manipulieren. Der privilegierte Zugriff auf den Knoten des Agents kann jedoch die Umgebung des Agents beeinträchtigen. Daher ist es für Administratoren wichtig, die Kubernetes-Sicherheitsrichtlinien zum Schutz der Clusterinfrastruktur einzuhalten.
Datensicherheit mit VPC Service Controls
VPC Service Controls bietet eine zusätzliche Sicherheitsebene für Google Cloud-Dienste, die unabhängig von der Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) ist. IAM ermöglicht eine detaillierte identitätsbasierte Zugriffssteuerung. VPC Service Controls hingegen ermöglicht eine breitere kontextbasierte Perimetersicherheit, einschließlich der Kontrolle ausgehender Datenübertragungen im gesamten Perimeter. Sie können beispielsweise angeben, dass nur bestimmte Projekte auf Ihre BigQuery-Daten zugreifen können. Weitere Informationen zum Schutz von Daten mit VPC Service Controls finden Sie hier.
Sie können VPC Service Controls mit Connect für zusätzliche Datensicherheit verwenden, wenn Sie dafür sorgen, dass aus dem angegebenen Dienstperimeter auf die erforderlichen Dienste zugegriffen werden kann. Weitere Informationen zu den Voraussetzungen für Connect