DevOps-Ingenieure stellen eine Verbindung zur vSphere IaaS control plane her, um TKG-Dienst-Cluster bereitzustellen und deren Lebenszyklus zu verwalten. Entwickler stellen eine Verbindung zu TKG-Dienst-Clustern her, um Pakete, Arbeitslasten und Dienste bereitzustellen. Administratoren benötigen möglicherweise direkten Zugriff auf TKG-Dienst-Clusterknoten, um Fehler zu beheben. Auf der Plattform werden Tools für die Identitäts- und Zugriffsverwaltung sowie Methoden bereitgestellt, die alle Anwendungsfälle und Rollen unterstützen.

TKG-Dienst-Clusterzugriff erfolgt über den vSphere-Namespace

Sie stellen TKG-Dienst-Cluster in einem vSphere-Namespace bereit. Wenn Sie einen vSphere-Namespace konfigurieren, legen Sie dessen DevOps-Berechtigungen fest, einschließlich der Identitätsquelle, der Benutzer und Gruppen sowie der Rollen. Die Plattform gibt diese Berechtigungen an jeden in diesem vSphere-Namespace bereitgestellten TKG-Dienst-Cluster weiter. Die Plattform unterstützt zwei Authentifizierungsmethoden: vCenter Single Sign-On und einen OIDC-konformen externen Identitätsanbieter.

Authentifizierung mithilfe von vCenter Single Sign-On und Kubectl

Standardmäßig wird vCenter Single Sign-On zur Authentifizierung bei der Umgebung verwendet, einschließlich Supervisor- und TKG-Dienst-Clustern. vCenter Single Sign-On bietet Authentifizierung für die vSphere-Infrastruktur und kann in AD/LDAP-Systeme integriert werden. Weitere Informationen finden Sie unter vSphere-Authentifizierung mit vCenter Single Sign-On.

Für die Authentifizierung mit vCenter Single Sign-On verwenden Sie das vSphere-Plug-In für kubectl. Nach der Authentifizierung verwenden Sie kubectl, um den Lebenszyklus von TKG-Dienstclustern deklarativ bereitzustellen und zu verwalten und mit Supervisor zu interagieren.

Das vSphere-Plug-In für kubectl-Plug-In hängt von kubectl ab. Wenn Sie sich mit dem Befehl kubectl vsphere login authentifizieren, gibt das Plug-In eine POST-Anforderung mit Standardauthentifizierung für einen /wcp/login-Endpoint auf Supervisor aus. vCenter Server gibt ein JSON-Web-Token (JWT) aus, dem der Supervisor vertraut.

Informationen zum Herstellen einer Verbindung über vCenter Single Sign-On finden Sie unter Herstellen einer Verbindung zu TKG-Dienst-Clustern mithilfe der vCenter SSO-Authentifizierung.

Authentifizierung mithilfe eines externen Identitätsanbieters und der Tanzu-CLI

Sie können Supervisor mit einem externen Identitätsanbieter konfigurieren, der das OpenID Connect-Protokoll unterstützt. Nach der Konfiguration fungiert Supervisor als OAuth 2.0-Client und verwendet den Authentifizierungsdienst Pinniped, um mithilfe der Tanzu-CLI Client-Konnektivität bereitzustellen. Die Tanzu-CLI unterstützt die Bereitstellung und Verwaltung des Lebenszyklus von TKG-Dienst-Clustern. Jede Supervisor-Instanz kann nur einen externen Identitätsanbieter unterstützen.

Sobald das Authentifizierungs-Plug-In und der OIDC-Aussteller ordnungsgemäß für die Funktion der pinniped-auth-CLI konfiguriert sind, sucht das System bei Supervisor mit tanzu login --endpoint nach einigen bekannten Configmaps, um die pinniped config-Konfigurationsdatei zu erstellen.

Informationen zum Herstellen einer Verbindung mithilfe eines externen OIDC-Anbieters finden Sie unter Herstellen einer Verbindung zu TKG-Clustern auf Supervisor mithilfe eines externen Identitätsanbieters.

