Accedere ai progetti

Questa pagina illustra come accedere e gestire i carichi di lavoro e le risorse in Google Distributed Cloud (GDC) air-gapped. Descrive come eseguire l'autenticazione, generare file kubeconfig per le risorse zonali e globali e gestire l'inattività della sessione. La comprensione di questi processi garantisce un accesso sicuro e affidabile ai progetti e ai carichi di lavoro.

Questa pagina è rivolta al pubblico all'interno del gruppo di amministratori della piattaforma (ad esempio amministratori IT) o del gruppo di operatori dell'applicazione (ad esempio sviluppatori di applicazioni) che vogliono utilizzare le risorse GDC. Per saperne di più, consulta la sezione Pubblico per la documentazione di GDC con air gap.

Puoi accedere ai carichi di lavoro utilizzando la console GDC, gdcloud CLI o kubectl CLI.

Autenticare l'account per l'accesso

Per accedere alla console GDC o a un cluster, segui questi passaggi:

Console

Apri il seguente URL in una nuova scheda del browser per accedere all'interfaccia utente (UI) di Distributed Cloud:

https://GDC_URL

Sostituisci GDC_URL con il nome di dominio che utilizzi per accedere a Distributed Cloud fornito dall'operatore dell'infrastruttura (IO). Quando apri un URL per la prima volta, Distributed Cloud ti reindirizza alla pagina di accesso del provider di identità se l'operatore dell'infrastruttura (IO) ha configurato la pagina.

Ad esempio, la seguente immagine mostra l'accesso all'interfaccia utente della console per un'organizzazione denominata org-1:

gdcloud

Quando accedi a CLI gdcloud, utilizza il gdcloud auth login comando per autenticare un'entità in CLI gdcloud. La CLI gdcloud utilizza questa entità per l'autenticazione e l'autorizzazione alla gestione di risorse e servizi. Google Cloud

Prima di accedere, assicurati di:

• Scarica il file binario di gdcloud CLI e installalo nel sistema. Per saperne di più, consulta Scaricare gdcloud CLI.
• Configura e inizializza la configurazione predefinita di gdcloud CLI. Assicurati di impostare l'URL dell'organizzazione corretto, che viene utilizzato per recuperare l'endpoint di configurazione dell'accesso. Per saperne di più, consulta Installazione di CLI gdcloud.
• Installa kubectl CLI.
• Installa il plug-in di autenticazione gdcloud-k8s-auth-plugin. Per saperne di più, consulta Autenticazione di gdcloud CLI.

Importante: esegui i passaggi successivi sul tuo sistema con il tuo account utente e non con l'account root. La CLI gdcloud non apre automaticamente un browser in modalità root.

Per accedere a un server API di gestione o a un cluster Kubernetes, segui questi passaggi:

• Server API di gestione:

1. Esporta il percorso in cui vuoi archiviare il file kubeconfig del server API di gestione:

   export KUBECONFIG=MANAGEMENT_API_SERVER
   

   Sostituisci MANAGEMENT_API_SERVER con il percorso della directory in cui archiviare il file kubeconfig.

2. Autentica l'istanza di gdcloud CLI per accedere. Esistono due modi per eseguire l'autenticazione:

   • Accesso standard al browser: utilizza questo flusso di autenticazione quando accedi da un browser.

     gdcloud auth login
     

   • Accesso al dispositivo secondario: utilizza questo flusso di autenticazione se il dispositivo principale non ha un browser disponibile. Questo flusso avvia l'accesso sul dispositivo principale senza accesso al browser e continua l'accesso con il dispositivo secondario che ha accesso al browser.

     Avvia l'accesso sul dispositivo principale senza browser:

     gdcloud auth login --no-browser
     

     La variabile di ambiente KUBECONFIG viene aggiornata con i file kubeconfig per tutti i server API e i cluster dell'organizzazione. Se la variabile KUBECONFIG non è impostata, kubectl CLI utilizza il file kubeconfig predefinito archiviato in $HOME/.kube/config.

     Per evitare di modificare i file kubeconfig, aggiungi il flag --skip-kubeconfig-update al comando. Ad esempio:

     gdcloud auth login --no-browser --skip-kubeconfig-update
     

     Copia l'output comando gdcloud CLI stampato ed eseguilo su una macchina con accesso al browser.

