I tecnici di DevOps si connettono a vSphere IaaS control plane per eseguire il provisioning e gestire il ciclo di ciclo di vita dei cluster Servizio TKG. Gli sviluppatori si connettono ai cluster Servizio TKG per distribuire pacchetti, carichi di lavoro e servizi. È possibile che gli amministratori necessitino dell'accesso diretto ai nodi del cluster Servizio TKG per la risoluzione dei problemi. La piattaforma fornisce strumenti e metodi di gestione delle identità e degli accessi che supportano ogni caso d'uso e ruolo.

L'ambito dell'accesso al cluster Servizio TKG è lo Spazio dei nomi vSphere

Il provisioning dei cluster Servizio TKG viene eseguito in uno Spazio dei nomi vSphere. Quando si configura Spazio dei nomi vSphere, si impostano le autorizzazioni di DevOps, tra cui l'origine dell'identità, gli utenti, i gruppi e i ruoli. La piattaforma propaga queste autorizzazioni a ogni cluster Servizio TKG di cui è stato eseguito il provisioning in tale Spazio dei nomi vSphere. La piattaforma supporta due metodi di autenticazione, ovvero vCenter Single Sign-On e un provider di identità esterno conforme a OIDC.

Autenticazione tramite vCenter Single Sign-On e Kubectl

Per impostazione predefinita, vCenter Single Sign-On viene utilizzato per eseguire l'autenticazione nell'ambiente, inclusi il Supervisore e i cluster Servizio TKG. vCenter Single Sign-On fornisce l'autenticazione per l'infrastruttura vSphere e può integrarsi con i sistemi AD/LDAP. Per ulteriori informazioni, vedere Autenticazione di vSphere con vCenter Single Sign-On.

Per eseguire l'autenticazione mediante vCenter Single Sign-On, utilizzare Plug-in vSphere per kubectl. Dopo l'autenticazione, utilizzare kubectl per eseguire il provisioning e gestire il ciclo di vita dei cluster TKG Service in modo dichiarativo, nonché interagire con Supervisore.

Il plug-in Plug-in vSphere per kubectl dipende da kubectl. Quando si esegue l'autenticazione con il comando kubectl vsphere login, il plug-in genera una richiesta POST con autenticazione di base in un endpoint /wcp/login in Supervisore. vCenter Server genera un token Web JSON (JWT) che Supervisore considera attendibile.

Per connettersi utilizzando vCenter Single Sign-On, vedere Connessione ai cluster Servizio TKG tramite l'autenticazione SSO di vCenter.

Autenticazione mediante un provider di identità esterno e la CLI Tanzu

È possibile configurare Supervisore con un provider di identità esterno che supporti il protocollo OpenID Connect. Una volta configurato, Supervisore funziona come un client OAuth 2.0 e utilizza il servizio di autenticazione Pinniped per fornire connettività client tramite la CLI di Tanzu. La CLI di Tanzu supporta il provisioning e la gestione del ciclo di vita dei cluster Servizio TKG. Ogni istanza Supervisore può supportare un singolo provider di identità esterno.

Una volta che il plug-in di autenticazione e l'emittente di OIDC sono stati configurati correttamente per il funzionamento della CLI pinniped-auth, quando si accede al Supervisore utilizzando tanzu login --endpoint, il sistema cerca alcune mappe di configurazione note per creare il file di configurazione pinniped config.

Per connettersi utilizzando un provider OIDC esterno, vedere Connessione ai cluster TKG in Supervisore tramite un provider di identità esterno.

Autenticazione con un approccio ibrido: vCenter SSO con la CLI di Tanzu

Se si utilizza vCenter Single Sign-On come provider di identità e si desidera utilizzare CLI di Tanzu, è possibile adottare un approccio ibrido e accedere a Supervisore usando entrambi gli strumenti. Questo approccio può essere utile per l'installazione dei pacchetti standard. Vedere Connessione a Supervisore tramite la CLI di Tanzu e l'autenticazione SSO di vCenter.

Utenti e gruppi per DevOps

Le autorizzazioni stabilite quando si configura un'istanza dello Spazio dei nomi vSphere consentono agli utenti di DevOps di gestire il ciclo di vita dei cluster Servizio TKG. L'utente o il gruppo di DevOps a cui si assegnano le autorizzazioni deve esistere nell'origine dell'identità. Gli utenti di DevOps eseguono l'autenticazione utilizzando le credenziali del loro provider di identità.

Gli utenti di DevOps sono responsabili della concessione dell'accesso al cluster agli utenti downstream come gli sviluppatori che desiderano distribuire carichi di lavoro nei cluster sottoposti a provisioning. Questi utenti eseguono l'autenticazione utilizzando un provider di identità o un ruolo cluster e un binding in Kubernetes. Questo comportamento è descritto più dettagliatamente nella sezione seguente.
Nota: Le autorizzazioni dello Spazio dei nomi vSphere sono esclusivamente per gli utenti di DevOps che devono creare e gestire i cluster Servizio TKG. Gli utenti di questi cluster, ad esempio gli sviluppatori, utilizzeranno i meccanismi di autenticazione di Kubernetes.

Autorizzazioni e binding dei ruoli

