Configurare Connect Gateway con identità di terze parti

Questa guida è rivolta agli amministratori della piattaforma che devono configurare il gateway Connect in un progetto che contiene utenti che non dispongono di identità Google e non appartengono a Google Workspace. In questa guida, queste identità sono indicate come "identità di terze parti". Prima di leggere questa guida, devi conoscere i concetti descritti nella Panoramica di Connect Gateway. Per autorizzare i singoli Account Google, consulta Configurare il gateway Connect. Per l'assistenza di Google Gruppi, consulta Configurare Connect Gateway con Google Gruppi.

La configurazione descritta in questa guida consente agli utenti di accedere ai cluster di flotte utilizzando Google Cloud CLI, il gateway Connect e la console Google Cloud .

Tipi di cluster supportati

Puoi configurare il controllo dell'accesso con identità di terze parti tramite il gateway Connect per i seguenti tipi di cluster registrati:

• Cluster GKE
• Google Distributed Cloud (solo software) su VMware e su bare metal da Anthos (GKE Enterprise) 1.13 e versioni successive
• GKE su AWS e GKE su Azure da Kubernetes versione 1.25 e successive.
• Cluster collegati da Anthos (GKE Enterprise) 1.16 e versioni successive.

Se devi eseguire l'upgrade dei cluster on-premise per utilizzare questa funzionalità, consulta Eseguire l'upgrade dei cluster GKE Enterprise per VMware e Eseguire l'upgrade dei cluster GKE Enterprise su bare metal.

Se hai un caso d'uso per ambienti di cluster GKE diversi da quelli elencati sopra, contatta l'assistenza clienti Google Cloud o il team di Connect Gateway.

Come funziona

Come descritto nella panoramica, gli utenti potrebbero utilizzare provider di identità diversi da Google Workspace o Cloud Identity. Utilizzando la federazione delle identità della forza lavoro, gli utenti possono utilizzare i propri provider di identità di terze parti, come Okta o Azure Active Directory, per accedere ai propri cluster tramite Connect Gateway. A differenza degli Account Google, gli utenti di terze parti sono rappresentati da un'entità IAM (Identity and Access Management) che segue il formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE

• WORKFORCE_POOL_ID è il nome del pool di forza lavoro che contiene il provider di identità di terze parti pertinente.

• SUBJECT_VALUE è la mappatura dell'identità di terze parti a un soggetto Google.

Per i gruppi di terze parti, l'entità IAM segue il formato:

principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_VALUE

Il seguente diagramma mostra un flusso tipico per un utente di terze parti che esegue l'autenticazione e comandi su un cluster con questo servizio abilitato. Affinché questo flusso vada a buon fine, è necessario applicare un criterio di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) al cluster per l'utente o per un gruppo.

Per i singoli utenti, sul cluster deve esistere un criterio RBAC che utilizzi il nome completo dell'entità IAM dell'utente.

Se utilizzi la funzionalità di gruppo, nel cluster deve esistere un criterio RBAC che utilizzi il nome completo dell'entità IAM per un gruppo che:

1. Contiene l'utente [e-mail] come membro.

2. È incluso in una mappatura per un provider di identità all'interno di un pool di forza lavoro nell'organizzazione Google Cloud di Alice.

Nota: GKE Identity Service deve essere configurato per consentire il funzionamento della funzionalità dei gruppi di terze parti nei cluster dei membri del parco fuori da Google Cloud.