3. Segui le istruzioni nella pagina web per completare la procedura di accesso.

   Al termine dell'accesso, il browser visualizza il messaggio Autenticazione riuscita. Chiudi questa finestra.

4. Segui le istruzioni nel terminale. Al termine dell'accesso, il terminale visualizza il messaggio: Hai eseguito l'accesso.

   Nota: se visualizzi un errore x509: certificate signed by unknown authority, la tua workstation non considera attendibile il certificato CA utilizzato in GDC.

   Segui la procedura della tua organizzazione per controllare l'archivio di certificazioni attendibili per la tua workstation.Avviso:l'utilizzo di --login-config-cert con un certificato non verificato ti rende vulnerabile agli attacchi man in the middle.

   Assicurati di fare affidamento solo sull'archivio di attendibilità della tua workstation anziché considerare attendibile un certificato CA proveniente da fonti sconosciute.

• Cluster Kubernetes:

1. Autentica l'istanza di gdcloud CLI per accedere. Esistono due modi per eseguire l'autenticazione:

   • Accesso standard al browser: utilizza questo flusso di autenticazione quando accedi da un browser.

     gdcloud auth login
     

   • Accesso al dispositivo secondario: utilizza questo flusso di autenticazione se il dispositivo principale non ha un browser disponibile. Questo flusso avvia l'accesso sul dispositivo principale senza accesso al browser e continua l'accesso con il dispositivo secondario che ha accesso al browser.

     1. Avvia l'accesso sul dispositivo principale senza browser:

        gdcloud auth login --no-browser
        

        Il comando nel dispositivo principale stampa un altro comando gdcloud che devi eseguire sul dispositivo secondario nel passaggio c.

     2. Ripeti il passaggio 1 per scaricare il certificato sul dispositivo secondario.

     3. Completa l'accesso sul dispositivo secondario inserendo il comando stampato sul dispositivo principale nel passaggio a.

   Questa azione apre un browser per accedere al provider di identità (IdP) configurato. Fornisci il nome utente e la password che hai impostato durante la configurazione iniziale di gdcloud CLI per accedere.

   Nota: se visualizzi un errore x509: certificate signed by unknown authority, la tua workstation non considera attendibile il certificato CA utilizzato in GDC.

   Segui la procedura della tua organizzazione per controllare l'archivio di certificazioni attendibili per la tua workstation.Avviso:l'utilizzo di --login-config-cert con un certificato non verificato ti rende vulnerabile agli attacchi man in the middle.

   Assicurati di fare affidamento solo sull'archivio di attendibilità della tua workstation anziché considerare attendibile un certificato CA proveniente da fonti sconosciute.

2. Esporta il file kubeconfig dell'identità utente come variabile:

   export KUBECONFIG=/tmp/CLUSTER_NAME-ZONE-kubeconfig-with-user-identity.yaml
   

3. Genera un file kubeconfig per un cluster zonale con la tua identità utente:

   gdcloud clusters get-credentials CLUSTER_NAME --zone ZONE
   

   Sostituisci ZONE con il nome della zona.

   Importante: l'apiserver globale non è associato ad alcuna zona, quindi esegui questo comando senza il flag zone per generare il file kubeconfig per l'apiserver globale: gdcloud clusters get-credentials global-api.
   Nota: l'elenco dei nomi dei cluster disponibili è disponibile nell'URL di configurazione dell'accesso:
   https://GDC_URL/.well-known/login-config.

   Viene generato un file kubeconfig con la tua identità utente. Il seguente file YAML mostra un esempio:

   apiVersion: v1
   clusters:
   - cluster:
     certificate-authority-data: <REDACTED>
     server: https://10.200.0.32:443
   name: cluster-name
   contexts:
   - context:
     cluster: cluster-name
     user: cluster-name-anthos-default-user
   name: cluster-name-cluster-name-anthos-default-user
   current-context: cluster-name-cluster-name-anthos-default-user
   kind: Config
   preferences: {}
   users:
   - name: cluster-name-anthos-default-user
   user:
     exec:
       apiVersion: client.authentication.k8s.io/v1
       args:
       - --audience=root-admin
       command: gdcloud-k8s-auth-plugin
       env: null
       installHint: Run 'gdcloud components install gdcloud-k8s-auth-plugin' to use plugin
       interactiveMode: Never
       provideClusterInfo: false
   

