Les ingénieurs DevOps se connectent au vSphere IaaS control plane pour provisionner et gérer le cycle de vie des clusters Service TKG. Les développeurs se connectent aux clusters Service TKG pour déployer des modules, des charges de travail et des services. Les administrateurs peuvent avoir besoin d'un accès direct aux nœuds des clusters Service TKG pour résoudre les problèmes. La plate-forme fournit des outils et des méthodes de gestion des identités et des accès prenant en charge chaque cas d'utilisation et rôle.

L'accès au cluster Service TKG est étendu à l'Espace de noms vSphere

Vous provisionnez des clusters Service TKG dans un Espace de noms vSphere. Lorsque vous configurez un Espace de noms vSphere, vous définissez des autorisations DevOps pour cet espace de noms, y compris la source d'identité, les utilisateurs et les groupes, ainsi que les rôles. La plate-forme propage ces autorisations à chaque cluster Service TKG provisionné dans cet Espace de noms vSphere. La plate-forme prend en charge deux méthodes d'authentification : vCenter Single Sign-On et un fournisseur d'identité externe compatible OIDC.

Authentification à l'aide de vCenter Single Sign-On et Kubectl

Par défaut, vCenter Single Sign-On est utilisé pour s'authentifier auprès de l'environnement, y compris le Superviseur et les clusters Service TKG. vCenter Single Sign-On fournit une authentification pour l'infrastructure vSphere et peut s'intégrer aux systèmes AD/LDAP. Pour plus d'informations, reportez-vous à la section Authentification de vSphere avec vCenter Single Sign-On.

Pour vous authentifier à l'aide de vCenter Single Sign-On, utilisez le Plug-in vSphere pour kubectl. Une fois authentifié, vous utilisez kubectl pour provisionner et gérer de manière déclarative le cycle de vie des clusters de service TKG et interagir avec le Superviseur.

Le plug-in Plug-in vSphere pour kubectl dépend de kubectl. Lorsque vous vous authentifiez avec la commande kubectl vsphere login, le plug-in effectue une demande POST avec une authentification de base pour un point de terminaison /wcp/login sur le Superviseur. vCenter Server émet un jeton Web JSON (JWT) que le Superviseur approuve.

Pour vous connecter à l'aide de vCenter Single Sign-On, reportez-vous à la section Connexion à des clusters Service TKG à l'aide de l'authentification vCenter SSO.

Authentification à l'aide d'un fournisseur d'identité externe et de l'interface de ligne de commande Tanzu

Vous pouvez configurer Superviseur avec un fournisseur d'identité externe qui prend en charge le protocole OpenID Connect. Une fois configuré, le Superviseur fonctionne en tant que client OAuth 2.0 et utilise le service d'authentification Pinniped pour fournir la connectivité au client à l'aide de la CLI Tanzu. La Tanzu CLI prend en charge le provisionnement et la gestion du cycle de vie des clusters Service TKG. Chaque instance de Superviseur peut prendre en charge un fournisseur d'identité externe unique.

Une fois que le plug-in d'authentification et l'émetteur OIDC sont configurés de manière appropriée pour que l'interface de ligne de commande pinniped-auth fonctionne, lorsque vous vous connectez au Superviseur avec tanzu login --endpoint, le système recherche quelques ConfigMaps connus pour créer le fichier de configuration pinniped config.

Pour vous connecter à l'aide d'un fournisseur OIDC externe, reportez-vous à la section Connexion à des clusters TKG sur le Superviseur en utilisant un fournisseur d'identité externe.

Authentification à l'aide d'une approche hybride : vCenter SSO avec l'interface de ligne de commande Tanzu

Si vous utilisez vCenter Single Sign-On comme fournisseur d'identité et que vous souhaitez utiliser l'Tanzu CLI, vous pouvez adopter une approche hybride et vous connecter au Superviseur à l'aide de ces deux outils. Cette approche peut être utile pour l'installation de modules standard. Reportez-vous à la section Se connecter au Superviseur à l'aide de l'interface de ligne de commande Tanzu et de l'authentification vCenter SSO.

Utilisateurs et groupes pour DevOps

Les autorisations que vous établissez lorsque vous configurez un Espace de noms vSphere permettent aux utilisateurs DevOps de gérer le cycle de vie des clusters Service TKG. L'utilisateur ou le groupe DevOps auquel vous attribuez des autorisations doit exister dans la source d'identité. Les utilisateurs DevOps s'authentifient à l'aide de leurs informations d'identification de fournisseur d'identité.

Les utilisateurs DevOps sont responsables d'octroyer un accès au cluster aux utilisateurs en aval, tels que les développeurs qui souhaitent déployer des charges de travail sur des clusters provisionnés. Ces utilisateurs s'authentifient à l'aide d'un fournisseur d'identité ou à l'aide d'un rôle de cluster et d'une liaison sur Kubernetes. Cela est décrit plus en détail dans la section suivante.
Note : Les autorisations pour l' Espace de noms vSphere sont exclusivement destinées aux utilisateurs DevOps qui doivent créer et gérer des clusters Service TKG. Les utilisateurs de ces clusters, tels que les développeurs, utiliseront des mécanismes d'authentification Kubernetes.