1. L'utente [e-mail] accede a gcloud con la propria identità di terze parti utilizzando l'accesso basato su browser di terze parti. Per utilizzare il cluster dalla riga di comando, l'utente ottiene il gateway kubeconfig del cluster come descritto in Utilizzare Connect Gateway.
2. L'utente invia una richiesta eseguendo un comando kubectl o aprendo le pagine Workloads o Browser degli oggetti di Google Kubernetes Engine nella console Google Cloud .
3. La richiesta viene ricevuta da Connect Gateway, che gestisce l'autenticazione di terze parti utilizzando la federazione delle identità della forza lavoro.
4. Il gateway Connect esegue un controllo di autorizzazione con IAM.
5. Il servizio Connect inoltra la richiesta all'agente Connect in esecuzione sul cluster. La richiesta è accompagnata dalle informazioni sulle credenziali dell'utente da utilizzare per l'autenticazione e l'autorizzazione nel cluster.
6. L'agente Connect inoltra la richiesta al server dell'API Kubernetes.
7. Il server API Kubernetes inoltra la richiesta a GKE Identity Service, che la convalida.
8. GKE Identity Service restituisce le informazioni sugli utenti e sui gruppi di terze parti al server API Kubernetes. Il server API Kubernetes può quindi utilizzare queste informazioni per autorizzare la richiesta in base ai criteri RBAC configurati del cluster.

Prima di iniziare

• Assicurati di avere installato i seguenti strumenti a riga di comando:

  • La versione più recente di Google Cloud CLI, lo strumento a riga di comando per interagire con Google Cloud.
  • Lo strumento a riga di comando Kubernetes, kubectl, per interagire con i cluster.

  Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati per te.

• Assicurati di aver inizializzato gcloud CLI per l'utilizzo con il tuo progetto.

• Questa guida presuppone che tu abbia roles/owner nel tuo progetto. Se non sei un proprietario del progetto, potresti aver bisogno di autorizzazioni aggiuntive per eseguire alcuni passaggi di configurazione.

• Per i cluster esterni a Google Cloud, il servizio GKE Identity deve chiamare le API Google dal tuo cluster per completare l'autenticazione. Controlla se il criterio di rete richiede che il traffico in uscita passi attraverso un proxy.

Configurare le mappature degli attributi delle identità di terze parti utilizzando Workforce Identity

Assicurati che per la tua organizzazione Google Cloud sia configurato un pool di forza lavoro e un provider di identità seguendo le istruzioni corrispondenti al tuo provider di identità:

• Azure AD
• Okta
• Altro OIDC o SAML 2.0

Nota: esiste un limite di 4 kilobyte per la mappatura degli attributi, inclusi i gruppi, per ogni provider di identità.

Abilita API

Per aggiungere il gateway al progetto, abilita l'API Connect Gateway e le API di dipendenza richieste. Se i tuoi utenti vogliono autenticarsi ai cluster solo utilizzando la console Google Cloud , non devi attivare connectgateway.googleapis.com, ma devi attivare le API rimanenti.

gcloud services enable --project=PROJECT_ID  \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com

Nota: se non sei il proprietario del progetto, devi disporre dell'autorizzazione serviceusage.services.enable prima di poter attivare le API per il progetto.

Configura GKE Identity Service

La funzionalità di supporto delle identità di terze parti di Connect Gateway utilizza GKE Identity Service per ottenere da Google informazioni sull'appartenenza ai gruppi. Per scoprire di più su GKE Identity Service, consulta Introduzione a GKE Identity Service.

Se utilizzi i cluster GKE con il gateway, non devi configurare GKE Identity Service per utilizzare il supporto delle identità di terze parti. Segui invece le istruzioni riportate in Configurare Google Gruppi per il RBAC e vai a Concedere i ruoli IAM per concedere l'accesso ai cluster tramite il gateway.

Se utilizzi cluster collegati a GKE con il gateway, GKE Identity Service non è necessario per il supporto delle identità di terze parti. Segui le istruzioni per il tipo di cluster scelto per configurare il supporto delle identità di terze parti:

• Connettiti al cluster collegato a EKS
• Connettiti al cluster AKS collegato
• Connettersi ad altri tipi di cluster

Assicurati che GKE Identity Service sia installato

