Configura il gateway Connect con identità di terze parti

Questa guida è rivolta agli amministratori di piattaforma che devono configurare il gateway Connect in un progetto che contiene utenti che non hanno identità Google e non appartengono a Google Workspace. In questa guida, queste identità sono chiamate "identità di terze parti". Prima di leggere questa guida, dovresti acquisire familiarità con i concetti descritti nella Panoramica di Connessione del gateway. Per autorizzare singoli Account Google, vedi Configurare il gateway di Connect. Per il supporto di Google Gruppi, consulta Configurare il gateway Connect con Google Gruppi.

La configurazione in questa guida consente agli utenti di accedere ai cluster del parco risorse 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:

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

Se hai un caso d'uso per ambienti cluster GKE diversi da quelli elencati in precedenza, contatta l'assistenza clienti Google Cloud o il team del gateway Connect.

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à per la 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à Identity and Access Management (IAM) che segue il formato:

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

  • WORKFORCE_POOL_ID è il nome del pool 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 diagramma seguente mostra un flusso tipico per un utente di terze parti che autentica ed esegue comandi su un cluster in cui questo servizio è abilitato. Affinché questo flusso abbia esito positivo, è necessario applicare al cluster un criterio di controllo dell'accesso dell'accesso basato su ruoli (RBAC) per l'utente o per un gruppo.

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

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

  1. Contiene l'utente alice@example.com come membro.

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

Diagramma che mostra il flusso di identità di terze parti del gateway

  1. L'utente alice@example.com 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 riceve il gateway del cluster kubeconfig, come descritto in Utilizzo del gateway Connect.
  2. L'utente invia una richiesta eseguendo un comando kubectl oppure aprendo le pagine Carichi di lavoro o Browser oggetti di Google Kubernetes Engine nella console Google Cloud.
  3. La richiesta viene ricevuta dal gateway Connect, che gestisce l'autenticazione di terze parti utilizzando la federazione delle identità per la forza lavoro.
  4. Il gateway Connect esegue un controllo dell'autorizzazione con IAM.
  5. Il servizio Connect inoltra la richiesta all'agente Connect in esecuzione sul cluster. La richiesta è accompagnata dalle informazioni delle credenziali dell'utente da utilizzare per l'autenticazione e l'autorizzazione nel cluster.
  6. L'agente Connect inoltra la richiesta al server API Kubernetes.
  7. Il server API di Kubernetes inoltra la richiesta a GKE Identity Service, che la convalida.
  8. GKE Identity Service restituisce le informazioni su utenti e 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 nel cluster.

Prima di iniziare

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

    • L'ultima versione di Google Cloud CLI dello strumento a riga di comando per interagire con Google Cloud.
    • Lo strumento a riga di comando di Kubernetes, kubectl, per interagire con i tuoi cluster.

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

  • Assicurati di aver inizializzato l'interfaccia alla gcloud CLI per utilizzarla con il tuo progetto.

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

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

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

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

Abilita le API

Per aggiungere il gateway al progetto, abilita l'API Connect gateway e le API di dipendenza richieste. Se i tuoi utenti vogliono eseguire l'autenticazione nei cluster solo utilizzando la console Google Cloud, non è necessario abilitare connectgateway.googleapis.com, ma le API rimanenti.

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

Configura il servizio di identità GKE

La funzionalità di supporto delle identità di terze parti del gateway Connect utilizza il servizio di identità GKE per ottenere da Google informazioni sull'iscrizione a gruppi di terze parti. Scopri di più sul servizio di identità GKE in Introduzione a GKE Identity Service.

Assicurati che il servizio di identità GKE 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 cluster eseguendo questo comando:

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

Sostituisci CLUSTER_KUBECONFIG con il percorso a kubeconfig del cluster.

Configurare il supporto dell'identità di terze parti per i gruppi

Se il cluster o il parco risorse è già configurato per l'assistenza per Google Gruppi, non sono necessari ulteriori passaggi e puoi passare direttamente a Concedi ruoli IAM a utenti e gruppi di terze parti.

Se utilizzi Google Distributed Cloud on VMware o bare metal, il modo in cui configuri GKE Identity Service determina il modo in cui devi configurare la funzionalità dei gruppi di terze parti.