Autorisations de rôle et liaisons

Il existe deux types de systèmes de contrôle d'accès basé sur les rôles (RBAC) pour les clusters TKGS : les autorisations pour l'Espace de noms vSphere et l'autorisation RBAC Kubernetes. En tant qu'administrateur vSphere, vous attribuez des autorisations pour l'Espace de noms vSphere pour permettre aux utilisateurs de créer et d'exploiter des clusters de service TKG. Les opérateurs de cluster utilisent le RBAC Kubernetes pour accorder l'accès au cluster et attribuer des autorisations de rôle aux développeurs. Reportez-vous à la section Accorder aux développeurs l'accès vCenter SSO aux clusters Service TKG.

Les Espaces de noms vSphere prennent en charge trois rôles : Peut modifier, Peut afficher et Propriétaire. Les autorisations de rôle sont attribuées et étendues à l'Espace de noms vSphere qui héberge un cluster Service TKG. Reportez-vous à la section Configuration de Espaces de noms vSphere pour l'hébergement de clusters Service TKG.

Un utilisateur/groupe disposant de l'autorisation de rôle Peut modifier sur un Espace de noms vSphere peut créer, lire, mettre à jour et supprimer des clusters Service TKG dans cet Espace de noms vSphere. En outre, lorsque vous attribuez un utilisateur ou un groupe au rôle Peut modifier, le système crée une liaison RoleBinding sur chaque cluster de cet Espace de noms vSphere et lie le privilège au ClusterRole Kubernetes nommé cluster-admin. Le rôle cluster-admin permet aux utilisateurs de provisionner et d'utiliser des clusters de service TKG dans l' Espace de noms vSphere cible. Vous pouvez afficher ce mappage à l'aide de la commande kubectl get rolebinding à partir de l' Espace de noms vSphere cible. 
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

Un utilisateur/groupe disposant de l'autorisation de rôle Peut afficher sur un Espace de noms vSphere dispose d'un accès en lecture seule aux objets de clusters Service TKG provisionnés dans cet Espace de noms vSphere. Cependant, contrairement au privilège Peut modifier, pour le rôle Peut afficher, aucune liaison RoleBinding Kubernetes n'est créée sur les clusters TKGS dans cet Espace de noms vSphere. Cela est dû au fait que dans Kubernetes, il n'existe aucun rôle en lecture seule équivalent auquel un utilisateur ou un groupe disposant de l'autorisation Peut afficher peut être lié. Pour les utilisateurs autres que cluster-admin, vous utilisez le RBAC Kubernetes pour accorder l'accès. Reportez-vous à la section Accorder aux développeurs l'accès vCenter SSO aux clusters Service TKG.

Un utilisateur/groupe disposant de l'autorisation Propriétaire sur un Espace de noms vSphere peut administrer les clusters Service TKG dans cet Espace de noms vSphere, et peut créer et supprimer des Espaces de noms vSphere supplémentaires à l'aide de kubectl. Lorsque vous attribuez un utilisateur ou un groupe au rôle de propriétaire, le système crée une liaison ClusterRoleBinding et la mappe à un ClusterRole qui permet à l'utilisateur ou au groupe de créer et de supprimer des Espaces de noms vSphere à l'aide de kubectl. Vous ne pouvez pas afficher ce mappage à l'aide de la même approche. Vous devez vous connecter par SSH à un nœud de Superviseur pour afficher ce mappage.
Note : Le rôle de propriétaire est pris en charge pour les utilisateurs provenant de la source d'identité vCenter Single Sign-On. Vous ne pouvez pas utiliser le rôle de propriétaire avec un utilisateur ou un groupe d'identité d'un fournisseur d'identité externe.

Autorisations de vSphere

Ce tableau affiche les types d'autorisations vSphere requis pour divers personas de vSphere IaaS control plane. Si nécessaire, vous pouvez créer un groupe et un rôle vSphere SSO personnalisés pour la gestion de la charge de travail. Reportez-vous à la section Créer un groupe dédié et un rôle pour les opérateurs de plate-forme.

Tableau 1. Autorisations de vSphere pour les personas vSphere with Tanzu
Persona Rôle vSphere Groupe vSphere SSO Espace de noms vSphere
Administrateur VI/Cloud Administrateur Administrateurs Utilisateur SSO et/ou utilisateur AD
DevOps/Opérateur de plate-forme Non-administrateur ou rôle personnalisé ServiceProviderUsers Utilisateur SSO et/ou utilisateur AD
Développeur Lecture seule ou Aucun Aucun Utilisateur SSO et/ou utilisateur AD

Connectivité de l'administrateur système

Les administrateurs peuvent se connecter aux nœuds de cluster Service TKG en tant qu'utilisateur kubernetes-admin. Cette méthode peut être appropriée si l'authentification vCenter Single Sign-On n'est pas disponible. À des fins de dépannage, les administrateurs système peuvent se connecter à un Service TKG en tant qu'utilisateur vmware-system-user à l'aide du protocole SSH et d'une clé privée. Reportez-vous à la section Connexion à des clusters Service TKG en tant qu'administrateur Kubernetes et utilisateur système.