GKE Identity Service è installato per impostazione predefinita sui cluster GKE a partire dalla versione 1.7 (anche se il supporto delle identità di terze parti richiede la versione 1.13 o successive). Puoi verificare che sia installato correttamente nel tuo cluster eseguendo il seguente comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service

Sostituisci CLUSTER_KUBECONFIG con il percorso del file kubeconfig del cluster.

Configurare il supporto delle identità di terze parti per i gruppi

Se il tuo cluster o il tuo parco è già configurato per il supporto di Google Gruppi, non sono necessari altri passaggi e puoi andare a Concedere ruoli IAM a utenti e gruppi di terze parti.

Se utilizzi Google Distributed Cloud su VMware o bare metal, il modo in cui configuri il servizio GKE Identity determina la modalità di configurazione della funzionalità dei gruppi di terze parti.

Se utilizzi GKE Identity Service per la prima volta, puoi scegliere tra configurare il supporto dei gruppi di terze parti utilizzando le API Fleet (opzione consigliata) o kubectl.

Se non è la prima volta che utilizzi il servizio GKE Identity, tieni presente una delle seguenti informazioni:

• Se hai già configurato GKE Identity Service per un altro provider di identità a livello di parco risorse, la funzionalità dei gruppi di terze parti è attiva per impostazione predefinita. Per ulteriori dettagli e per eventuali configurazioni aggiuntive, consulta la sezione Flotta di seguito.

• Se hai già configurato GKE Identity Service per un altro provider di identità su base per cluster, consulta la sezione Kubectl di seguito per istruzioni su come aggiornare la configurazione per la funzionalità dei gruppi di terze parti.

Parco risorse

Puoi utilizzare la console o la riga di comando di Google Cloud per configurare l'accesso ai gruppi di terze parti utilizzando le API di funzionalità del parco.

Console

Se non hai ancora configurato GKE Identity Service per un parco risorse, segui le istruzioni riportate in Configurare i cluster per GKE Identity Service.

Seleziona i cluster e aggiorna la configurazione

1. Nella console Google Cloud , vai alla pagina Gestione funzionalità.

   Vai a Gestore funzionalità

2. Fai clic su Dettagli nel riquadro Servizio di identità. Vengono visualizzati i dettagli del cluster del progetto.

3. Fai clic su Aggiorna servizio di identità per aprire il riquadro di configurazione.

4. Seleziona i cluster da configurare. Puoi scegliere singoli cluster o specificare che tutti i cluster devono essere configurati con la stessa configurazione dell'identità.

5. Nella sezione Configura provider di identità, puoi scegliere di conservare, aggiungere, aggiornare o rimuovere un provider di identità.

6. Fai clic su Continua per passare al passaggio di configurazione successivo. Se hai selezionato almeno un cluster idoneo per questa configurazione, viene visualizzata la sezione Autenticazione Google.

7. Seleziona Attiva per attivare l'autenticazione Google per i cluster selezionati. Se devi accedere al provider di identità Google tramite un proxy, inserisci i dettagli del proxy.

8. Fai clic su Aggiorna configurazione. La configurazione dell'identità viene applicata ai cluster selezionati.

gcloud

Se non hai ancora configurato GKE Identity Service per un parco risorse, segui le istruzioni riportate in Configurare i cluster per GKE Identity Service. Specifica solo la seguente configurazione nel file auth-config.yaml:

spec:
  authentication:
  - name: google-authentication-method
    google:
      disable: false

Configurare l'accesso ai gruppi di terze parti utilizzando un proxy

Se devi accedere al provider di identità tramite un proxy, utilizza un campo proxy nel file auth-config.yaml. Potresti dover impostare questo valore se, ad esempio, il tuo cluster si trova in una rete privata e deve connettersi a un provider di identità pubblico. Devi aggiungere questa configurazione anche se hai già configurato Identity Service for GKE per un altro provider.