Authentifizierung mit einem hybriden Ansatz: vCenter SSO mit Tanzu CLI

Wenn Sie vCenter Single Sign-On als Identitätsanbieter verwenden und die Tanzu-CLI einsetzen möchten, können Sie einen hybriden Ansatz nutzen und sich mithilfe der beiden Tools bei Supervisor anmelden. Dieser Ansatz kann für die Installation von Standardpaketen nützlich sein. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu Supervisor mithilfe der Tanzu-CLI und der vCenter SSO-Authentifizierung.

Benutzer und Gruppen für DevOps

Die beim Konfigurieren eines vSphere-Namespace eingerichteten Berechtigungen gelten für DevOps-Benutzer, die den Lebenszyklus von TKG-Dienst-Clustern verwalten. Der DevOps-Benutzer oder die DevOps-Gruppe, der Sie Berechtigungen zuweisen, muss in der Identitätsquelle vorhanden sein. DevOps-Benutzer authentifizieren sich mit ihren Identitätsanbieter-Anmeldedaten.

DevOps-Benutzer sind dafür verantwortlich, nachgelagerten Benutzern Clusterzugriff zu gewähren, wie z. B. Entwicklern, die Arbeitslasten auf bereitgestellten Clustern zur Verfügung stellen möchten. Diese Benutzer authentifizieren sich mithilfe eines Identitätsanbieters oder einer Clusterrolle und Bindung bei Kubernetes. Dieser Vorgang wird im folgenden Abschnitt genauer beschrieben.
Hinweis: vSphere-Namespace-Berechtigungen gelten ausschließlich für DevOps-Benutzer, die TKG-Dienst-Cluster erstellen und verwalten müssen. Benutzer dieser Cluster, wie z. B. Entwickler, verwenden den Kubernetes-Authentifizierungsmechanismus.

Rollenberechtigungen und -bindungen

Zwei Arten von RBAC-Systemen (Role Based Access Control, Rollenbasierte Zugriffssteuerung) stehen für TKGS-Cluster zur Verfügung: vSphere-Namespace-Berechtigungen und Kubernetes RBAC-Autorisierung. Als vSphere-Administrator weisen Sie vSphere-Namespace-Berechtigungen zu, damit Benutzer TKG-Dienstcluster erstellen und betreiben können. Cluster-Operatoren verwenden Kubernetes RBAC, um Entwicklern Clusterzugriff zu gewähren und Rollenberechtigungen zuzuweisen. Weitere Informationen hierzu finden Sie unter Gewähren von vCenter SSO-Zugriff auf TKG-Dienst-Cluster für Entwickler.

vSphere-Namespaces unterstützen drei Rollen: Schreibzugriff, Lesezugriff und Besitzer. Rollenberechtigungen werden zum vSphere-Namespace, in dem ein TKG-Dienst-Cluster gehostet wird, zugewiesen und auf diesen beschränkt. Weitere Informationen hierzu finden Sie unter Konfigurieren von vSphere-Namespaces für das Hosting von TKG-Dienst-Clustern.

Ein Benutzer / eine Gruppe, dem/der die Rollenberechtigung Kann bearbeiten für einen vSphere-Namespace zugewiesen wurde, kann TKG-Dienst-Cluster in diesem vSphere-Namespace erstellen, lesen, aktualisieren und löschen. Wenn Sie der Rolle Schreibzugriff darüber hinaus einen Benutzer/eine Gruppe zuweisen, erstellt das System in jedem Cluster in diesem vSphere-Namespace eine Rollenbindung und bindet die Berechtigung an die Kubernetes-Clusterrolle mit dem Namen cluster-admin. Mithilfe der Rolle cluster-admin können Benutzer TKG-Dienstcluster im Ziel- vSphere-Namespace bereitstellen und betreiben. Sie können diese Zuordnung mit dem Befehl kubectl get rolebinding im Ziel- vSphere-Namespace anzeigen. 
kubectl get rolebinding -n tkgs-cluster-namespace
NAME                                                           ROLE                         AGE
wcp:tkg-cluster-namespace:group:vsphere.local:administrators   ClusterRole/edit             33d
wcp:tkg-cluster-namespace:user:vsphere.local:administrator     ClusterRole/edit             33d

