Questa guida è rivolta agli amministratori della piattaforma che devono configurare Connect Gateway per l'utilizzo da parte degli utenti e dei service account del loro progetto. Questa configurazione consente agli utenti di:
Utilizzare la Google Cloud consoleper accedere ai cluster registrati esterni Google Cloud con la propria Google Cloud identità.
Utilizzare
kubectlper accedere ai cluster tramite Connect Gateway.
Questa configurazione consente solo l'autenticazione di utenti e servizi in base ai loro ID individuali, non alla loro appartenenza a gruppi Google. Per configurare il supporto aggiuntivo per i gruppi, consulta Configura Connect Gateway con Google Gruppi.
Se non hai familiarità con Connect Gateway, consulta la nostra panoramica per una spiegazione dei concetti di base e del suo funzionamento.
Prima di iniziare
Assicurati di aver 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.
kubectlper eseguire comandi sui cluster Kubernetes. Se devi installarekubectl, segui queste istruzioni
Se utilizzi Cloud Shell come ambiente shell per interagire con Google Cloud, questi strumenti vengono installati automaticamente.
Inizializza gcloud CLI per l'utilizzo con il tuo progetto oppure esegui i seguenti 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 il proprietario del progetto, chiedi a un proprietario del progetto di concederti autorizzazioni aggiuntive sul progetto in modo che tu possa svolgere le seguenti attività:
Per abilitare le API, devi disporre dell'autorizzazione
serviceusage.services.enable, inclusa nel ruolo Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin). Un proprietario del progetto può creare un ruolo personalizzato con l'autorizzazioneserviceusage.services.enableabilitata 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 service account in modo che possano utilizzare Connect Gateway, 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 API
Per aggiungere il gateway al tuo progetto, abilita l'API Connect Gateway e le API di dipendenza richieste. Se gli utenti vogliono autenticarsi solo ai cluster
utilizzando la Google Cloud console, non devi abilitare
connectgateway.googleapis.com, ma devi abilitare le altre API.
gcloud services enable --project=PROJECT_ID \
connectgateway.googleapis.com \
gkeconnect.googleapis.com \
gkehub.googleapis.com \
cloudresourcemanager.googleapis.com
Verifica i cluster registrati
È possibile accedere tramite Connect Gateway 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 il seguente comando:
gcloud container fleet memberships list
Dovresti visualizzare 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
Concedi 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 differiscono leggermente
dai ruoli per accedere ai cluster nella Google Cloud console, come spiegato
nelle sezioni seguenti.
Concedi ruoli per l'accesso tramite kubectl
Come minimo, gli utenti e i service account devono disporre dei
seguenti ruoli IAM per utilizzare kubectl per interagire con i cluster
tramite Connect Gateway, a meno che l'utente non disponga di roles/owner nel progetto:
roles/gkehub.gatewayAdmin: questo ruolo consente a un utente di accedere all'API Connect Gateway per utilizzarekubectlper gestire il cluster. Questo ruolo include l'autorizzazionegkehub.gateway.stream, che consente agli utenti di eseguire i comandikubectlattach,cpedexec. Per ulteriori requisiti per l'esecuzione di questi comandi, consulta Supporto in anteprima per i comandi.Se un utente ha bisogno solo dell'accesso in lettura ai cluster connessi, puoi concedere invece
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 ikubeconfigsdel cluster.
Per i dettagli sulle autorizzazioni incluse in questi ruoli, consulta Ruoli di GKE Hub nella documentazione IAM.
Puoi utilizzare i seguenti comandi per concedere questi ruoli:
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'utente o il account di servizio, nel formatouser|serviceAccount:emailID, ad esempio:user:alice@example.comserviceAccount:test_sa@example-project.iam.gserviceaccount.com
GATEWAY_ROLEèroles/gkehub.gatewayAdmin,roles/gkehub.gatewayReaderoroles/gkehub.gatewayEditor.
Puoi scoprire di più sulla concessione di autorizzazioni e ruoli IAM in Concessione, modifica e revoca dell'accesso alle risorse.
Concedi ruoli per l'accesso tramite la Google Cloud console
Gli utenti che vogliono interagire con i cluster esterni utilizzando la console devono disporre dei seguenti ruoli IAM come minimo per visualizzare i cluster: Google CloudGoogle Cloud
roles/container.viewer. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse container nella Google Cloud console. Per i dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli di Kubernetes Engine nella documentazione IAM.roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster esterni Google Cloud nella Google Cloud console. Tieni presente che questo è uno dei ruoli richiesti per l'accessokubectl. Se hai già concesso questo ruolo a un utente, non devi concederlo di nuovo. Per i dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli di GKE Hub nella documentazione IAM.Nei comandi seguenti, sostituisci
PROJECT_IDcon l'ID progetto del progetto host del parco risorse. Inoltre, sostituisciMEMBERcon l'indirizzo email dell'utente o il account di servizio utilizzando il formatouser|serviceAccount:emailID, ad esempio:user:alice@example.comserviceAccount: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 saperne di più sulla concessione dei ruoli IAM, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni nella documentazione IAM.
Configura l'autorizzazione RBAC
Il server API Kubernetes di ogni cluster deve essere in grado di autorizzare
le richieste provenienti dalla Google Cloud console o dai kubectl comandi
che passano attraverso Connect Gateway dagli utenti e dai service
account specificati. Per assicurarti che ciò avvenga, devi aggiornare i criteri di controllo dell'accesso basato sui ruoli (RBAC) su ogni cluster a cui vuoi rendere accessibile tramite il gateway. Devi aggiungere o aggiornare i seguenti criteri:
- Un criterio di rappresentazione che autorizza l'agente Connect a inviare richieste al server API Kubernetes per conto di un utente.
- Un criterio di autorizzazioni che specifica le autorizzazioni di cui dispone l'utente sul cluster. Può trattarsi di un ruolo a livello di cluster come
clusterrole/cluster-adminoclusterrole/cloud-console-readeroppure di 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 Google Cloud console
devono disporre delle autorizzazioni Kubernetes pertinenti. Se non vuoi concedere a questi utenti autorizzazioni più estese, come quelle di un amministratore del cluster, puoi creare un ruolo RBAC personalizzato che includa le autorizzazioni minime per visualizzare i nodi, i volumi permanenti, i pod e le classi di archiviazione del cluster. Puoi definire questo insieme di
autorizzazioni creando una ClusterRole risorsa RBAC,
cloud-console-reader, nel cluster.
cloud-console-reader concede ai suoi utenti le autorizzazioni get, list e watch sui nodi, sui volumi permanenti, sui pod e sulle classi di archiviazione del cluster, consentendo loro di visualizzare i dettagli di queste risorse.
kubectl
Per creare ClusterRole cloud-console-reader e applicarlo al cluster, esegui il seguente 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
Puoi quindi 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. In alternativa, se preferisci, puoi creare un file di criteri RBAC e applicarlo con kubectl.
gcloud
Per generare e applicare i criteri al cluster scelto con gcloud CLI, esegui il seguente 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 relativo parco risorse. Puoi scoprire come controllare il nome di appartenenza del cluster in Controlla lo stato di appartenenza al parco risorse.
- ROLE: il ruolo Kubernetes che vuoi concedere agli utenti del 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
service account) a cui vuoi concedere le autorizzazioni, come elenco
separato da virgole. Ad esempio:
--users=dana@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 è memorizzato il kubeconfig
contenente una voce per il cluster. Nella maggior parte dei casi è
$HOME/.kube/config. KUBECONFIG_CONTEXT: il contesto del cluster così come appare in nel file kubeconfig. Puoi recuperare il contesto corrente dalla riga di comando eseguendo
kubectl config current-context. Indipendentemente dal fatto che utilizzi o meno il contesto corrente, assicurati che funzioni per accedere al cluster eseguendo il seguente comando:kubectl get namespaces \ --kubeconfig=KUBECONFIG_PATH \ --context=KUBECONFIG_CONTEXT
Dopo aver eseguito gcloud container fleet memberships generate-gateway-rbac, alla fine dell'output viene visualizzato un messaggio simile al seguente, troncato per motivi di leggibilità
Validating input arguments. Specified Cluster Role is: clusterrole/cluster-admin Generated RBAC policy is: -------------------------------------------- ... --- Applying the generate RBAC policy to cluster with kubeconfig: artifacts/kubeconfig, context: example-cluster-admin@example-cluster Writing RBAC policy for user: 222larabrown@gmail.com to cluster. Successfully applied the RBAC policy to cluster.
Questo è il contesto per accedere al cluster tramite Connect Gateway.
Per maggiori dettagli sul comando generate-gateway-rbac, consulta la
guida di riferimento di gcloud CLI.
kubectl
L'esempio seguente mostra come creare criteri appropriati per un utente (dana@example.com) e un account di servizio (test@example-project.iam.gserviceaccount.com), concedendo a entrambi le autorizzazioni cluster-admin sul cluster e salvando il file dei criteri come /tmp/gateway-rbac.yaml. I criteri vengono quindi applicati al cluster associato al contesto corrente:
cat <<EOF > /tmp/gateway-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: gateway-impersonate
rules:
- apiGroups:
- ""
resourceNames:
- dana@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: dana@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
Puoi scoprire di più sulla specifica delle autorizzazioni RBAC in Utilizzo dell'autorizzazione RBAC.
Supporto dei Controlli di servizio VPC
I Controlli di servizio VPC forniscono un livello aggiuntivo di difesa della sicurezza per Google Cloud i servizi, indipendente da Identity and Access Management (IAM). Mentre IAM consente un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC consentono una sicurezza perimetrale basata sul contesto più ampia, che include il controllo dell'uscita dei dati dal perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Puoi scoprire di più su come i Controlli di servizio VPC proteggono i tuoi dati nella panoramica dei Controlli di servizio VPC.
Puoi utilizzare i Controlli di servizio VPC con Connect Gateway per una maggiore sicurezza dei dati, dopo aver verificato che sia possibile accedere alle API necessarie per utilizzare il gateway dall'interno del perimetro di servizio specificato.
Passaggi successivi
- Scopri come utilizzare Connect Gateway per connetterti ai cluster dalla riga di comando.
- Consulta un esempio di come utilizzare Connect Gateway come parte dell'automazione DevOps nel nostro tutorial Integrazione con Cloud Build.