Per configurare proxy, ecco come aggiornare la sezione authentication del file di configurazione esistente auth-config.yaml.

  spec:
    authentication:
    - name: authentication-method
      google:
        disable: false
      proxy: PROXY_URL

dove

• disable (facoltativo) indica se vuoi attivare o disattivare la funzionalità dei gruppi di terze parti per i cluster. Per impostazione predefinita, questo valore è impostato su false. Se vuoi disattivare questa funzionalità, puoi impostarla su true.

• PROXY_URL (facoltativo) è l'indirizzo del server proxy per la connessione all'identità Google. Ad esempio: http://user:password@10.10.10.10:8888

Applica la configurazione

Per applicare la configurazione a un cluster, esegui il comando seguente:

gcloud container fleet identity-service apply \
--membership=CLUSTER_NAME \
--config=/path/to/auth-config.yaml

dove

CLUSTER_NAME è il nome univoco dell'appartenenza del cluster all'interno del parco risorse.

Una volta applicata, questa configurazione viene gestita dal controller GKE Identity Service. Eventuali modifiche locali apportate alla configurazione del client di Identity Service for GKE vengono riconciliate dal controller con la configurazione specificata in questa configurazione.

kubectl

Per configurare il cluster in modo che utilizzi GKE Identity Service con la funzionalità dei gruppi di terze parti, devi aggiornare GKE Identity Service ClientConfig del cluster. Si tratta di un tipo di risorsa personalizzata (CRD) di Kubernetes utilizzata per la configurazione del cluster. Ogni cluster GKE Enterprise ha una risorsa ClientConfig denominata default nello spazio dei nomi kube-public che aggiorni con i dettagli di configurazione.

Per modificare la configurazione, utilizza il seguente comando.

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Se in kubeconfig sono presenti più contesti, viene utilizzato il contesto corrente. Prima di eseguire il comando, potrebbe essere necessario reimpostare il contesto corrente sul cluster corretto.

Ecco un esempio di come aggiornare ClientConfig con un nuovo metodo di autenticazione con una configurazione di tipo google per attivare la funzionalità dei gruppi di terze parti. Se il campo internalServer è vuoto, assicurati che sia impostato su https://kubernetes.default.svc, come mostrato di seguito.

spec:
  authentication:
  - google:
      audiences:
      - "CLUSTER_IDENTIFIER"
    name: google-authentication-method
    proxy: PROXY_URL
  internalServer: https://kubernetes.default.svc

dove

CLUSTER_IDENTIFIER (obbligatorio) indica i dettagli dell'abbonamento al cluster. Puoi recuperare i dettagli dell'abbonamento del tuo cluster utilizzando il comando:

kubectl --kubeconfig CLUSTER_KUBECONFIG get memberships membership -o yaml

dove

CLUSTER_KUBECONFIG è il percorso del file kubeconfig per il cluster. Nella risposta, fai riferimento al campo spec.owner.id per recuperare i dettagli dell'abbonamento del cluster.

Ecco un esempio di risposta che mostra i dettagli dell'appartenenza a un cluster:

id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34ef

che corrisponde al seguente formato: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP

Concedere ruoli IAM a utenti e gruppi di terze parti

Le identità di terze parti richiedono i seguenti ruoli aggiuntivi di Google Cloud per interagire con i cluster collegati tramite il gateway:

• roles/gkehub.gatewayAdmin. Questo ruolo consente agli utenti di accedere all'API gateway Connect.
  • Se gli utenti hanno bisogno solo di accesso in sola lettura ai cluster collegati, è possibile utilizzare roles/gkehub.gatewayReader.
  • Se gli utenti hanno bisogno di accesso in lettura/scrittura ai cluster collegati, è possibile utilizzare roles/gkehub.gatewayEditor.
• roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare le iscrizioni ai cluster registrate.

Di seguito viene mostrato come aggiungere i ruoli necessari alle singole identità e ai gruppi mappati:

Identità singole

