Configurazione della gestione delle identità

Questo argomento spiega come abilitare e configurare la gestione delle identità in Tanzu Kubernetes Grid (TKG) con un cluster di gestione autonomo.

Informazioni sull'abilitazione e la configurazione della gestione delle identità

È possibile abilitare la gestione delle identità durante o dopo la distribuzione del cluster di gestione configurando un provider di identità LDAPS o OIDC. Tutti i cluster del carico di lavoro creati dopo l'abilitazione della gestione delle identità vengono configurati automaticamente per l'utilizzo dello stesso provider di identità del cluster di gestione. Per configurare retroattivamente i cluster del carico di lavoro esistenti con la gestione delle identità appena abilitata, seguire le indicazioni di Abilitazione della gestione delle identità nei cluster del carico di lavoro.

L'abilitazione e la configurazione della gestione delle identità prevede i passaggi seguenti. Se si desidera utilizzare file kubeconfig standard non di amministrazione per l'accesso ai cluster di gestione e del carico di lavoro, dopo aver completato i passaggi di questo argomento, è inoltre necessario configurare il controllo degli accessi basato sui ruoli (RBAC) seguendo le istruzioni di Configurazione di RBAC.

(Opzione consigliata) Abilitazione e configurazione della gestione delle identità durante la distribuzione del cluster di gestione:

Recuperare i dettagli del provider di identità.
Utilizzare i dettagli ottenuti per configurare LDAPS o OIDC in Tanzu Kubernetes Grid.
Dopo aver creato il cluster di gestione, verificare che il servizio di autenticazione venga eseguito correttamente e completarne la configurazione.

Per istruzioni, vedere (Opzione consigliata) Abilitazione e configurazione della gestione delle identità durante la distribuzione del cluster di gestione di seguito.

Abilitazione e configurazione della gestione delle identità dopo la distribuzione del cluster di gestione:

Recuperare i dettagli del provider di identità.
Generare il segreto del componente aggiuntivo Pinniped per il cluster di gestione.
Verificare che il servizio di autenticazione venga eseguito correttamente e completarne la configurazione.
Se il cluster di gestione gestisce cluster del carico di lavoro, generare il segreto del componente aggiuntivo Pinniped per ogni cluster del carico di lavoro creato prima di abilitare la gestione delle identità.

Per istruzioni, vedere Abilitazione e configurazione della gestione delle identità in una distribuzione esistente di seguito.

(Opzione consigliata) Abilitazione e configurazione della gestione delle identità durante la distribuzione del cluster di gestione

Questa sezione spiega come abilitare e configurare la gestione delle identità durante la distribuzione del cluster di gestione.

Recupero dei dettagli del provider di identità

Per poter abilitare la gestione delle identità, è necessario disporre di un provider di identità. Tanzu Kubernetes Grid supporta i provider di identità LDAPS e OIDC.

Per utilizzare il server LDAPS interno della propria azienda come provider di identità, recuperare le informazioni relative a LDAPS dall'amministratore di LDAP.
Per utilizzare OIDC come provider di identità, è necessario disporre di un account con un provider di identità che supporti lo standard OpenID Connect, ad esempio Okta.

Esempio: registrazione di un'applicazione di Tanzu Kubernetes Grid in Okta

Per utilizzare Okta come provider OIDC, è necessario creare un account con Okta e registrare un'applicazione per Tanzu Kubernetes Grid con l'account:

Se non si dispone di un account Okta, crearne uno.
Passare al portale di amministrazione facendo clic sul pulsante Amministrazione (Admin).
Passare ad Applicazioni (Applications) e fare clic su Crea integrazione app (Create App Integration).
Per Metodo di accesso (Sign-in method), selezionare OIDC - OpenID Connect e per Tipo di applicazione (Application type) selezionare Applicazione Web (Web Application) e quindi fare clic su Avanti (Next).
Specificare un nome per l'applicazione.
In Tipo di concessione (Grant Type), in Client che agiscono per conto di un utente (Client acting on behalf of a user), assicurarsi che siano selezionati sia Codice autorizzazione (Authorization Code) sia Token di aggiornamento (Refresh Token).
Immettere un segnaposto URI di reindirizzamento accesso (Sign-in redirect URI). Ad esempio, digitare http://localhost:8080/authorization-code/callback. Dopo aver distribuito il cluster di gestione, aggiornare questo campo inserendo l'URL effettivo.
In Assegnazioni (Assignments) assegnare persone e gruppi all'applicazione. Le persone e i gruppi assegnati all'applicazione saranno gli utenti che possono accedere al cluster di gestione e ai cluster del carico di lavoro che vengono distribuiti tramite il cluster di gestione.
Fare clic su Salva (Save).
Nella scheda Generale (General) dell'applicazione, copiare e salvare ID client (Client ID) e Segreto client (Client secret). Queste credenziali saranno necessarie quando si distribuisce il cluster di gestione.

Importante
Tutti i provider OIDC devono essere configurati per emettere token di aggiornamento per utilizzare TKG 2.3 o versione successiva.

Configurazione delle impostazioni LDAPS o OIDC in Tanzu Kubernetes Grid

Utilizzare i dettagli ottenuti in precedenza per configurare LDAPS o OIDC in Tanzu Kubernetes Grid:

Se si distribuisce il cluster di gestione utilizzando l'interfaccia del programma di installazione, configurare LDAPS o OIDC nella sezione Gestione identità (Identity Management). Per istruzioni, vedere Configurazione della gestione delle identità in Distribuzione dei cluster di gestione con l'interfaccia del programma di installazione.

Se si distribuisce il cluster di gestione da un file di configurazione, impostare le variabili LDAP_* o OIDC_* nel file di configurazione.

Ad esempio:

LDAP:

IDENTITY_MANAGEMENT_TYPE: ldap
LDAP_BIND_DN: "cn=bind-user,ou=people,dc=example,dc=com"
LDAP_BIND_PASSWORD: "example-password"
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: &(objectClass=posixGroup)(memberUid={})
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: uid
LDAP_HOST: ldaps.example.com:636
LDAP_ROOT_CA_DATA_B64: ""
LDAP_USER_SEARCH_BASE_DN: ou=people,dc=example,dc=com
LDAP_USER_SEARCH_FILTER: &(objectClass=posixAccount)(uid={})
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid

OIDC:

IDENTITY_MANAGEMENT_TYPE: oidc
OIDC_IDENTITY_PROVIDER_CLIENT_ID: 0oa2i[...]NKst4x7
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: 331!b70[...]60c_a10-72b4
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: groups
OIDC_IDENTITY_PROVIDER_ISSUER_URL: https://dev-[...].okta.com
OIDC_IDENTITY_PROVIDER_SCOPES: openid,groups,email,offline_access
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: email

Per istruzioni su come preparare un file di configurazione del cluster di gestione, vedere Creazione di un file di configurazione del cluster di gestione.

Completamento della configurazione della gestione delle identità

Dopo aver distribuito il cluster di gestione, completare la configurazione della gestione delle identità eseguendo le procedure descritte nelle sezioni seguenti:

Connettere kubectl al cluster di gestione.
Verificare che il servizio di autenticazione sia correttamente in esecuzione controllandone lo stato, come descritto in Controllo dello stato del servizio gestione delle identità.
(Solo OIDC) Specifica dell'URI di callback per il provider OIDC.
Per supportare l'utilizzo di file kubeconfig standard non di amministrazione per accedere al cluster di gestione, vedere Configurazione di RBAC per un cluster di gestione.

Connessione di `kubectl` al cluster di gestione

Per configurare la gestione delle identità, è necessario recuperare e utilizzare il contesto admin del cluster di gestione:

