Questa guida è rivolta agli amministratori della piattaforma che devono configurare il gateway di connessione 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, devi acquisire familiarità con i concetti descritti nella panoramica del gateway di connessione. Per autorizzare singoli Account Google, consulta Configurazione del gateway di connessione. 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 fleet utilizzando Google Cloud CLI, il gateway di connessione e la console Google Cloud .
Tipi di cluster supportati
Puoi configurare il controllo dell'accesso con identità di terze parti tramite il gateway di connessione per i seguenti tipi di cluster:
- GKE su Google Cloud: tutte le versioni disponibili. Per configurare il gateway di connessione, configura Google Gruppi per RBAC, quindi concedi ruoli IAM a Google Gruppi.
- Google Distributed Cloud (solo software) su VMware e bare metal: tutte le versioni disponibili.
- Google Distributed Cloud connesso: tutte le versioni disponibili.
- Cluster collegati a GKE: versione 1.28.0-gke.2 e successive.
GKE su AWS e GKE su Azure: tutte le versioni disponibili.
Per utilizzare questa funzionalità con ambienti non inclusi nell'elenco precedente, 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à 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 il gateway di connessione. 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 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 i 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 un gruppo.
Per i singoli utenti, nel 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 dell'entità IAM completo per un gruppo che:
Contiene l'utente
alice@example.comcome membro.È incluso in un mapping per un provider di identità all'interno di un pool di forza lavoro che si trova nell'organizzazione di Google Cloud Alice.
- L'utente
alice@example.comaccede a gcloud CLI con la propria identità di terze parti utilizzando l'accesso basato sul browser di terze parti. Per utilizzare il cluster dalla riga di comando, l'utente ottiene il gatewaykubeconfigdel cluster come descritto in Utilizzo di Connect Gateway. - L'utente invia una richiesta eseguendo un comando
kubectlo aprendo le pagine Carichi di lavoro o Browser oggetti di Google Kubernetes Engine nella console Google Cloud . - La richiesta viene ricevuta dal gateway di connessione, che gestisce l'autenticazione di terze parti utilizzando la federazione delle identità per la forza lavoro.
- Il gateway di connessione esegue un controllo dell'autorizzazione con IAM.
- 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 sul cluster.
- L'agente Connect inoltra la richiesta al server API Kubernetes.
- Il server API Kubernetes inoltra la richiesta al componente del servizio di identità nel cluster, che la convalida.
- Il componente del servizio di identità 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 del cluster.
Prima di iniziare
- Accedi al tuo account Google Cloud . Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei workload.
-
Installa Google Cloud CLI.
-
Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.
-
Per inizializzare gcloud CLI, esegui questo comando:
gcloud init -
Verifica di disporre delle autorizzazioni necessarie per completare questa guida.
Abilita le API Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager:
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (
roles/serviceusage.serviceUsageAdmin), che include l'autorizzazioneserviceusage.services.enable. Scopri come concedere i ruoli.gcloud services enable connectgateway.googleapis.com
gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com -
Installa Google Cloud CLI.
-
Se utilizzi un provider di identità (IdP) esterno, devi prima accedere a gcloud CLI con la tua identità federata.
-
Per inizializzare gcloud CLI, esegui questo comando:
gcloud init -
Verifica di disporre delle autorizzazioni necessarie per completare questa guida.
Abilita le API Connect Gateway, GKE Connect, GKE Hub, Anthos Identity Service e Cloud Resource Manager:
Ruoli richiesti per abilitare le API
Per abilitare le API, devi disporre del ruolo IAM Amministratore utilizzo dei servizi (
roles/serviceusage.serviceUsageAdmin), che include l'autorizzazioneserviceusage.services.enable. Scopri come concedere i ruoli.gcloud services enable connectgateway.googleapis.com
gkeconnect.googleapis.com gkehub.googleapis.com anthosidentityservice.googleapis.com cloudresourcemanager.googleapis.com - Per i cluster al di fuori di Google Cloud, i componenti di autenticazione nel cluster devono chiamare l'API Cloud Identity. Controlla se hai criteri di rete che richiedono che il traffico in uscita dal cluster passi attraverso un proxy.
Ruoli obbligatori
Per ottenere le autorizzazioni necessarie per configurare il gateway di connessione e i cluster, chiedi all'amministratore di concederti il ruolo IAM Editor (roles/editor) nel progetto.
Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.
Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.
Configura le mappature degli attributi di identità di terze parti utilizzando la federazione delle identità per la forza lavoro
Assicurati che per la tua organizzazione Google Cloud siano configurati un pool di forza lavoro e un provider di identità seguendo le istruzioni corrispondenti al tuo provider di identità:
Configurare il supporto per i gruppi
Il gateway Connect utilizza i componenti di autenticazione nel cluster per recuperare le informazioni sull'iscrizione al gruppo. Per abilitare i componenti richiesti, consulta uno dei seguenti documenti a seconda del tipo di cluster:
- GKE su Google Cloud: configura Google Gruppi per RBAC, poi vai alla sezione Concedi ruoli IAM ai gruppi.
- Cluster collegati a GKE:
Google Distributed Cloud: attiva il supporto per i gruppi aggiornando la risorsa personalizzata ClientConfig nel cluster. Distributed Cloud crea automaticamente un ClientConfig denominato
defaultnello spazio dei nomikube-publicin ogni cluster. Per verificare che questa risorsa personalizzata esista, esegui questo comando:kubectl --kubeconfig CLUSTER_KUBECONFIG get ClientConfig default -n kube-publicSostituisci
CLUSTER_KUBECONFIGcon il percorso del file kubeconfig del cluster.
Se il tuo cluster o il tuo parco risorse è già configurato per il supporto di Google Gruppi, non sono necessari passaggi aggiuntivi e puoi passare a Concedere ruoli IAM a utenti e gruppi di terze parti.
Le sezioni seguenti mostrano come aggiornare la risorsa personalizzata ClientConfig per abilitare il supporto dei gruppi. Queste sezioni si applicano solo ai cluster Google Distributed Cloud. Per altri tipi di cluster, come GKE su Google Cloud; GKE su AWS e GKE su Azure, vai alla sezione Concedere ruoli IAM ai gruppi.
Per Distributed Cloud, puoi configurare il supporto per i gruppi per singoli cluster o per una flotta. Il tipo di cluster che utilizzi determina la modalità di configurazione del supporto dei gruppi, come segue:
- Distributed Cloud connesso: solo singoli cluster. La configurazione a livello di parco risorse non è supportata.
- Google Distributed Cloud (solo software) su VMware e bare metal: singoli cluster o flotte.
Configura il supporto dei gruppi utilizzando l'API GKE Fleet
Per Google Distributed Cloud (solo software) su VMware e bare metal, puoi configurare il supporto dei gruppi a livello di flotta. Se in precedenza hai configurato l'autenticazione a livello di parco auto, ad esempio per un altro provider di identità, l'autenticazione di gruppo è già attivata. Tuttavia, se la tua policy di rete richiede che il traffico in uscita passi attraverso un proxy, devi aggiornare la configurazione esistente con le informazioni su questo proxy.
Per configurare il supporto dei gruppi a livello di parco risorse, seleziona una delle seguenti opzioni:
Console
Nella console Google Cloud , vai alla pagina GKE Identity Service.
Fai clic su Abilita Identity Service.
Seleziona i cluster Google Distributed Cloud (solo software) su VMware e bare metal che vuoi configurare.
Fai clic su Aggiorna configurazione. Viene visualizzato il riquadro Modifica configurazione dei cluster di Identity Service.
Nella sezione Configura provider di identità, puoi scegliere di conservare, aggiungere, aggiornare o rimuovere un provider di identità.
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.
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.
Fai clic su Aggiorna configurazione. In questo modo la configurazione dell'identità viene applicata ai cluster selezionati.
gcloud
- Abilita la funzionalità del servizio di identità a livello di parco risorse e configura i cluster come descritto in Configurare la gestione dell'autenticazione a livello di parco risorse.
Nel file
auth-config.yamlche contiene la specifica ClientConfig, aggiungi il seguente campo:spec: authentication: - name: google-authentication-method google: disable: falseIl valore di
falsenel campogoogle.disableattiva il supporto dei gruppi. Per disattivare il supporto dei gruppi, modifica questo valore impostandolo sutrue.(Facoltativo) Se devi accedere al provider di identità Google tramite un proxy, aggiungi il campo
proxyalla configurazione precedente:spec: authentication: - name: google-authentication-method google: disable: false proxy: PROXY_URLSostituisci
PROXY_URLcon l'indirizzo del server proxy a cui connetterti all'identità Google. Ad esempio:http://user:password@10.10.10.10:8888Applica la configurazione a un cluster nel tuo parco risorse:
gcloud container fleet identity-service apply \ --membership=CLUSTER_NAME \ --config=/path/to/auth-config.yaml
Sostituisci
CLUSTER_NAMEcon il nome univoco dell'appartenenza del tuo cluster all'interno del parco risorse.
Dopo aver configurato il supporto dei gruppi a livello di parco risorse, il controller del parco risorse gestisce la configurazione. La configurazione a livello di parco risorse sovrascrive eventuali modifiche locali apportate alla configurazione in un cluster specifico.
Configura il supporto dei gruppi per i singoli cluster
Per tutti i cluster Distributed Cloud, incluso
Distributed Cloud connesso, abilita il supporto dei gruppi
aggiornando default ClientConfig in ogni cluster:
Recupera i dettagli dell'abbonamento del tuo cluster:
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get memberships membership -o yamlSostituisci
USER_CLUSTER_KUBECONFIGcon il percorso del file kubeconfig per il cluster. Se in kubeconfig sono presenti più contesti, viene utilizzato il contesto corrente. Potresti dover reimpostare il contesto attuale sul cluster corretto prima di eseguire il comando.Nella risposta, fai riferimento al campo
spec.owner.idper recuperare i dettagli dell'appartenenza al cluster. L'identificatore dell'abbonamento ha il formato//gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/MEMBERSHIP.L'output è simile al seguente:
id: //gkehub.googleapis.com/projects/123456789/locations/global/memberships/xy-ab12cd34efApri il file
defaultClientConfig nel tuo cluster per la modifica:kubectl --kubeconfig USER_CLUSTER_KUBECONFIG -n kube-public edit clientconfig defaultPer attivare il supporto dei gruppi, aggiungi il campo
googleal campospec.authentication:spec: internalServer: https://kubernetes.default.svc authentication: - google: audiences: - "CLUSTER_IDENTIFIER" name: google-authentication-methodSostituisci
CLUSTER_IDENTIFIERcon i dettagli dell'appartenenza del tuo cluster.Assicurati che il campo
internalServerabbia il valorehttps://kubernetes.default.svc.(Facoltativo) Se devi accedere al provider di identità Google tramite un proxy, aggiungi il campo
proxyalla configurazione precedente:spec: internalServer: https://kubernetes.default.svc authentication: - google: audiences: - "CLUSTER_IDENTIFIER" name: google-authentication-method proxy: PROXY_URLSostituisci
PROXY_URLcon l'indirizzo del server proxy a cui connetterti all'identità Google. Ad esempio:http://user:password@10.10.10.10:8888
Concedere 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 del gateway di connessione.- Se gli utenti hanno bisogno solo dell'accesso in 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.
- Se gli utenti hanno bisogno solo dell'accesso in sola lettura ai cluster connessi, è possibile utilizzare
roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare le appartenenze ai cluster registrati.
Di seguito viene illustrato come aggiungere i ruoli necessari a singole identità e gruppi mappati:
Singole identità
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 dei valoriroles/gkehub.gatewayAdmin,roles/gkehub.gatewayReaderogkehub.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 dei valoriroles/gkehub.gatewayAdmin,roles/gkehub.gatewayReaderogkehub.gatewayEditor.WORKFORCE_POOL_ID: è l'ID del pool di forza lavoro.GROUP_ID: è un gruppo nella rivendicazionegoogle.groupsmappata.
Per ulteriori personalizzazioni, ad esempio la specifica degli attributi del reparto, quando applichi il criterio RBAC, consulta la configurazione del tuo provider di identità elencata in Configurare le mappature di terze parti utilizzando Workforce Identity.
Per saperne di più sulla concessione di ruoli e autorizzazioni 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 che arrivano tramite il gateway dall'utente e dai gruppi di terze parti specificati. Per ogni cluster, devi aggiungere un criterio di autorizzazioni RBAC che specifichi le autorizzazioni che il soggetto ha sul cluster.
I soggetti nelle policy RBAC devono utilizzare lo stesso formato dei binding 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 il cluster non ha configurato l'autenticazione da identità di terze parti esterne, avrai bisogno di criteri di rappresentazione oltre a ruoli/clusterroles 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 cluster-admin le autorizzazioni su un cluster in cui è configurata l'autenticazione da identità esterne di terze parti. 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 saperne di più su come specificare le autorizzazioni RBAC, consulta Utilizzo dell'autorizzazione RBAC.
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 Integrazione con Cloud Build.