Per concedere i ruoli necessari a una singola identità per il progettoPROJECT_ID, esegui il seguente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principal://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/subject/SUBJECT_VALUE"

dove

• PROJECT_ID: è l'ID del progetto.
• GATEWAY_ROLE è uno di roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: è l'ID del pool di identità della forza lavoro.
• SUBJECT_VALUE: è l'identità utente.

Gruppi

Per concedere i ruoli necessari a tutte le identità all'interno di un gruppo specifico per il progetto PROJECT_ID, esegui il seguente comando:

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=GATEWAY_ROLE \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

gcloud projects add-iam-policy-binding PROJECT_ID \
    --role=roles/gkehub.viewer \
    --member="principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP_ID"

dove

• PROJECT_ID: è l'ID del progetto.
• GATEWAY_ROLE è uno di roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o gkehub.gatewayEditor.
• WORKFORCE_POOL_ID: è l'ID del pool di forza lavoro.
• GROUP_ID: è un gruppo nella rivendicazione mappatagoogle.groups.

Per ulteriori personalizzazioni, ad esempio la specifica degli attributi dei reparti, quando applichi il criterio RBAC, consulta la configurazione del provider di identità elencata in Configurare le mappature di terze parti utilizzando Workforce Identity.

Scopri di più sulla concessione di autorizzazioni e ruoli IAM in Concessione, modifica e revoca dell'accesso alle risorse.

Configura i criteri di controllo dell'accesso basato sui ruoli (RBAC)

Infine, il server API Kubernetes di ogni cluster deve essere in grado di autorizzare i comandi kubectl inviati tramite il gateway dagli utenti e dai gruppi di terze parti specificati. Per ogni cluster, devi aggiungere un criterio di autorizzazione RBAC che specifichi le autorizzazioni di cui dispone l'oggetto nel cluster.

Nota: il percorso della risorsa per un utente di terze parti non include il nome del provider di identità. Per evitare autorizzazioni impreviste, assicurati di non utilizzare gli stessi nomi di utenti o gruppi in provider di identità diversi per un singolo pool di personale.

I soggetti nei criteri RBAC devono utilizzare lo stesso formato delle associazioni IAM, con gli utenti di terze parti che iniziano con principal://iam.googleapis.com/ e i gruppi di terze parti che iniziano con principalSet://iam.googleapis.com/. Se GKE Identity Service non è configurato per il cluster, avrai bisogno di criteri di rappresentazione oltre a ruoli/clusterroles per un utente di terze parti. In questo caso, segui questi passaggi di configurazione del RBAC, aggiungendo l'entità terza che inizia con principal://iam.googleapis.com/ come utente.

L'esempio seguente mostra come concedere ai membri di un gruppo di terze parti le autorizzazioni cluster-admin in un cluster in cui è configurato il servizio GKE Identity. Puoi quindi salvare il file dei criteri come /tmp/admin-permission.yaml e applicarlo al cluster associato al contesto corrente.

cat <<EOF > /tmp/admin-permission.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: gateway-cluster-admin-group
subjects:
- kind: Group
  name: "principalSet://iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID/group/GROUP"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF
# Apply permission policy to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/admin-permission.yaml

Scopri di più su come specificare le autorizzazioni RBAC in Utilizzo dell'autorizzazione RBAC.

Nota: anche se i nostri esempi mostrano l'applicazione degli aggiornamenti dei criteri direttamente con kubectl, per l'utilizzo pratico consigliamo vivamente di utilizzare Policy Controller per creare e gestire i criteri con Config Sync per sincronizzare questi criteri e altre configurazioni nei tuoi cluster.

Passaggi successivi

• Scopri come utilizzare Connect Gateway per connetterti ai cluster dalla riga di comando.
• Consulta un esempio di come utilizzare il gateway Connect nell'ambito dell'automazione DevOps nel nostro tutorial sull'integrazione con Cloud Build.