Recuperare il contesto admin del cluster di gestione. Le procedure descritte in questo argomento utilizzano un cluster di gestione denominato id-mgmt-test.
```
tanzu mc kubeconfig get id-mgmt-test --admin
```
Se il cluster di gestione è denominato id-mgmt-test, verrà visualizzata la conferma Credentials of workload cluster 'id-mgmt-test' have been saved. You can now access the cluster by running 'kubectl config use-context id-mgmt-test-admin@id-mgmt-test'. Il contesto admin di un cluster fornisce l'accesso completo al cluster senza richiedere l'autenticazione con il provider di identità.

Impostare kubectl sul contesto admin del cluster di gestione:

kubectl config use-context id-mgmt-test-admin@id-mgmt-test

Controllo dello stato del servizio di gestione delle identità

Tanzu Kubernetes Grid utilizza Pinniped per integrare i cluster con i provider di identità OIDC e LDAP. Quando si abilita la gestione dell'identità, Tanzu Kubernetes Grid crea il servizio pinniped-supervisor nello spazio dei nomi pinniped-supervisor e pinniped-concierge nello spazio dei nomi pinniped-concierge. Eseguire i passaggi seguenti per controllare lo stato del servizio Pinniped e prendere nota dell'indirizzo EXTERNAL-IP in cui il servizio è esposto.

Recuperare informazioni sui servizi in esecuzione nel cluster di gestione. Il servizio di gestione delle identità viene eseguito nello spazio dei nomi pinniped-supervisor:

kubectl get services -n pinniped-supervisor

L'output contiene la voce seguente:

vSphere con NSX Advanced Load Balancer (ALB):

NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/pinniped-supervisor   LoadBalancer   100.70.70.12   20.52.230.18   5556:31234/TCP   84m

Amazon Web Services (AWS):

NAME                          TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.13.66   ab1[...]71.eu-west-1.elb.amazonaws.com   443:30865/TCP   56m

Azure:

NAME                          TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)         AGE
service/pinniped-supervisor   LoadBalancer   100.69.169.220   20.54.226.44     443:30451/TCP   84m

vSphere senza NSX ALB:

NAME                          TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
service/pinniped-supervisor   NodePort   100.70.70.12   <none>        5556:31234/TCP   84m

Prendere nota delle informazioni seguenti:
- vSphere con NSX ALB, AWS e Azure: prendere nota dell'indirizzo esterno del servizio pinniped-supervisor indicato in EXTERNAL-IP.
- vSphere senza NSX ALB: prendere nota della porta in cui è in esecuzione il servizio pinniped-supervisor. Nell'esempio precedente, questa porta è 31234.
Verificare che tutti i servizi nel cluster di gestione siano in esecuzione.
```
kubectl get pods -A
```
Prima che sia possibile eseguire il servizio Pinniped, è necessario attendere diversi minuti. Ad esempio, nelle distribuzioni di AWS e Azure, il servizio deve attendere che gli indirizzi IP di LoadBalancer siano pronti. Attendere il completamento di pinniped-post-deploy-job prima di procedere con i passaggi successivi.
```
NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
```

Nota
È possibile eseguire kubectl get pods perché si sta utilizzando il contesto admin per il cluster di gestione. Gli utenti che tentano di connettersi al cluster di gestione con il contesto regolare non saranno in grado di accedere alle relative risorse perché non dispongono ancora delle autorizzazioni necessarie per eseguire questa operazione.

Controllo dello stato di un servizio di gestione delle identità LDAP

Tanzu Kubernetes Grid utilizza Pinniped per integrare i cluster con un servizio di identità LDAP per esporre l'endpoint del servizio. Quando si abilita LDAP, Tanzu Kubernetes Grid crea il servizio pinniped-supervisor nello spazio dei nomi pinniped-supervisor e il servizio pinniped-concierge nello spazio dei nomi pinniped-concierge.