Se utilizzi il servizio di identità GKE per la prima volta, puoi scegliere se configurare il supporto per gruppi di terze parti utilizzando le API Fleet (consigliato) o utilizzare kubectl.

Se non sei un nuovo utente del servizio di identità GKE, tieni presente uno dei seguenti aspetti:

  • Se hai già configurato GKE Identity Service per un altro provider di identità a livello di parco risorse, la funzionalità relativa ai gruppi di terze parti è abilitata per impostazione predefinita. Consulta la sezione Floet di seguito per ulteriori dettagli ed eventuali configurazioni aggiuntive di cui potresti avere bisogno.

  • Se hai già configurato GKE Identity Service per un altro provider di identità in base al 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 Google Cloud o la riga di comando per configurare l'accesso a gruppi di terze parti utilizzando le API Fleet Feature.

Console

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

Seleziona i cluster e aggiorna la configurazione

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

    Vai a Gestore funzionalità

  2. Fai clic su Details (Dettagli) nel riquadro Identity Service (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 che vuoi configurare. Puoi scegliere singoli cluster o specificare che tutti i cluster siano 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 andare al passaggio di configurazione successivo. Se hai selezionato almeno un cluster idoneo per questa configurazione, viene visualizzata la sezione Autenticazione Google.

  7. Seleziona Abilita per abilitare 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. In questo modo verrà applicata la configurazione dell'identità sui cluster selezionati.

gcloud

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

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

Configurazione dell'accesso a gruppi di terze parti tramite un proxy

Se devi accedere al provider di identità tramite un proxy, usa un campo proxy nel file auth-config.yaml. Potresti dover impostare questa opzione se, ad esempio, il cluster si trova su una rete privata e deve connettersi a un provider di identità pubblica. Devi aggiungere questa configurazione anche se hai già configurato GKE Identity Service 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. Questo valore è impostato su false per impostazione predefinita. 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 questo comando:

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 GKE Identity Service 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 utilizzato 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 comando seguente.

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

Se sono presenti più contesti in kubeconfig, viene utilizzato quello attuale. Potresti dover reimpostare il contesto attuale nel cluster corretto prima di eseguire il comando.

Ecco un esempio di come puoi aggiornare ClientConfig con un nuovo metodo di autenticazione con una configurazione di tipo google per abilitare 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'iscrizione del cluster. Puoi recuperare i dettagli dell'appartenenza al 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'appartenenza 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

Concedi ruoli IAM a utenti e gruppi di terze parti

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

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

Di seguito viene illustrato come aggiungere i ruoli necessari a singole identità e gruppi mappati:

Identità singole

Per concedere i ruoli necessari a una singola identità per il progetto PROJECT_ID, esegui questo 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à dell'utente.

Gruppi

Per concedere i ruoli necessari a tutte le identità all'interno di un gruppo specifico per il progetto PROJECT_ID, esegui questo 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 google.groups mappata.

Fai riferimento alla configurazione del tuo provider di identità elencata in Configurare mappature di terze parti utilizzando Workforce Identity per ulteriori personalizzazioni, come la specifica degli attributi del reparto, quando si applica il criterio RBAC.

Per saperne di più sulla concessione delle autorizzazioni e dei ruoli IAM, consulta Concessione, modifica e revoca dell'accesso alle risorse.

Configurare 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 provenienti dal gateway dall'utente e dai gruppi di terze parti specificati. Per ogni cluster, devi aggiungere un criterio di autorizzazione RBAC che specifichi le autorizzazioni di cui il soggetto dispone sul cluster.

I soggetti nei criteri RBAC devono utilizzare lo stesso formato delle associazioni IAM, con utenti di terze parti che iniziano con principal://iam.googleapis.com/ e 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 ai ruoli/clusterrole per un utente di terze parti. In questo caso, segui questi passaggi di configurazione RBAC, aggiungendo l'entità di terze parti 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 su un cluster in cui è configurato GKE Identity Service. 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

Per ulteriori informazioni sulla specifica delle autorizzazioni RBAC, consulta Utilizzo dell'autorizzazione RBAC.

Che cosa succede dopo?