Configura il gateway Connect
Questa guida è rivolta agli amministratori di piattaforma che devono configurare il gateway Connect in modo che venga utilizzato dagli utenti e dagli account di servizio del loro progetto. Questa configurazione consente agli utenti di:
Usa la console Google Cloud per accedere ai cluster registrati esterni a Google Cloud con la tua identità Google Cloud.
Usa
kubectl
per accedere ai cluster tramite il gateway Connect.
Questa configurazione consente l'autenticazione degli utenti e dei servizi solo in base ai loro singoli ID, non alla loro appartenenza a Google Gruppi. Per configurare il supporto aggiuntivo per i gruppi, vedi Configurare il gateway Connect con Google Gruppi.
Se non hai dimestichezza con il gateway Connect, consulta la nostra panoramica per una spiegazione dei concetti di base e del suo funzionamento.
Prima di iniziare
Assicurati di avere installato i seguenti strumenti a riga di comando:
- L'ultima versione di Google Cloud CLI, lo strumento a riga di comando per interagire con Google Cloud.
kubectl
per l'esecuzione di comandi sui cluster Kubernetes. Se devi installarekubectl
, segui queste instructions
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti sono installati automaticamente.
initialize l'interfaccia alla gcloud CLI per utilizzarla con il tuo progetto oppure esegui questi comandi per autorizzare gcloud CLI e impostare il tuo progetto come predefinito:
gcloud auth login gcloud config set project PROJECT_ID
Ruoli IAM richiesti per la configurazione
Questa guida presuppone che tu disponga dell'autorizzazione roles/owner
nel tuo progetto.
Se non sei un proprietario del progetto, chiedi a un proprietario di concederti autorizzazioni aggiuntive sul progetto in modo da poter eseguire le seguenti attività:
Per abilitare le API, devi disporre dell'autorizzazione
serviceusage.services.enable
, inclusa nel ruolo di Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin
). Un proprietario del progetto può creare un ruolo personalizzato con l'autorizzazioneserviceusage.services.enable
abilitata oppure concedertiroles/serviceusage.serviceUsageAdmin
, come segue:gcloud projects add-iam-policy-binding PROJECT_ID \ --member user:USER_EMAIL_ADDRESS \ --role='roles/serviceusage.serviceUsageAdmin'
Per concedere autorizzazioni IAM a utenti e account di servizio in modo che possano utilizzare il gateway Connect, devi disporre del ruolo Amministratore IAM progetto (
roles/resourcemanager.projectIamAdmin
), che un proprietario del progetto può concedere con il seguente comando:gcloud projects add-iam-policy-binding PROJECT_ID \ --member user:USER_EMAIL_ADDRESS \ --role='roles/resourcemanager.projectIamAdmin'
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 devi abilitare le altre API.
gcloud services enable --project=PROJECT_ID \
connectgateway.googleapis.com \
anthos.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com
Verifica i cluster registrati
È possibile accedere tramite il gateway Connect solo ai cluster registrati nel parco risorse del progetto. I cluster GKE on-premise e su altri cloud pubblici vengono registrati automaticamente al momento della creazione. Tuttavia, i cluster GKE su Google Cloud e i cluster collegati devono essere registrati separatamente. Se devi registrare un cluster, segui le istruzioni nelle nostre guide alla registrazione dei cluster. Tieni presente che i cluster GKE devono essere registrati nel parco risorse per utilizzare il gateway.
Per verificare che i cluster siano stati registrati, esegui questo comando:
gcloud container fleet memberships list
Dovresti vedere un elenco di tutti i cluster registrati, come in questo output di esempio:
NAME EXTERNAL_ID
cluster-1 0192893d-ee0d-11e9-9c03-42010a8001c1
cluster-2 f0e2ea35-ee0c-11e9-be79-42010a8400c2
Concede ruoli IAM agli utenti
L'accesso ai cluster è controllato da Identity and Access Management (IAM). I ruoli IAM richiesti per accedere ai cluster utilizzando kubectl
sono leggermente diversi dai ruoli per accedere ai cluster nella console Google Cloud, come spiegato nelle sezioni seguenti.
Concedi ruoli per l'accesso tramite kubectl
Come minimo, gli utenti e gli account di servizio devono avere i seguenti ruoli IAM per utilizzare kubectl
per interagire con i cluster tramite il gateway Connect, a meno che l'utente non abbia roles/owner
nel progetto:
roles/gkehub.gatewayAdmin
: questo ruolo consente a un utente di accedere all'API Connect gateway per utilizzarekubectl
al fine di gestire il cluster.Se un utente ha bisogno dell'accesso di sola lettura ai cluster connessi, puoi invece concedere
roles/gkehub.gatewayReader
.Se un utente ha bisogno dell'accesso in lettura / scrittura ai cluster connessi, puoi concedere
roles/gkehub.gatewayEditor
.
roles/gkehub.viewer
: questo ruolo consente a un utente di recuperare il clusterkubeconfigs
.
Per maggiori dettagli sulle autorizzazioni incluse in questi ruoli, consulta Ruoli GKE Hub nella documentazione IAM.
Per concedere questi ruoli puoi utilizzare i comandi seguenti:
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=GATEWAY_ROLE
gcloud projects add-iam-policy-binding PROJECT_ID \
--member=MEMBER \
--role=roles/gkehub.viewer
dove:
MEMBER
è l'account utente o di servizio, che ha il formatouser|serviceAccount:emailID
, ad esempio:user:alice@example.com
serviceAccount:test_sa@example-project.iam.gserviceaccount.com
GATEWAY_ROLE
èroles/gkehub.gatewayAdmin
,roles/gkehub.gatewayReader
oroles/gkehub.gatewayEditor
.
Per saperne di più sulla concessione delle autorizzazioni e dei ruoli IAM, consulta Concessione, modifica e revoca dell'accesso alle risorse.
Concedi ruoli per l'accesso tramite la console Google Cloud
Gli utenti che vogliono interagire con cluster esterni a Google Cloud utilizzando la console Google Cloud devono avere almeno i seguenti ruoli IAM per visualizzare i cluster:
roles/container.viewer
. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse container nella console Google Cloud. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo, vedi Ruoli di Kubernetes Engine nella documentazione IAM.roles/gkehub.viewer
. Questo ruolo consente agli utenti di visualizzare i cluster esterni a Google Cloud nella console Google Cloud. Tieni presente che questo è uno dei ruoli richiesti per l'accessokubectl
. Se hai già concesso questo ruolo a un utente, non è necessario concederlo di nuovo. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE Hub nella documentazione IAM.Nei comandi seguenti, sostituisci
PROJECT_ID
con l'ID del progetto host del parco risorse. Inoltre, sostituisciMEMBER
con l'indirizzo email o l'account di servizio dell'utente utilizzando il formatouser|serviceAccount:emailID
, ad esempio:user:alice@example.com
serviceAccount:test_sa@example-project.iam.gserviceaccount.com
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/container.viewer gcloud projects add-iam-policy-binding PROJECT_ID \ --member=MEMBER \ --role=roles/gkehub.viewer
Per ulteriori informazioni sulla concessione dei ruoli IAM, consulta Gestire l'accesso a progetti, cartelle e organizzazioni nella documentazione di IAM.
Configura autorizzazione RBAC
Il server API Kubernetes di ogni cluster deve essere in grado di autorizzare le richieste provenienti dalla console Google Cloud o dai comandi kubectl
che arrivano tramite il gateway Connect dagli utenti e dagli account di servizio specificati. Per farlo, devi aggiornare i criteri di controllo dell'accesso dell'accesso basato sui ruoli (RBAC) in ogni cluster che vuoi rendere accessibile tramite il gateway. Devi aggiungere o aggiornare i seguenti criteri:
- Un criterio relativo al furto d'identità che autorizza l'agente Connect a inviare richieste al server API Kubernetes per conto di un utente.
- Un criterio di autorizzazione che specifica le autorizzazioni di cui l'utente dispone sul cluster. Può essere un ruolo a livello di cluster come
clusterrole/cluster-admin
oclusterrole/cloud-console-reader
oppure un ruolo a livello di spazio dei nomi comerole/default/pod-reader
.
(Facoltativo) Crea un ruolo cloud-console-reader
Gli utenti autenticati che vogliono accedere alle risorse di un cluster nella console Google Cloud devono disporre delle autorizzazioni Kubernetes pertinenti. Se non vuoi concedere a questi utenti autorizzazioni più estese, ad esempio quelle di amministratore del cluster, puoi creare un ruolo RBAC personalizzato che includa le autorizzazioni minime per visualizzare nodi, volumi permanenti, pod e classi di archiviazione del cluster. Puoi definire questo set di autorizzazioni creando una risorsa RBAC ClusterRole
, cloud-console-reader
, nel cluster.
cloud-console-reader
concede agli utenti le autorizzazioni get
, list
e watch
per nodi, volumi permanenti, pod e classi di archiviazione del cluster,
che consentono loro di visualizzare i dettagli su queste risorse.
kubectl
Per creare l'elemento cloud-console-reader
ClusterRole
e applicarlo al cluster, esegui questo comando:
cat <<EOF > cloud-console-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: cloud-console-reader
rules:
- apiGroups: [""]
resources: ["nodes", "persistentvolumes", "pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
EOF
kubectl apply -f cloud-console-reader.yaml
In seguito, potrai concedere questo ruolo agli utenti durante la configurazione dei criteri di autorizzazione, come descritto nella sezione successiva.
Crea e applica i criteri RBAC richiesti
Di seguito viene illustrato come creare e applicare i criteri RBAC richiesti. Il modo più semplice per farlo è utilizzare gcloud CLI per generare e applicare i criteri appropriati per te. In alternativa, se preferisci, puoi creare un file dei criteri RBAC e applicarlo con kubectl
.
gcloud
Per generare e applicare i criteri al cluster scelto con gcloud CLI, esegui questo comando:
gcloud container fleet memberships generate-gateway-rbac \
--membership=MEMBERSHIP_NAME \
--role=ROLE \
--users=USERS \
--project=PROJECT_ID \
--kubeconfig=KUBECONFIG_PATH \
--context=KUBECONFIG_CONTEXT \
--apply
Sostituisci quanto segue:
- MEMBERSHIP_NAME: il nome utilizzato per rappresentare in modo univoco il cluster nel parco risorse. Puoi scoprire come controllare il nome dell'appartenenza al cluster in Ottenere lo stato dell'abbonamento al parco risorse.
- ROLE: il ruolo Kubernetes che vuoi concedere agli utenti nel cluster, ad esempio
clusterrole/cluster-admin
,clusterrole/cloud-console-reader
orole/mynamespace/namespace-reader
. Questo ruolo deve già esistere prima di eseguire il comando. - USERS: gli indirizzi email degli utenti (account utente o account di servizio) a cui vuoi concedere le autorizzazioni, sotto forma di elenco separato da virgole. Ad esempio:
--users=foo@example.com,test-acct@test-project.iam.gserviceaccount.com
. - PROJECT_ID: l'ID progetto in cui è registrato il cluster.
- KUBECONFIG_PATH: il percorso file locale in cui è archiviato
kubeconfig contenente una voce per il cluster. Nella maggior parte dei casi è
$HOME/.kube/config
. KUBECONFIG_CONTEXT: il contesto del cluster come appare nel file kubeconfig. Puoi ottenere il contesto attuale dalla riga di comando eseguendo il comando
kubectl config current-context
. Indipendentemente dal fatto che utilizzi o meno il contesto corrente, assicurati che funzioni per accedere al cluster eseguendo questo comando:kubectl get namespaces \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT
Dopo aver eseguito gcloud container fleet memberships generate-gateway-rbac
, alla fine dell'output verrà visualizzato un risultato simile al seguente:
connectgateway_example-project-12345_global_example-membership-name
Questo è il contesto per accedere al cluster tramite il gateway Connect.
Per maggiori dettagli sul comando generate-gateway-rbac
, consulta la guida di riferimento dell'interfaccia a riga di comando gcloud.
Se visualizzi un errore di tipo ERROR: (gcloud.container.hub.memberships)
Invalid choice: 'generate-gateway-rbac'
quando esegui questo comando, aggiorna
Google Cloud CLI seguendo la
guida agli aggiornamenti.
kubectl
L'esempio seguente mostra come creare criteri appropriati per un utente (foo@example.com
) e un account di servizio (test@example-project.iam.gserviceaccount.com
), concedendo a entrambi le autorizzazioni cluster-admin
per il cluster e salvando il file del criterio come /tmp/gateway-rbac.yaml
. I criteri vengono quindi applicati al cluster associato al contesto attuale:
cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: gateway-impersonate
rules:
- apiGroups:
- ""
resourceNames:
- foo@example.com
- test@example-project.iam.gserviceaccount.com
resources:
- users
verbs:
- impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: gateway-impersonate
roleRef:
kind: ClusterRole
name: gateway-impersonate
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: connect-agent-sa
namespace: gke-connect
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: gateway-cluster-admin
subjects:
- kind: User
name: foo@example.com
- kind: User
name: test@example-project.iam.gserviceaccount.com
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
EOF
# Apply policies to the cluster.
kubectl apply --kubeconfig=KUBECONFIG_PATH -f /tmp/gateway-rbac.yaml
Per ulteriori informazioni sulla specifica delle autorizzazioni RBAC, consulta Utilizzo dell'autorizzazione RBAC.
Supporto dei Controlli di servizio VPC
I Controlli di servizio VPC forniscono un ulteriore livello di protezione per i servizi Google Cloud, indipendente da Identity and Access Management (IAM). Mentre IAM consente un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC offrono una più ampia sicurezza perimetrale basata sul contesto, compreso il controllo del traffico in uscita dei dati attraverso il perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Per saperne di più su come funzionano i Controlli di servizio VPC per proteggere i tuoi dati, consulta la Panoramica sui Controlli di servizio VPC.
Puoi utilizzare Controlli di servizio VPC con il gateway Connect per una maggiore sicurezza dei dati, dopo aver verificato che le API necessarie per utilizzare il gateway siano accessibili dall'interno del perimetro di servizio specificato.
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.