Verificare che tutti i servizi nel cluster di gestione siano in esecuzione:
```
kubectl get services -A
```
Prima che sia possibile eseguire il servizio Pinniped, è necessario attendere diversi minuti. Ad esempio, nelle distribuzioni di AWS e Azure, il servizio deve attendere che gli indirizzi IP di LoadBalancer siano pronti. Attendere il completamento di pinniped-post-deploy-job prima di procedere con i passaggi successivi.
```
NAMESPACE             NAME                                   READY  STATUS      RESTARTS  AGE
[...]
pinniped-supervisor   pinniped-post-deploy-job-hq8fc         0/1    Completed   0         85m
```
Nota
È possibile eseguire kubectl get pods perché si sta utilizzando il contesto admin per il cluster di gestione. Gli utenti che tentano di connettersi al cluster di gestione con il contesto regolare non saranno in grado di accedere alle relative risorse perché non dispongono ancora delle autorizzazioni necessarie per eseguire questa operazione.
Passare a Configurazione di RBAC per il cluster di gestione.

(Solo OIDC) Specifica dell'URI di callback per il provider OIDC

Se il cluster di gestione è stato configurato per l'utilizzo dell'autenticazione OIDC, è necessario specificare l'URI di callback per tale cluster di gestione per il provider di identità OIDC. Ad esempio, se si utilizza OIDC e il provider di identità è Okta, eseguire i passaggi seguenti:

Accedere all'account Okta.
Nel menu principale, passare ad Applicazioni (Applications).
Selezionare l'applicazione creata per Tanzu Kubernetes Grid.
Nel pannello Impostazioni generali (General Settings), fare clic su Modifica (Edit).
In Accesso (Login) aggiornare URI di reindirizzamento accesso (Login redirect URIs) per includere l'indirizzo del nodo in cui pinniped-supervisor è in esecuzione:
- vSphere con NSX ALB, AWS e Azure: aggiungere l'indirizzo IP esterno e il numero di porta del servizio pinniped-supervisor annotati nella procedura precedente:
```
https://EXTERNAL-IP/callback
```
- vSphere senza NSX ALB: aggiungere l'indirizzo IP impostato come endpoint dell'API e il numero di porta di pinniped-supervisor annotati nella procedura precedente:
```
https://API-ENDPOINT-IP:31234/callback
```
  In tutti i casi, è necessario specificare https, non http.
Fare clic su Salva (Save).

Configurazione di RBAC per il cluster di gestione

Se si intende utilizzare file kubeconfig standard non di amministrazione per l'accesso al cluster di gestione, dopo aver completato la configurazione della gestione delle identità, configurare RBAC seguendo le istruzioni di Configurazione di RBAC per un cluster di gestione.

Abilitazione e configurazione della gestione delle identità in una distribuzione esistente

Questa sezione spiega come abilitare e configurare la gestione delle identità in una distribuzione esistente.

Recupero dei dettagli del provider di identità

Seguire le istruzioni della sezione Recupero dei dettagli del provider di identità precedente.

Generazione del segreto del componente aggiuntivo Pinniped per il cluster di gestione

Questa procedura consente di configurare il componente aggiuntivo Pinniped e distribuire i componenti di autenticazione nel cluster di gestione. Per generare un segreto Kubernetes per il componente aggiuntivo Pinniped:

