This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

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:

  1. Recuperare i dettagli del provider di identità.
  2. Utilizzare i dettagli ottenuti per configurare LDAPS o OIDC in Tanzu Kubernetes Grid.
  3. 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:

  1. Recuperare i dettagli del provider di identità.
  2. Generare il segreto del componente aggiuntivo Pinniped per il cluster di gestione.
  3. Verificare che il servizio di autenticazione venga eseguito correttamente e completarne la configurazione.
  4. 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:

  1. Se non si dispone di un account Okta, crearne uno.
  2. Passare al portale di amministrazione facendo clic sul pulsante Amministrazione (Admin).
  3. Passare ad Applicazioni (Applications) e fare clic su Aggiungi applicazione (Add Application).
  4. Fare clic su Crea nuova app.
  5. In Piattaforma (Platform) selezionare Web e in Metodo di accesso (Sign on method) selezionare OpenID Connect, quindi fare clic su Crea (Create).
  6. Specificare un nome per l'applicazione.
  7. Immettere un segnaposto URI di reindirizzamento accesso (Login redirect URI). Ad esempio, digitare http://localhost:8080/callback. Dopo aver distribuito il cluster di gestione, aggiornare questo campo inserendo l'URL effettivo.
  8. Fare clic su Salva (Save).
  9. 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.
  10. Nella scheda 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.

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: ""
LDAP_BIND_PASSWORD: ""
LDAP_GROUP_SEARCH_BASE_DN: dc=example,dc=com
LDAP_GROUP_SEARCH_FILTER: (objectClass=posixGroup)
LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: 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)
LDAP_USER_SEARCH_NAME_ATTRIBUTE: uid
LDAP_USER_SEARCH_USERNAME: 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
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.

Nota

I pod Dex devono essere ruotati manualmente ogni volta che il certificato TLS Dex scade (90 giorni per impostazione predefinita). È possibile aumentare la durata del certificato utilizzando CERT_DURATION. Per riavviare i pod di Dex, eseguire kubectl rollout restart deployments/dex -n tanzu-system-auth.

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:

  1. Connettere kubectl al cluster di gestione.
  2. Verificare che il servizio di autenticazione venga eseguito correttamente controllandone lo stato:
  3. OIDC: specificare l'URI di callback per il provider OIDC.
  4. 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:

  1. 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à.

  2. Impostare kubectl sul contesto admin del cluster di gestione:

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

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

Tanzu Kubernetes Grid utilizza Pinniped per integrare i cluster con un servizio di identità OIDC. Quando si abilita OIDC, 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.

  1. 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 all -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

  2. 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.

  3. 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 insieme a Dex per esporre l'endpoint del servizio. Quando si abilita LDAP, Tanzu Kubernetes Grid crea il servizio pinniped-supervisor nello spazio dei nomi pinniped-supervisor, pinniped-concierge nello spazio dei nomi pinniped-concierge e dexsvc nello spazio dei nomi tanzu-system-auth. Eseguire i passaggi seguenti per controllare lo stato di un servizio LDAP e prendere nota dell'indirizzo EXTERNAL-IP in cui il servizio è esposto.

  1. Recuperare informazioni sui servizi in esecuzione nel cluster di gestione nello spazio dei nomi tanzu-system-auth:

    kubectl get all -n tanzu-system-auth

    L'output contiene la voce seguente:

    vSphere con NSX ALB:

    NAME             TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)          AGE
service/dexsvc   LoadBalancer   100.70.70.12   20.52.230.18   443:30167/TCP   84m

    AWS:

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP                              PORT(S)         AGE
service/dexsvc   LoadBalancer   100.65.184.107   a6e[...]74.eu-west-1.elb.amazonaws.com   443:32547/TCP   84m

    Azure:

    NAME             TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)         AGE
service/dexsvc   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/dexsvc   NodePort   100.70.70.12   <none>        5556:30167/TCP   84m

  2. 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.

  3. 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:

  1. Accedere all'account Okta.
  2. Nel menu principale, passare ad Applicazioni (Applications).
  3. Selezionare l'applicazione creata per Tanzu Kubernetes Grid.
  4. Nel pannello Impostazioni generali (General Settings), fare clic su Modifica (Edit).

  5. 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.

  6. 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:

  1. 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

  2. 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"
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_GROUP_ATTRIBUTE:
LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn
LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN
LDAP_HOST:
LDAP_ROOT_CA_DATA_B64:
LDAP_USER_SEARCH_BASE_DN:
LDAP_USER_SEARCH_EMAIL_ATTRIBUTE: DN
LDAP_USER_SEARCH_FILTER:
LDAP_USER_SEARCH_ID_ATTRIBUTE: DN
LDAP_USER_SEARCH_NAME_ATTRIBUTE:
LDAP_USER_SEARCH_USERNAME: userPrincipalName

