Configurazione di Connect Gateway

Questa guida è rivolta agli amministratori di piattaforma che devono configurare il gateway di Connect per l'utilizzo da parte degli utenti e degli account di servizio del loro progetto. Questa configurazione consente agli utenti di:

  • Utilizza la console Google Cloud per accedere ai cluster registrati all'esterno di Google Cloud con la loro Google Cloud Identity.

  • Usa kubectl per accedere ai cluster tramite il gateway Connect.

Questa configurazione consente l'autenticazione di utenti e servizi solo in base ai loro singoli ID, non alla loro iscrizione a Google Gruppi. Per configurare ulteriore supporto per i gruppi, vedi Configurare il gateway di Connect con Google Gruppi.

Se non hai dimestichezza con il gateway di Connect, consulta la nostra panoramica per una spiegazione dei concetti di base e del suo funzionamento.

Prima di iniziare

  1. 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.
    • kubectl per eseguire comandi sui cluster Kubernetes. Se devi installare kubectl, segui queste instructions

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

  2. initialize gcloud CLI per utilizzarlo con il tuo progetto oppure esegui i comandi seguenti 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 progetto. Se non sei un proprietario del progetto, chiedi a un proprietario di concederti ulteriori autorizzazioni per il progetto in modo che tu possa svolgere le seguenti attività:

  • Per abilitare le API, devi avere l'autorizzazione serviceusage.services.enable, che è inclusa nel ruolo Amministratore Service Usage (roles/serviceusage.serviceUsageAdmin). Un proprietario del progetto può creare un ruolo personalizzato con l'autorizzazione serviceusage.services.enable abilitata o concederti roles/serviceusage.serviceUsageAdmin come segue:

    gcloud projects add-iam-policy-binding PROJECT_ID \
   --member user:USER_EMAIL_ADDRESS \
   --role='roles/serviceusage.serviceUsageAdmin'

  • Per concedere le 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 progetti. 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 ai 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 nell'output di questo 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 da quelli per l'accesso ai cluster nella console Google Cloud, come spiegato nelle sezioni seguenti.

Concedi ruoli per l'accesso tramite kubectl

In minima parte, utenti e account di servizio devono disporre dei seguenti ruoli IAM per utilizzare kubectl per interagire con i cluster tramite il gateway di 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 utilizzare kubectl per gestire il cluster.

    • Se un utente ha bisogno solo dell'accesso di sola lettura ai cluster connessi, puoi 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 cluster kubeconfigs.

Per maggiori dettagli sulle autorizzazioni incluse in questi ruoli, consulta Ruoli 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'account utente o di servizio, nel formato user|serviceAccount:emailID, ad esempio:

    • user:alice@example.com
    • serviceAccount:test_sa@example-project.iam.gserviceaccount.com

  • GATEWAY_ROLE è roles/gkehub.gatewayAdmin, roles/gkehub.gatewayReader o roles/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 disporre almeno dei seguenti ruoli IAM per visualizzare i cluster:

  • roles/container.viewer. Questo ruolo consente agli utenti di visualizzare la pagina Cluster GKE e altre risorse dei container nella console Google Cloud. Per maggiori dettagli sulle autorizzazioni incluse in questo ruolo, consulta Ruoli Kubernetes Engine nella documentazione IAM.

  • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster all'esterno di Google Cloud nella console Google Cloud. Tieni presente che questo è uno dei ruoli richiesti per l'accesso a kubectl. 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, sostituisci MEMBER con l'indirizzo email o l'account di servizio dell'utente utilizzando il formato user|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 l'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 provenienti tramite il gateway di 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) su 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 di connessione 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 o clusterrole/cloud-console-reader o un ruolo a livello di spazio dei nomi come role/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 per farlo. 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 nodi, volumi permanenti, pod e classi di archiviazione del cluster. Puoi definire questo insieme di autorizzazioni creando una risorsa ClusterRole RBAC, cloud-console-reader, nel cluster.

cloud-console-reader concede agli utenti le autorizzazioni get, list e watch su nodi, volumi permanenti, pod e classi di archiviazione del cluster, che consentono loro di visualizzare i dettagli di queste risorse.

kubectl

Per creare l'ClusterRole cloud-console-reader 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

Puoi quindi concedere questo ruolo agli utenti quando imposti i criteri di autorizzazione, come descritto nella sezione successiva.

Crea e applica i criteri RBAC richiesti

Di seguito viene mostrato 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 di 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 relativo parco risorse. Per informazioni su come verificare il nome dell'appartenenza del cluster, consulta Ottieni lo stato dell'abbonamento del parco risorse.
  • ROLE: il ruolo Kubernetes che vuoi concedere agli utenti nel cluster, ad esempio clusterrole/cluster-admin, clusterrole/cloud-console-reader o role/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 il file kubeconfig contenente una voce per il cluster. Nella maggior parte dei casi è $HOME/.kube/config.

  • KUBECONFIG_CONTEXT: il contesto del cluster come viene visualizzato nel file kubeconfig. Puoi ottenere il contesto attuale dalla riga di comando eseguendo kubectl config current-context. Che tu utilizzi o meno il contesto attuale, assicurati che funzioni per l'accesso al cluster eseguendo un semplice comando come:

    kubectl get namespaces \
  --kubeconfig=KUBECONFIG_PATH \
  --context=KUBECONFIG_CONTEXT

Dopo aver eseguito gcloud container fleet memberships generate-gateway-rbac, alla fine dell'output vedrai qualcosa di 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 viene visualizzato un errore come 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 loro entrambe 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:
  - 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

Scopri 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 ulteriore livello di difesa della sicurezza per i servizi Google Cloud, indipendente da Identity and Access Management (IAM). Sebbene IAM consenta un controllo dell'accesso basato sull'identità granulare, i Controlli di servizio VPC offrono una sicurezza perimetrale basata sul contesto più ampia, tra cui il controllo del traffico in uscita dai dati lungo il perimetro. Ad esempio, puoi specificare che solo determinati progetti possano accedere ai tuoi dati BigQuery. Per saperne di più su come i Controlli di servizio VPC proteggono i tuoi dati, consulta la Panoramica sui Controlli di servizio VPC.

Puoi utilizzare Controlli di servizio VPC con il gateway di 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?