Impostare il contesto di kubectl sul cluster di gestione. Ad esempio, con un cluster di gestione denominato id-mgmt-test:
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```

Creare un file di configurazione del cluster copiando le impostazioni di configurazione definite durante la distribuzione del cluster di gestione in un nuovo file. Aggiungere le impostazioni seguenti nel file di configurazione del cluster di gestione, inclusi i dettagli del provider di identità OIDC o LDAP:

Nota
È necessario impostare queste variabili solo per i cluster di gestione.

# Identity management type. This must be "oidc" or "ldap".

IDENTITY_MANAGEMENT_TYPE:

# Explicitly set the namespace, which for management clusters is "tkg-system".

NAMESPACE: tkg-system

# Set these variables if you want to configure OIDC.

OIDC_IDENTITY_PROVIDER_CLIENT_ID:
OIDC_IDENTITY_PROVIDER_CLIENT_SECRET:
OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM:
OIDC_IDENTITY_PROVIDER_ISSUER_URL:
OIDC_IDENTITY_PROVIDER_SCOPES: "email,profile,groups,offline_access"
OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM:

# Set these variables if you want to configure LDAP.

LDAP_BIND_DN:
LDAP_BIND_PASSWORD:
LDAP_GROUP_SEARCH_BASE_DN:
LDAP_GROUP_SEARCH_FILTER:
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: dn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: dn
LDAP_HOST:
LDAP_ROOT_CA_DATA_B64:
LDAP_USER_SEARCH_BASE_DN:
LDAP_USER_SEARCH_FILTER:
LDAP_USER_SEARCH_ID_ATTRIBUTE: dn
LDAP_USER_SEARCH_NAME_ATTRIBUTE:

# Set these variables if you want to configure certificate duration

CERT_DURATION: 2160h
CERT_RENEW_BEFORE: 360h

Per sapere quali di queste variabili sono facoltative e possono essere omesse, passare a Variabili per la configurazione dei provider di identità - OIDC e Variabili per la configurazione dei provider di identità - LDAP.

Se il cluster di gestione si trova dietro un proxy, assicurarsi che il nuovo file di configurazione includa i dettagli della configurazione del proxy:

TKG_HTTP_PROXY:
TKG_HTTPS_PROXY:
TKG_NO_PROXY:

Per ulteriori informazioni su questi variabili, vedere Configurazione del proxy.

vSphere: modificare la configurazione di VSPHERE_CONTROL_PLANE_ENDPOINT impostandola su un indirizzo IP inutilizzato come valore fittizio per superare i controlli interni.

Assicurarsi che nell'ambiente locale la variabile IDENTITY_MANAGEMENT_TYPE sia impostata su oidc o ldap e non su none:
```
echo $IDENTITY_MANAGEMENT_TYPE
```
Se questa variabile è impostata su none, eseguire un comando export per impostarla nuovamente su oidc o ldap.
Impostare la variabile di ambiente FILTER_BY_ADDON_TYPE su authentication/pinniped in modo che tanzu management-cluster create funzioni solo per gli oggetti correlati a Pinniped:
```
export FILTER_BY_ADDON_TYPE="authentication/pinniped"
```
Generare un segreto per il componente aggiuntivo Pinniped:
```
tanzu management-cluster create CLUSTER-NAME --dry-run -f CLUSTER-CONFIG-FILE > CLUSTER-NAME-example-secret.yaml
```
In cui:
- CLUSTER-NAME è il nome del cluster di gestione di destinazione.
- CLUSTER-CONFIG-FILE è il file di configurazione creato in precedenza.
Le impostazioni delle variabili di ambiente fanno in modo che tanzu management-cluster create --dry-run generi un segreto Kubernetes, non un manifesto del cluster completo.
Controllare il segreto e quindi applicarlo al cluster di gestione. Ad esempio:
```
kubectl apply -f CLUSTER-NAME-example-secret.yaml
```

Dopo aver applicato il segreto, controllare lo stato del componente aggiuntivo Pinniped eseguendo il comando kubectl get app:

$ kubectl get app CLUSTER-NAME-pinniped -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
pinniped       Reconcile succeeded     3m23s           7h50m

Se lo stato restituito è Reconcile failed, eseguire il comando seguente per visualizzare i dettagli dell'errore:

kubectl get app CLUSTER-NAME-pinniped -n tkg-system -o yaml

Completamento della configurazione della gestione delle identità

Seguire le istruzioni della sezione Completamento della configurazione della gestione delle identità precedente.

Abilitazione della gestione delle identità nei cluster del carico di lavoro

Tutti i cluster del carico di lavoro creati dopo aver abilitato la gestione delle identità nel cluster di gestione vengono configurati automaticamente per l'utilizzo dello stesso servizio di gestione delle identità.

Autenticazione degli utenti in una macchina senza browser

Se la macchina di bootstrap è una jumpbox o un'altra macchina senza monitor, è possibile eseguire l'autenticazione in un cluster da un browser in esecuzione nella macchina locale. La modalità di esecuzione di questa operazione dipende dalla versione di Pinniped del cluster, che deriva dalla versione di Tanzu Kubernetes su cui il cluster è basato:

Versione di TKr del cluster	Procedura di autenticazione senza browser
TKr v1.23.10 (predefinita per Tanzu Kubernetes Grid v1.6.1) o versioni successive	Seguire le istruzioni disponibili di seguito
Cluster basati su TKr precedenti o creati da versioni precedenti di Tanzu Kubernetes Grid	Seguire la procedura indicata in Autenticazione di utenti in una macchina senza browser nella documentazione di Tanzu Kubernetes Grid v1.4

Nota
Tanzu Kubernetes Grid v2.3 non supporta l'accesso alla CLI senza browser basato su account non interattivi o concessioni di password.

Da una finestra terminale nella macchina locale, eseguire ssh per accedere in remoto alla macchina di bootstrap.
Impostare la variabile di ambiente TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true. In questo modo viene aggiunta l'opzione --skip-browser al file kubeconfig per il cluster.
```
# Linux
export TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
# Windows
set TANZU_CLI_PINNIPED_AUTH_LOGIN_SKIP_BROWSER=true
```
Esportare il file kubeconfig standard per il cluster in un file locale. Si tenga presente che il comando non include l'opzione --admin, quindi il file kubeconfig esportato è il file kubeconfig standard, non la versione admin. Ad esempio, per esportare il file kubeconfig in /tmp/my-cluster-kubeconfig:
- Per un cluster di gestione, eseguire:
```
tanzu mc kubeconfig get --export-file /tmp/my-cluster-kubeconfig
```
  Viene visualizzata la conferma You can now access the cluster by specifying '--kubeconfig /tmp/my-mgmt-cluster-kubeconfig' flag when using 'kubectl' command.
- Per un cluster del carico di lavoro, eseguire:
```
tanzu cluster kubeconfig get my-cluster --export-file /tmp/my-cluster-kubeconfig
```

Connettersi al cluster utilizzando il file kubeconfig appena creato:

kubectl get pods -A --kubeconfig /tmp/my-cluster-kubeconfig

La CLI genera un collegamento di accesso per il provider di identità. Ad esempio:

Log in by visiting this link:

   https://10.180.105.166:31234/oauth2/authorize?access_type=offline&client_id=pinniped-cli&code_challenge=-aJ617vJZXZeEnHPab1V2_VHPmc5VwspFig5QQKyTwg&code_challenge_method=S256&nonce=cafaf8f4d2cb714ef8fb3320c1b088ba&redirect_uri=http%3A%2F%2F127.0.0.1%3A33087%2Fcallback&response_mode=form_post&response_type=code&scope=offline_access+openid+pinniped%3Arequest-audience&state=fff3d4d46b36359d5ba2f24fad471dd8

   Optionally, paste your authorization code:

Copiare il collegamento e incollarlo in un browser nella macchina locale.
Nel browser, accedere al provider di identità. Viene visualizzata una pagina che richiede di incollare un codice di autorizzazione nella CLI:
Copiare il codice di autorizzazione e incollarlo nella CLI, dopo il prompt Optionally, paste your authorization code:.
Connettersi nuovamente al cluster utilizzando lo stesso file kubeconfig usato in precedenza:
```
kubectl get pods -A --kubeconfig FILE-PATH
```
- Se nel cluster è già stato configurato un binding del ruolo per l'utente autenticato, l'output include le informazioni del pod.
- Se nel cluster non è stato configurato un binding del ruolo, verrà visualizzato un messaggio che nega l'accesso dell'account utente ai pod: Error from server (Forbidden): pods is forbidden: User "[email protected]" cannot list resource "pods" in API group "" at the cluster scope. Questo errore si verifica perché l'utente è stato autenticato correttamente, ma non è ancora autorizzato ad accedere alle risorse nel cluster. Per autorizzare l'utente ad accedere alle risorse del cluster, è necessario configurare RBAC nel cluster creando un binding del ruolo del cluster:
  - Vedere Creazione di un binding del ruolo nel cluster di gestione.
  - Vedere Creazione di un binding del ruolo in un cluster del carico di lavoro.

Disattivazione della gestione delle identità in una distribuzione esistente

Per disattivare la gestione delle identità in una distribuzione esistente in cui la gestione delle identità è abilitata:

Impostare il contesto di kubectl sul cluster di gestione. Ad esempio, con un cluster di gestione denominato id-mgmt-test:
```
kubectl config use-context id-mgmt-test-admin@id-mgmt-test
```
Recuperare il file di configurazione del cluster di gestione e modificarlo per impostare IDENTITY_MANAGEMENT_TYPE: none.
Generare una definizione di segreto di Pinniped eseguendo tanzu management-cluster create con --dry-run e filtrando per gli oggetti correlati a Pinniped.
```
FILTER_BY_ADDON_TYPE=authentication/pinniped tanzu management-cluster create --dry-run CLUSTER-CONFIG > PINNIPED-SECRET
```
In cui CLUSTER-CONFIG è il file di configurazione del cluster e PINNIPED-SECRET è la definizione di Secret di Pinniped generata, ad esempio mc-no-idp.yaml.
Applicare il nuovo segreto per disattivare Pinniped nel cluster di gestione:
```
kubectl apply -f PINNIPED-SECRET
```
Dopo aver disattivato Pinniped nel cluster di gestione, i relativi cluster basati sulla classe vengono disattivati automaticamente, ma è necessario disattivare manualmente i cluster legacy:
1. Elencare tutti i segreti di Pinniped rimanenti nel contesto del cluster di gestione:
```
kubectl get secret -A | grep pinniped-addon
```
2. Analizzare i segreti nell'output kubectl get secret, se presenti, utilizzando il nome e lo spazio dei nomi del segreto indicati:
```
kubectl get secret SECRET-NAME -n SECRET-NAMESPACE -o yaml
```
3. Eliminare i segreti che contengono:
  - type: tkg.tanzu.vmware.com/addon: si tratta di segreti di cluster legacy
  - qualsiasi configurazione OIDC o LDAP
```
kubectl delete secret SECRET-NAME
```
  In cui SECRET-NAME è il valore di metadata.name impostato nella specifica Secret.

Passaggi successivi

Se si intende utilizzare file kubeconfig standard non di amministrazione per consentire agli utenti di accedere ai cluster di gestione e del carico di lavoro, è necessario configurare l'autorizzazione RBAC:

Per configurare RBAC per il cluster di gestione, seguire le istruzioni di Configurazione di RBAC per un cluster di gestione.
Dopo aver completato i passaggi descritti in questo argomento, è possibile iniziare a creare cluster del carico di lavoro. Per configurare RBAC per i cluster del carico di lavoro, seguire le istruzioni di Configurazione di RBAC per un cluster del carico di lavoro.

Configurazione della gestione delle identità

Informazioni sull'abilitazione e la configurazione della gestione delle identità

(Opzione consigliata) Abilitazione e configurazione della gestione delle identità durante la distribuzione del cluster di gestione

Recupero dei dettagli del provider di identità

Esempio: registrazione di un'applicazione di Tanzu Kubernetes Grid in Okta

Configurazione delle impostazioni LDAPS o OIDC in Tanzu Kubernetes Grid

Completamento della configurazione della gestione delle identità

Connessione di kubectl al cluster di gestione

Controllo dello stato del servizio di gestione delle identità

Controllo dello stato di un servizio di gestione delle identità LDAP

(Solo OIDC) Specifica dell'URI di callback per il provider OIDC

Configurazione di RBAC per il cluster di gestione

Abilitazione e configurazione della gestione delle identità in una distribuzione esistente

Recupero dei dettagli del provider di identità

Generazione del segreto del componente aggiuntivo Pinniped per il cluster di gestione

Completamento della configurazione della gestione delle identità

Abilitazione della gestione delle identità nei cluster del carico di lavoro

Autenticazione degli utenti in una macchina senza browser

Disattivazione della gestione delle identità in una distribuzione esistente

Passaggi successivi

Connessione di `kubectl` al cluster di gestione