4. Per verificare di poter accedere al cluster, accedi con il file kubeconfig generato con un'identità utente:

   kubectl --kubeconfig /tmp/admin-kubeconfig-with-user-identity.yaml version
   

Esci

Per uscire dalla console GDC:

Console

Fai clic su Esci nella barra dei menu.

gdcloud

Esci dalla CLI:

gdcloud auth revoke

Nota: qualsiasi pagina che si basa sulle risorse Kubernetes non funziona. La console di debug di Chrome mostra errori "forbidden" nelle risposte. Questo errore si verifica perché all'utente non sono state concesse autorizzazioni e non è associato ad alcun ruolo. Per istruzioni su come concedere le autorizzazioni, consulta Concedere l'accesso alle risorse.

Generare manualmente il file kubeconfig

Se gestisci le risorse con kubectl CLI chiamando direttamente le API KRM, devi generare il file kubeconfig per il cluster o il server API che ospita la risorsa, a seconda del tipo di risorsa che stai gestendo.

Devi anche conoscere la configurazione dell'universo GDC per determinare le zone in cui intendi eseguire il deployment delle risorse zonali o il server API globale per le risorse globali. Per saperne di più, consulta Server API globali e zonali.

Determina se la risorsa che stai manipolando è una risorsa globale o zonale. Se non sei sicuro, consulta la documentazione dedicata della risorsa per ricevere assistenza.

Completa la configurazione applicabile in base al tipo di risorsa.

Risorse del server API di gestione zonale

Completa i seguenti passaggi per generare il file kubeconfig per il server API di gestione zonale:

1. Visualizza tutte le zone disponibili:

   gdcloud zones list
   

   Prendi nota del nome della zona che ospita la risorsa personalizzata.

2. Imposta la variabile di ambiente ZONE sulla zona che ospita le risorse zonali:

   export ZONE="ZONE"
   

   Sostituisci ZONE con il nome della zona.

3. Imposta la variabile di ambiente MANAGEMENT_API_SERVER:

   export MANAGEMENT_API_SERVER="ORG_NAME-admin"
   

   Sostituisci ORG_NAME con il nome della tua organizzazione, ad esempio org-1.

