Wenn Sie Ihre Kubernetes-Cluster über Google Cloud bei Connect registrieren, wird eine langlebige authentifizierte und verschlüsselte Verbindung zwischen Ihren Clustern und der Google Cloud-Steuerungsebene hergestellt. Über die Verbindung werden Informationen zu Clustern in der Google Cloud Console bereitgestellt. Außerdem können Sie damit Konfigurationen und Ressourcen mithilfe von GKE Enterprise-Komponenten und -Features wie Config Management verwalten und in Clustern bereitstellen.
In diesem Thema wird die Art der Verbindung zwischen Google Cloud und Connect beschrieben und es werden Details zu den Google Cloud-Controllern angezeigt, die über Connect auf Ihren Clustern ausgeführt werden.
Verbindung zwischen Google Cloud und Connect
Wie im Thema Sicherheitsfunktionen beschrieben, sendet nur die Google Cloud-Steuerungsebene Anfragen über die Verbindung zu jedem verbundenen Cluster (z. B. zum API-Server eines Clusters). Der Cluster wiederum sendet Antworten an die Steuerungsebene zurück. (Clusterdienste und -ressourcen können keine Anfragen an die Steuerungsebene über Connect initiieren.) Über die Verbindung können autorisierte Nutzer und die Google-Automatisierung die Cluster erreichen und sich authentifizieren.
Mit Connect können beispielsweise in der Google Cloud Console Informationen zu Arbeitslasten und Diensten abgerufen werden oder über Config Management die Installation oder Aktualisierung des Connect-In-Cluster-Agents und den Synchronisierungsstatus ermöglicht werden. Mit Connect kann auch der Metering-Agent die Anzahl der vCPUs in einem verbundenen Cluster beobachten.
Connect bietet keine Datenübertragung für Container-Images, Load-Balancing, Datenbankverbindungen, Logging oder Monitoring. Dafür müssen Sie Verbindungen für Personen parallel herstellen.
Google Cloud Console-Nutzerzugriff auf Cluster über Connect
Nachdem sich Nutzer in Ihrer Organisation über die Google Cloud Console in einem Cluster angemeldet haben, haben sie spezifische Clusterberechtigungen, die von den rollenbasierten Zugriffssteuerungen (RBAC) bestimmt werden. Der Cluster (nicht Connect) erzwingt die Berechtigungen. Mit Standard-Kubernetes-Logs können Sie die Aktionen beobachten, die jeder Nutzer bei der Verwaltung eines Clusters ausgeführt hat.
Die folgende Tabelle zeigt, welche Teile der Google Cloud Console Nutzern die Interaktion mit Clustern über Connect ermöglichen.
| Abschnitt Google Cloud Console | Optionen für Nutzer |
|---|---|
| GKE Enterprise | Flottenregistrierte Cluster und Arbeitslasten verwalten; GKE Enterprise-Komponenten verwalten. |
| Kubernetes Engine | Flottenregistrierte Cluster und Arbeitslasten verwalten. |
| Cloud Run for Anthos | Dienste und Anwendungen erstellen, bereitstellen und verwalten. |
| Marketplace | Drittanbieteranwendungen bereitstellen und verwalten. |
Zugriff auf Controller von Google Cloud auf Cluster über Connect
Google Cloud-Controller verwenden einen Connect Agent, um von der Google Cloud-Steuerungsebene aus auf einen Cluster zuzugreifen. Diese Controller bieten Verwaltung und Automatisierung für die Funktionen, die Sie in Ihren Clustern aktivieren. Config Management verfügt beispielsweise über einen Google Cloud-seitigen Controller, der den Lebenszyklus von In-Cluster-Agents leitet und eine UI zum Konfigurieren und Aufrufen des Status von Config Management bietet, der in mehreren Clustern ausgeführt wird.
Verschiedene Controller greifen auf Cluster mit unterschiedlichen Identitäten zu. Sie können die Aktivitäten jedes Controllers in Kubernetes-Audit-Logs prüfen.
In der folgenden Tabelle wird zusammengefasst, wie Google Cloud-Controller über Connect miteinander arbeiten. Die Tabelle enthält wichtige Details zu Controllern: die erforderlichen Berechtigungen, ihre IDs in Kubernetes-Audit-Logs und ob sie deaktiviert werden können.
Wenn Sie eine Komponente in diesem Kontext deaktivieren, wird sie vollständig deaktiviert, ohne einzelne Teile der Komponente in Clustern verwenden zu können.
| Komponentenname | Kann deaktiviert werden? | Clusterrolle / RBAC-Berechtigungen | Beschreibung | ID in Cluster-Audit-Logs |
|---|---|---|---|---|
| Feature-Autorisierer | Nein (standardmäßig aktiviert) | cluster-admin |
Mit der Feature-Autorisierer-Funktion wird RBAC für flottenfähige Komponenten oder Funktionen hinzugefügt, die auf Kubernetes-Clustern ausgeführt werden. So wird sichergestellt, dass jede Komponente die spezifischen Berechtigungen hat, die zum Ausführen ihrer Funktionen erforderlich sind. Sie können die Funktion "Autorisieren" nicht deaktivieren, solange im Projekt registrierte Mitgliedschaften vorhanden sind. Weitere Informationen finden Sie unter Feature-Autorisierung in einer Flotte. |
service-project-number@gcp-sa-gkehub.iam.gserviceaccount.com |
| Config Management | Ja (standardmäßig deaktiviert) | cluster-admin |
Der Config Management-Controller verwaltet seine eigenen In-Cluster-Agents und bietet eine Benutzeroberfläche, die den Status von Config Management für alle Cluster in einer Flotte anzeigt. Der Controller installiert seine clusterinternen Komponenten und erstellt ein lokales Dienstkonto mit den entsprechenden Berechtigungen, um alle Arten von Kubernetes-Konfigurationen für Nutzer bereitzustellen. Wenn er In-Cluster-Komponenten nicht installiert oder verwaltet, liest der Config Management-Controller Statusinformationen von seinem Cluster-Agent. |
service-project-number@gcp-sa-acm.iam.gserviceaccount.com |
| Nutzungsmessung | Nein (standardmäßig aktiviert) | Siehe RBAC-Definition | Der Messwert-Controller liest grundlegende Informationen über verbundene Cluster, um Abrechnungsdienste bereitzustellen. Für diesen Controller sind folgende Berechtigungen erforderlich:
Sie können die Messung nicht deaktivieren, solange im Projekt registrierte Mitgliedschaften vorhanden sind. |
service-project-number@gcp-sa-mcmetering.iam.gserviceaccount.com |
RBAC für bestimmte Komponenten, die über Connect ausgeführt werden
Die folgenden API-Definitionen zeigen die Zugriffssteuerungsberechtigungen für verschiedene Komponentenressourcen, die über Connect ausgeführt werden.
RBAC für die Nutzungsmessung über Connect
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
hub.gke.io/owner-feature: metering
hub.gke.io/project: [PROJECT_ID]
name: metering
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/metering
rules:
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- watch
- list
- apiGroups:
- metering.gke.io
resources:
- usagerecords
verbs:
- get
- list
- watch
- delete
- apiGroups:
- anthos.gke.io
resources:
- entitlements
verbs:
- create
- delete
- get
- list
- update
- watch
- apiGroups:
- apiextensions.k8s.io
resources:
- customresourcedefinitions
verbs:
- create
- list
- watch
- apiGroups:
- apiextensions.k8s.io
resourceNames:
- entitlements.anthos.gke.io
resources:
- customresourcedefinitions
verbs:
- get