Configura il gateway Connect

Questa guida è rivolta agli amministratori di piattaforma che devono configurare il gateway Connect affinché gli utenti e gli account di servizio del loro progetto. Questa configurazione consente agli utenti di:

  • Usa la console Google Cloud per accedere ai cluster registrati all'esterno Google Cloud con la propria identità Google Cloud.

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

Questa configurazione consente solo l'autenticazione di utenti e servizi in base ai loro ID individuali, non la loro appartenenza a Google Gruppi. Per impostare ulteriori gruppo di supporto, vedi Configura il gateway Connect con Google Gruppi.

Se non hai dimestichezza con il gateway Connect, consulta la nostra panoramica per una spiegazione degli concetti di base e come funziona.

Prima di iniziare

  1. Assicurati di avere installato i seguenti strumenti a riga di comando:

    • L'ultima versione di Google Cloud CLI, a riga di comando per interagire con Google Cloud.
    • kubectl per l'esecuzione di comandi sui cluster Kubernetes. Per installa kubectl, segui queste istruzioni

    Se utilizzi Cloud Shell come ambiente shell per l'interazione Google Cloud, questi strumenti sono installati per te.

  2. Inizializza il file gcloud CLI per l'uso con il tuo progetto oppure esegui seguenti comandi per autorizzare gcloud CLI e impostare 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 del progetto di concederti le autorizzazioni specifiche per il progetto, in modo da poter eseguire le attività seguenti:

  • Per abilitare le API devi avere l'autorizzazione serviceusage.services.enable, che è incluso nel Amministratore Service Usage ruolo (roles/serviceusage.serviceUsageAdmin). Un proprietario del progetto può crea un ruolo personalizzato con serviceusage.services.enable autorizzazione attivata o concediti roles/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 per usare il gateway Connect, è necessario Amministratore IAM progetto ruolo (roles/resourcemanager.projectIamAdmin), che un proprietario del progetto può 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 progetto, abilita l'API Connect gateway e i relativi le API di dipendenza richieste. Se i tuoi utenti vogliono autenticarsi solo sui cluster utilizzando la console Google Cloud, non devi 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 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). Il campo obbligatorio I ruoli IAM 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

Gli utenti e gli account di servizio devono avere 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 al gateway Connect API per utilizzare kubectl per gestire il cluster.

    • Se un utente ha bisogno dell'accesso di sola lettura ai cluster connessi, puoi concedere roles/gkehub.gatewayReader in alternativa.

    • Se un utente ha bisogno dell'accesso in lettura / scrittura ai cluster connessi, puoi concedi 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 nel documentazione di 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, presente in 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.

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 console Google Cloud

Utenti che vogliono interagire con cluster esterni a Google Cloud usando la console Google Cloud Per visualizzare i cluster sono necessari almeno i seguenti ruoli IAM:

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

  • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster esterni nella console Google Cloud. Tieni presente che si tratta di una dei ruoli richiesti per l'accesso kubectl. Se l'hai già concesso ruolo predefinito a un utente, non dovrai concederlo di nuovo. Per maggiori dettagli sui autorizzazioni incluse in questo ruolo, consulta Ruoli GKE Hub nel documentazione di 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 saperne di più 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 provenienti dalla console Google Cloud o dai comandi kubectl provenienti dagli utenti e dal servizio specificati attraverso il gateway . Per farlo, devi aggiornare il controllo dell'accesso basato sui ruoli (RBAC) su ciascun cluster che vuoi rendere accessibile tramite gateway VPN ad alta disponibilità. Devi aggiungere o aggiornare i seguenti criteri:

  • Le norme relative al furto d'identità che autorizza l'agente Connect di inviare richieste al server API Kubernetes per conto di un utente.
  • Un criterio di autorizzazione che specifica le autorizzazioni di cui dispone l'utente sulla in un cluster Kubernetes. Può essere un ruolo a livello di cluster come clusterrole/cluster-admin o clusterrole/cloud-console-reader oppure un ruolo a livello di spazio dei nomi, ad esempio role/default/pod-reader.

(Facoltativo) Crea un ruolo cloud-console-reader

Utenti autenticati che vogliono accedere alle risorse di un cluster nella console Google Cloud devi disporre delle autorizzazioni Kubernetes pertinenti per farlo. Se non vuoi concedere a questi utenti autorizzazioni più estese, ad esempio 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 le autorizzazioni creando una risorsa RBAC ClusterRole, cloud-console-reader, nel cluster.

cloud-console-reader concede ai propri utenti get, list e watch autorizzazioni su nodi, volumi permanenti, pod e classi di archiviazione del cluster, che consentono di vedere dettagli su queste risorse.

kubectl

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

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 le norme appropriate per te. In alternativa, se preferisci, puoi creare una File dei criteri RBAC e applicalo 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 del parco risorse. Puoi scoprire come controllare il nome dell'appartenenza al cluster in Verificare lo stato dell'abbonamento al parco risorse.
  • ROLE: il ruolo Kubernetes che vuoi concedere agli utenti sulla un cluster, ad esempio clusterrole/cluster-admin, clusterrole/cloud-console-reader o role/mynamespace/namespace-reader. Questo ruolo deve già esistere prima di per eseguire il comando.
  • USERS: gli indirizzi email degli utenti (account utente o account di servizio) a cui vuoi concedere le autorizzazioni, come 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 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 il file kubeconfig. Puoi ottenere il contesto corrente dalla riga di comando eseguendo kubectl config current-context. Se utilizzi il modello contesto o meno, assicurati che funzioni per l'accesso al cluster esegui 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 c'è qualcosa di simile al seguente, che è troncato per migliorare la 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 il gateway Connect.

Per ulteriori dettagli sul comando generate-gateway-rbac, consulta le guida di riferimento di gcloud CLI.

Se visualizzi un errore come ERROR: (gcloud.container.hub.memberships) Invalid choice: 'generate-gateway-rbac' quando esegui questo comando, aggiorna Google Cloud CLI seguendo 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

Puoi trovare ulteriori informazioni 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 protezione per Servizi Google Cloud indipendenti da Identity and Access Management (IAM). Sebbene IAM consenta un livello di analisi granulare dei controlli degli accessi, Controlli di servizio VPC consente un perimetro basato sul contesto , incluso il controllo del traffico in uscita dei dati attraverso il perimetro, Ad esempio, puoi specificare che solo alcuni progetti possano accedere Dati BigQuery. Scopri di più su come funzionano i Controlli di servizio VPC per proteggere i tuoi dati nella Panoramica dei 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.

Passaggi successivi