4. Genera il file kubeconfig del server API di gestione per la zona di destinazione e convalida le credenziali:

   export KUBECONFIG=${HOME}/${MANAGEMENT_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${MANAGEMENT_API_SERVER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${MANAGEMENT_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   Il comando rm ${KUBECONFIG:?} rimuove il file kubeconfig esistente nella home directory. Quando generi un nuovo file kubeconfig, questo sovrascrive quello esistente. Se non vuoi sovrascrivere o rimuovere il file esistente, esegui il backup in un'altra posizione sicura.

Risorse del cluster Kubernetes zonale

Completa i seguenti passaggi per generare il file kubeconfig per il cluster Kubernetes zonale:

1. Visualizza tutte le zone disponibili:

   gdcloud zones list
   

   Prendi nota del nome della zona che ospita la risorsa personalizzata.

2. Imposta la variabile di ambiente ZONE sulla zona che ospita il cluster Kubernetes:

   export ZONE="ZONE"
   

   Sostituisci ZONE con il nome della zona.

3. Imposta la variabile di ambiente KUBERNETES_CLUSTER:

   export KUBERNETES_CLUSTER="KUBERNETES_CLUSTER_NAME"
   

   Sostituisci KUBERNETES_CLUSTER_NAME con il nome del tuo cluster Kubernetes.

4. Genera il file kubeconfig del cluster Kubernetes per la variabile della zona di destinazione e convalida le credenziali:

   export KUBECONFIG=${HOME}/${KUBERNETES_CLUSTER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${KUBERNETES_CLUSTER:?} --zone ${ZONE:?}
   [[ $(kubectl config current-context) == *${KUBERNETES_CLUSTER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   Il comando rm ${KUBECONFIG:?} rimuove il file kubeconfig esistente nella home directory. Quando generi un nuovo file kubeconfig, questo sovrascrive quello esistente. Se non vuoi sovrascrivere o rimuovere il file esistente, esegui il backup in un'altra posizione sicura.

Risorse del server API globale

Completa i seguenti passaggi per generare il file kubeconfig per il server API globale:

1. Imposta la variabile di ambiente GLOBAL_API_SERVER:

   export GLOBAL_API_SERVER="global-api"
   

2. Genera il file kubeconfig del server API globale e convalida le credenziali:

   export KUBECONFIG=${HOME}/${GLOBAL_API_SERVER:?}-kubeconfig.yaml
   rm ${KUBECONFIG:?}
   gdcloud clusters get-credentials ${GLOBAL_API_SERVER:?}
   [[ $(kubectl config current-context) == *${GLOBAL_API_SERVER:?}* ]] && echo "Success. Your kubeconfig is at $KUBECONFIG" || echo "Failure"
   

   Il comando rm ${KUBECONFIG:?} rimuove il file kubeconfig esistente nella home directory. Quando generi un nuovo file kubeconfig, questo sovrascrive quello esistente. Se non vuoi sovrascrivere o rimuovere il file esistente, esegui il backup in un'altra posizione sicura.

Disconnessione per inattività della sessione

Dopo quindici o più minuti di inattività in una sessione, la console GDC e la CLI gdcloud ti disconnettono. Distributed Cloud considera l'inattività della sessione come un periodo durante una sessione aperta senza un coinvolgimento attivo da parte tua, ad esempio senza movimento del cursore o della tastiera. Una sessione attiva dura fino a dodici ore con l'attività dell'utente.

Console

In caso di inattività della sessione, la console GDC ti disconnette. Due minuti prima che la console GDC ti disconnetta per inattività, riceverai una finestra di dialogo che ti avvisa della disconnessione:

Dopo la disconnessione per inattività, viene visualizzata la seguente schermata:

Per accedere di nuovo alla console GDC, seleziona il tuo provider di identità e aggiungi le tue credenziali di accesso. Se utilizzi un servizio, ad esempio la dashboard di monitoraggio, e la console GDC ti disconnette per inattività, accedi di nuovo per ottenere l'accesso.

gdcloud

In caso di inattività della sessione, la CLI gdcloud ti disconnette. Dopo che la CLI gdcloud ti ha disconnesso e tenti di eseguire un comando, riceverai un errore di autorizzazione:

Error: error when creating kube client: unable to create k8sclient: Unauthorized

Per accedere di nuovo a GDC, segui i passaggi della CLI descritti in Accedere.

Se accedi di nuovo a GDC tramite un server API di gestione, il file kubeconfig viene aggiornato automaticamente. Per evitare che il file kubeconfig venga aggiornato, utilizza il flag --skip-kubeconfig-update nel comando gdcloud auth login.

Nota: i comandi che non effettuano richieste API, come gdcloud init e gdcloud config, non vengono conteggiati per la tua attività. Quando utilizzi questi comandi, gdcloud CLI ti disconnette comunque.

kubectl

La CLI gdcloud fa scadere i file kubeconfig dopo l'inattività della sessione. Se tenti di eseguire un comando kubectl dopo l'inattività, riceverai un errore di autorizzazione:

error: You must be logged in to the server (Unauthorized)

Per accedere di nuovo e utilizzare il file kubeconfig, segui i passaggi della CLI descritti in Accedere. Per ogni timeout della sessione, devi rigenerare i file kubeconfig.