Configura il gateway Connect con identità di terze parti
Questa guida è rivolta agli amministratori di piattaforma che devono configurare il gateway di Connect in un progetto che contiene utenti che non hanno identità Google e non appartengono a Google Workspace. In questa guida, vengono definite identità di terze parti. Prima di leggere questa guida, dovresti acquisire familiarità con i concetti della panoramica di Connect gateway. Per autorizzare singoli Account Google, consulta Configurare il gateway di Connect. Per assistenza con Google Gruppi, consulta Configurare il gateway di 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:
- Cluster GKE
- GKE su VMware e GKE su Bare Metal da GKE Enterprise 1.13 e versioni successive
- GKE su AWS e GKE su Azure da Kubernetes versione 1.25 e successive.
- Cluster collegati da GKE Enterprise 1.16 e versioni successive
Se devi eseguire l'upgrade dei cluster on-premise per utilizzare questa funzionalità, vedi Upgrade dei cluster GKE Enterprise per VMWare e Upgrade dei cluster GKE Enterprise on 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à 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 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
Di seguito è riportato il flusso tipico di un utente di terze parti che esegue l'autenticazione e l'esecuzione dei comandi su un cluster Anthos con questo servizio abilitato. Affinché questo flusso abbia esito positivo, è 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, nel cluster deve esistere un criterio RBAC che utilizza il nome completo dell'entità IAM 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:
Contiene l'utente
alice@example.com
come membro.È incluso in una mappatura per un provider di identità all'interno di un pool di forza lavoro che si trova nell'organizzazione Google Cloud di Alice.
- L'utente
alice@example.com
accede a gcloud con la sua 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 del clusterkubeconfig
, come descritto in Utilizzare il gateway di connessione. - L'utente invia una richiesta eseguendo un comando
kubectl
o aprendo le pagine Carichi di lavoro o Browser oggetti di Google Kubernetes Engine nella console Google Cloud. - La richiesta viene ricevuta dal gateway di Connect, che gestisce l'autenticazione di terze parti utilizzando la federazione delle identità per la forza lavoro.
- Il gateway Connect 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 a GKE Identity Service, che la convalida.
- 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 aver 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 di Kubernetes,
kubectl
, per interagire con i cluster.
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti sono installati automaticamente.
Assicurati di aver inizializzato gcloud CLI per utilizzarlo con il tuo progetto.
Questa guida presuppone che tu abbia
roles/owner
nel tuo progetto. 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 tuo cluster per completare l'autenticazione. Verifica se il criterio di rete richiede che il traffico in uscita passi attraverso un proxy.
Configura le mappature degli attributi delle 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 autenticarsi nei cluster utilizzando la console Google Cloud, non è necessario abilitare connectgateway.googleapis.com
, ma devi abilitare 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 GKE Identity Service
La funzionalità di supporto delle identità di terze parti del gateway utilizza GKE Identity Service per ricevere da Google informazioni sull'iscrizione a gruppi di terze parti. Per saperne di più su GKE Identity Service, consulta Introduzione a GKE Identity Service.
Assicurati che il servizio GKE Identity 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 sul tuo cluster eseguendo questo comando:
kubectl --kubeconfig CLUSTER_KUBECONFIG get all -n anthos-identity-service
Sostituisci CLUSTER_KUBECONFIG
con il percorso del kubeconfig del cluster.
Configurare il supporto delle identità di terze parti per i gruppi
Se il tuo cluster o parco risorse è già configurato per l'assistenza di Google Gruppi, non sono previsti passaggi aggiuntivi e puoi passare alla sezione Concedere ruoli IAM a utenti e gruppi di terze parti.
Se utilizzi GKE su Bare Metal o GKE su VMware, il modo in cui configuri GKE Identity Service determina come devi configurare la funzionalità dei gruppi di terze parti.
Se è la prima volta che utilizzi GKE Identity Service, puoi scegliere se configurare il supporto per i gruppi di terze parti utilizzando le API del parco risorse (opzione consigliata) o utilizzare kubectl.
Se non utilizzi GKE Identity Service per la prima volta, tieni presente una delle seguenti azioni:
- 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 è abilitata per impostazione predefinita. Consulta la sezione Il parco risorse di seguito per ulteriori dettagli ed eventuali configurazioni aggiuntive che potresti richiedere.
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 ai gruppi di terze parti utilizzando le API delle funzionalità del parco risorse.
Console
Se non hai ancora 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
Nella console Google Cloud, vai alla pagina Funzionalità di GKE Enterprise.
Nella tabella Funzionalità, fai clic su Dettagli nella riga Servizio di identità. Vengono visualizzati i dettagli del cluster del progetto.
Fai clic su Aggiorna servizio di identità per aprire il riquadro di configurazione.
Seleziona i cluster che vuoi configurare. Puoi scegliere singoli cluster o specificare che tutti i cluster devono essere configurati con la stessa configurazione delle identità.
Nella sezione Configura provider di identità, puoi scegliere di conservare, aggiungere, aggiornare o rimuovere un provider di identità.
Fai clic su Continua per procedere con il passaggio di configurazione successivo. Se hai selezionato almeno un cluster idoneo per questa configurazione, viene visualizzata la sezione Autenticazione Google.
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 campo Proxy.
Fai clic su Aggiorna configurazione. Questa azione applica la configurazione delle identità ai cluster selezionati.
gcloud
Se non hai ancora configurato GKE Identity Service per un parco risorse, segui le istruzioni 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
Configurazione dell'accesso a gruppi di terze parti mediante un proxy
Se devi accedere al provider di identità tramite un proxy, utilizza un campo proxy
nel file auth-config.yaml
. Potrebbe essere necessario impostare questa opzione se, ad esempio, il 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 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
Applicare 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 del tuo cluster all'interno del parco risorse.
Una volta applicata, questa configurazione viene gestita dal controller del servizio GKE Identity. Le modifiche locali apportate alla configurazione del client del servizio GKE Identity sono riconciliate dal controller con la configurazione specificata in questa configurazione.
kubectl
Per configurare il cluster per l'utilizzo di GKE Identity Service con la funzionalità gruppi di terze parti, devi aggiornare GKE Identity Service ClientConfig
del cluster.
Questo è un tipo di risorsa personalizzata (CRD) 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 della configurazione.
Per modificare la configurazione, utilizza il comando seguente.
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default
Se in kubeconfig sono presenti più contesti, viene utilizzato quello corrente. Potrebbe essere necessario reimpostare il contesto attuale sul 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'appartenenza al 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
Concede 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
.
- Se gli utenti hanno bisogno solo dell'accesso di sola lettura ai cluster connessi, è possibile utilizzare
roles/gkehub.viewer
. Questo ruolo consente agli utenti di visualizzare le appartenenze al cluster registrate.
Di seguito viene illustrato 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 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 seguenti:roles/gkehub.gatewayAdmin
,roles/gkehub.gatewayReader
ogkehub.gatewayEditor
.WORKFORCE_POOL_ID
: è l'ID 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 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 seguenti:roles/gkehub.gatewayAdmin
,roles/gkehub.gatewayReader
ogkehub.gatewayEditor
.WORKFORCE_POOL_ID
: è l'ID del pool di forza lavoro.GROUP_ID
: è un gruppo nell'attestazionegoogle.groups
mappata.
Fai riferimento alla configurazione del tuo provider di identità indicata in Configurare mappature di terze parti utilizzando l'identità della forza lavoro per ulteriori personalizzazioni, ad esempio per specificare gli attributi del dipartimento, quando applichi 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 criteri per controllo dell'accesso basato sui ruoli (RBAC)
Infine, il server API Kubernetes di ciascun cluster deve essere in grado di autorizzare i comandi kubectl
provenienti dal gateway di utenti e gruppi di terze parti specificati. Per ogni cluster, devi aggiungere un criterio di autorizzazione RBAC che specifica le autorizzazioni del soggetto sul cluster.
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 ai ruoli/clusterrole per un utente di terze parti. In questo caso, segui questi passaggi di configurazione di 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
in un cluster in cui è configurato GKE Identity Service. Puoi quindi salvare il file del criterio 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ù sulla specifica delle autorizzazioni RBAC in Utilizzo dell'autorizzazione RBAC.
Che cosa succede dopo?
- Scopri come utilizzare il gateway Connect per connetterti ai cluster dalla riga di comando.
- Per un esempio di come utilizzare il gateway Connect come parte dell'automazione DevOps, consulta il nostro tutorial Integrazione con Cloud Build.