Per i cluster TKGS sono disponibili due tipi di sistemi di controllo degli accessi in base al ruolo (RBAC), ovvero autorizzazioni di Spazio dei nomi vSphere e autorizzazione RBAC di Kubernetes. Un amministratore di vSphere assegna le autorizzazioni di Spazio dei nomi vSphere per consentire agli utenti di creare e far funzionare i cluster TKG Service. Gli operatori del cluster utilizzano RBAC di Kubernetes per concedere l'accesso al cluster e assegnare le autorizzazioni dei ruoli agli sviluppatori. Vedere Come concedere agli sviluppatori l'accesso SSO di vCenter ai cluster Servizio TKG.

Spazi dei nomi vSphere supportano tre ruoli, ovvero Può modificare, Puo visualizzare e Proprietario. Le autorizzazioni dei ruoli vengono assegnate nello Spazio dei nomi vSphere che ospita un cluster Servizio TKG e hanno come ambito tale spazio dei nomi. Vedere Configurazione di Spazi dei nomi vSphere per l'hosting di cluster Servizio TKG.

Un utente o un gruppo a cui è stata concessa l'autorizzazione del ruolo Può modificare in uno Spazio dei nomi vSphere può creare, leggere, aggiornare ed eliminare i cluster Servizio TKG in tale Spazio dei nomi vSphere. Quando si assegna un utente o un gruppo al ruolo Può modificare, il sistema crea inoltre un RoleBinding in ogni cluster in tale Spazio dei nomi vSphere e associa il privilegio al ClusterRole Kubernetes denominato cluster-admin. Il ruolo cluster-admin consente agli utenti di eseguire il provisioning e far funzionare i cluster TKG Service in Spazio dei nomi vSphere di destinazione. È possibile visualizzare questa mappatura utilizzando il comando kubectl get rolebinding dal Spazio dei nomi vSphere di destinazione. 
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 utente o un gruppo a cui è stata concessa l'autorizzazione del ruolo Può visualizzare in uno Spazio dei nomi vSphere dispone dell'accesso in sola lettura agli oggetti cluster Servizio TKG di cui è stato eseguito il provisioning in tale Spazio dei nomi vSphere. Tuttavia, a differenza del privilegio Può modificare per il ruolo Può visualizzare non viene creato alcun RoleBinding Kubernetes nei cluster TKGS in tale Spazio dei nomi vSphere. Questo perché in Kubernetes non esiste alcun ruolo di sola lettura equivalente a cui un utente o un gruppo a cui viene concessa l'autorizzazione Può visualizzare possa essere associato. Per concedere l'accesso agli utenti diversi da cluster-admin, è possibile utilizzare RBAC di Kubernetes. Vedere Come concedere agli sviluppatori l'accesso SSO di vCenter ai cluster Servizio TKG.

Un utente o un gruppo a cui è stata concessa l'autorizzazione del ruolo Proprietario in uno Spazio dei nomi vSphere può amministrare i cluster Servizio TKG in tale Spazio dei nomi vSphere, nonché creare ed eliminare ulteriori Spazi dei nomi vSphere utilizzando kubectl. Quando si assegna un utente/gruppo al ruolo di proprietario, il sistema crea un ClusterRoleBinding e lo mappa a un ClusterRole che consente all'utente/gruppo di creare ed eliminare Spazi dei nomi vSphere utilizzando kubectl. Non è possibile visualizzare questa mappatura utilizzando lo stesso approccio. Per visualizzare questa mappatura, è necessario accedere tramite SSH a un nodo Supervisore.
Nota: Il ruolo Proprietario è supportato per gli utenti provenienti dall'origine dell'identità vCenter Single Sign-On. Non è possibile utilizzare il ruolo Proprietario con un utente/gruppo da provider di identità esterno.

Autorizzazioni di vSphere

La tabella mostra i tipi di autorizzazioni di vSphere necessarie per varie personalità vSphere IaaS control plane. Se necessario, è possibile creare un ruolo e un gruppo SSO di vSphere personalizzati per la gestione del carico di lavoro. Vedere Creazione di un gruppo e un ruolo dedicati per gli operatori della piattaforma.

Tabella 1. Autorizzazioni di vSphere per personalità vSphere with Tanzu
Identità Ruolo vSphere Gruppo SSO vSphere Spazio dei nomi di vSphere
Amministratore di VI/Cloud Amministratore Administrators Utente SSO e/o Utente AD
Operatore DevOps/Piattaforma Ruolo non amministratore o personalizzato ServiceProviderUsers Utente SSO e/o Utente AD
Sviluppatore Sola lettura o Nessuno Nessuno Utente SSO e/o Utente AD

Connettività dell'amministratore di sistema

Gli amministratori possono connettersi ai nodi del cluster Servizio TKG come utente kubernetes-admin. Questo metodo potrebbe essere appropriato se non è disponibile l'autenticazione vCenter Single Sign-On. Per la risoluzione dei problemi, gli amministratori di sistema possono connettersi a un Servizio TKG come vmware-system-user utilizzando SSH e una chiave privata. Vedere Connessione ai cluster Servizio TKG come amministratore di Kubernetes e utente di sistema.