Ein Benutzer oder eine Gruppe, der die Rollenberechtigung Lesezugriff für einen vSphere-Namespace gewährt wird, hat Lesezugriff auf TKG-Dienst-Clusterobjekte, die in diesem vSphere-Namespace bereitgestellt werden. Anders als bei der Berechtigung Schreibzugriff wird für die Rolle Lesezugriff keine Kubernetes-Rollenbindung in TKGS-Clustern in diesem vSphere-Namespace erstellt. Der Grund hierfür besteht darin, dass in Kubernetes keine vergleichbare schreibgeschützte Rolle vorhanden ist, an die ein Benutzer oder eine Gruppe mit der Berechtigung Lesezugriff gebunden werden kann. Für andere Benutzer als cluster-admin verwenden Sie Kubernetes RBAC, um Zugriff zu gewähren. Weitere Informationen finden Sie unter Gewähren von vCenter SSO-Zugriff auf TKG-Dienst-Cluster für Entwickler.

Ein Benutzer/eine Gruppe, dem/der die Berechtigung Besitzer für einen vSphere-Namespace gewährt wurde, kann TKG-Dienst-Cluster in diesem vSphere-Namespace verwalten und zusätzliche vSphere-Namespaces mithilfe von kubectl erstellen und löschen. Wenn Sie der Rolle „Besitzer“ einen Benutzer bzw. eine Gruppe zuweisen, erstellt das System ein ClusterRoleBinding-Objekt und ordnet es einem ClusterRole-Objekt zu, mit dem der Benutzer bzw. die Gruppe vSphere-Namespaces mithilfe von kubectl erstellen und löschen kann. Sie können diese Zuordnung nicht mit demselben Verfahren anzeigen. Sie müssen sich per SSH bei einem Supervisor-Knoten anmelden, um diese Zuordnung anzuzeigen.
Hinweis: Die Besitzerrolle wird für Benutzer unterstützt, die aus der vCenter Single Sign-On-Identitätsquelle stammen. Sie können die Rolle „Besitzer“ nicht mit einem Benutzer / einer Gruppe eines externen Identitätsanbieters verwenden.

vSphere-Berechtigungen

Die Tabelle zeigt die Typen von vSphere-Berechtigungen, die für verschiedene vSphere IaaS control plane-Personas erforderlich sind. Bei Bedarf können Sie eine benutzerdefinierte vSphere SSO-Gruppe und -Rolle für die Arbeitslastverwaltung erstellen. Weitere Informationen hierzu finden Sie unter Erstellen einer dedizierten Gruppe und Rolle für Plattformoperatoren.

Tabelle 1. vSphere-Berechtigungen für vSphere with Tanzu-Personas
Persona vSphere-Rolle vSphere-SSO-Gruppe vSphere-Namespace
VI/Cloud-Administrator Administrator Administratoren SSO-Benutzer und/oder AD-Benutzer
DevOps-/Plattform-Operator Nicht-Admin oder benutzerdefinierte Rolle ServiceProviderUsers SSO-Benutzer und/oder AD-Benutzer
Entwickler Schreibgeschützt oder keine Keine SSO-Benutzer und/oder AD-Benutzer

Systemadministrator-Konnektivität

Administratoren können als kubernetes-admin-Benutzer eine Verbindung mit TKG-Dienst-Clusterknoten herstellen. Diese Methode kann empfehlenswert sein, wenn die vCenter Single Sign-On-Authentifizierung nicht verfügbar ist. Zu Fehlerbehebungszwecken können Systemadministratoren mithilfe von SSH und einem privaten Schlüssel als vmware-system-user eine Verbindung mit einem TKG-Dienst herstellen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zu TKG-Dienst-Clustern als Kubernetes-Administrator und Systembenutzer.