# 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.

  3. 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.

  4. Impostare la variabile di ambiente _TKG_CLUSTER_FORCE_ROLE su management:

    export _TKG_CLUSTER_FORCE_ROLE="management"

    In Windows, utilizzare il comando SET.

  5. Impostare la variabile di ambiente FILTER_BY_ADDON_TYPE su authentication/pinniped in modo che tanzu cluster create funzioni solo per gli oggetti correlati a Pinniped:

    export FILTER_BY_ADDON_TYPE="authentication/pinniped"

  6. Generare un segreto per il componente aggiuntivo Pinniped:

    tanzu 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 cluster create --dry-run generi un segreto Kubernetes, non un manifesto del cluster completo.

  7. Controllare il segreto e quindi applicarlo al cluster di gestione. Ad esempio:

    kubectl apply -f CLUSTER-NAME-example-secret.yaml

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

    $ kubectl get app 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 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.1 non supporta l'accesso alla CLI senza browser basato su account non interattivi o concessioni di password.

  1. Da una finestra terminale nella macchina locale, eseguire ssh per accedere in remoto alla macchina di bootstrap.

  2. 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

  3. 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

  4. 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:

  5. Copiare il collegamento e incollarlo in un browser nella macchina locale.

  6. Nel browser, accedere al provider di identità. Viene visualizzata una pagina che richiede di incollare un codice di autorizzazione nella CLI:

    Completamento dell'accesso

  7. Copiare il codice di autorizzazione e incollarlo nella CLI, dopo il prompt Optionally, paste your authorization code:.

  8. 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:

Aggiornamento delle impostazioni Dex dopo la distribuzione del cluster di gestione

Il componente Pinniped utilizza Dex per i provider di identità LDAP. Per i provider di identità OIDC, Dex non viene utilizzato.

Se si desidera aggiornare un'impostazione che inizia con dex. nella sezione values.yaml del segreto di Pinniped per il cluster di gestione, è necessario eseguire i passaggi seguenti:

  1. Identificare l'impostazione o le impostazioni dex. che si desidera aggiornare. Vedere la tabella in Aggiornamento della sezione values.yaml.
  2. Recuperare il segreto di Pinniped per il cluster di gestione come descritto in Aggiornamento della sezione values.yaml.

  3. Nel segreto di Pinniped aggiornare l'impostazione o le impostazioni dex. identificate in precedenza ed eseguire i passaggi seguenti:

    1. Specificare le impostazioni di configurazione dell'array dex.dns.INFRASTRUCTURE-PROVIDER.ipAddresses e dex.config.dns.INFRASTRUCTURE-PROVIDER.dnsNames. Questi campi possono essere impostati su array con una voce singola qualsiasi non vuota, ad esempio 0.0.0.0, perché vengono aggiornati automaticamente.
    2. Per l'impostazione di configurazione di pinniped.upstream_oidc_issuer_url specificare una stringa non vuota che inizia con https. Ad esempio, https://0.0.0.0. Questo campo viene aggiornato automaticamente in un secondo momento.
    3. Fare in modo che l'impostazione di configurazione dell'array dex.config.staticClients disponga di una voce singola. Questa impostazione può essere qualsiasi mappa che includa almeno le chiavi name, id e secret, ad esempio {name: "example-name", id: "example-id", secret: "example-secret"}, perché viene aggiornata automaticamente.

    4. Aggiungere il seguente overlay al segreto di Pinniped:

      #@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"metadata": {"name" : "upstream-oidc-identity-provider"}})
---
metadata:
  annotations:
    #@overlay/remove
    kapp.k14s.io/update-strategy: always-replace

  4. Applicare il segreto di Pinniped.

  5. Riavviare lo spazio dei nomi tanzu-system-auth nel cluster di gestione dopo aver applicato il segreto di Pinniped. Per riavviare lo spazio dei nomi, è possibile eliminare Namespace e attendere che l'App pinniped lo ricrei. Dopo aver applicato il segreto di Pinniped, potrebbe essere necessario riavviare il Job pinniped-post-deploy-job in Namespace di pinniped-supervisor. A tale scopo, è possibile eliminare il Job e attendere che l'App pinniped lo ricrei.

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:

  1. 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

  2. Recuperare il file di configurazione del cluster di gestione e modificarlo per impostare IDENTITY_MANAGEMENT_TYPE: none.

  3. 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.

  4. Applicare il nuovo segreto per disattivare Pinniped nel cluster di gestione:

    kubectl apply -f PINNIPED-SECRET

  5. 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:

check-circle-line exclamation-circle-line close-line
Scroll to top icon