Configurare Connect Gateway

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

  • Utilizza la Google Cloud console per accedere ai cluster registrati al di fuori diGoogle Cloud Google Cloud con la loro Google Cloud identità.

  • Utilizza kubectl per accedere ai cluster tramite Connect Gateway.

Questa configurazione consente l'autenticazione di utenti e servizi solo in base ai loro ID individuali, non alla loro appartenenza a Google Gruppi. Per configurare un supporto aggiuntivo per i gruppi, consulta Configurare Connect Gateway con Google Gruppi.

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

Prima di iniziare

  1. Assicurati di avere 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 istruzioni

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

  2. 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 progetto. Se non sei un proprietario del progetto, chiedi a un proprietario del progetto di concederti autorizzazioni aggiuntive sul progetto in modo da poter svolgere le seguenti attività:

  • Per abilitare le API, devi disporre dell'autorizzazione serviceusage.services.enable, che è inclusa nel ruolo Amministratore utilizzo dei servizi (roles/serviceusage.serviceUsageAdmin). Un proprietario del progetto può creare un ruolo personalizzato con l'autorizzazione serviceusage.services.enable abilitata o concederti il ruolo roles/serviceusage.serviceUsageAdmin nel seguente modo:

    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 del 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 progetto, abilita l'API Connect Gateway e le API di dipendenza obbligatorie. Se i tuoi utenti vogliono autenticarsi ai cluster solo utilizzando la Google Cloud console, non devi attivareconnectgateway.googleapis.com, ma devi attivare 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

Solo i cluster registrati al parco risorse del progetto possono essere accessibili tramite Connect Gateway. 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 riportate nelle nostre guide alla registrazione dei cluster. Tieni presente che i cluster GKE devono essere registrati al parco risorse per utilizzare il gateway.

Per verificare che i cluster siano stati registrati, esegui il seguente 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 accedere ai cluster nella console, come spiegato nelle sezioni seguenti. Google Cloud

Concedi i ruoli per l'accesso tramite kubectl

Come minimo, gli utenti e gli account di servizio devono disporre dei seguenti ruoli IAM per utilizzare kubectl per interagire con i cluster tramite il gateway Connect, 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 gateway Connect per utilizzare kubectl per gestire il cluster. Questo ruolo include l'autorizzazione gkehub.gateway.stream, che consente agli utenti di eseguire i comandi attach, cp e exec kubectl. Per ulteriori requisiti per l'esecuzione di questi comandi, consulta Supporto di anteprima per i comandi.

    • Se un utente ha bisogno solo di accesso di sola lettura ai cluster collegati, puoi concedere roles/gkehub.gatewayReader.

    • Se un utente ha bisogno di accesso in lettura / scrittura ai cluster collegati, puoi grant roles/gkehub.gatewayEditor.

  • roles/gkehub.viewer: questo ruolo consente a un utente di recuperare il cluster kubeconfigs.

Per informazioni dettagliate sulle autorizzazioni incluse in questi ruoli, consulta Ruoli GKE Hub nella documentazione IAM.

Per concedere questi ruoli, puoi utilizzare i seguenti comandi:

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.

Scopri di più sulla concessione di autorizzazioni e ruoli IAM in Concessione, modifica e revoca dell'accesso alle risorse.

Concedi i ruoli per l'accesso tramite la Google Cloud console

Gli utenti che vogliono interagire con i cluster al di fuori di Google Cloud utilizzando la Google Cloud console devono disporre almeno dei seguenti ruoli IAM per visualizzare i cluster:

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

  • roles/gkehub.viewer. Questo ruolo consente agli utenti di visualizzare i cluster al di fuoriGoogle Cloud nella Google Cloud console. Tieni presente che questo è uno degli accessi richiesti per kubectl. Se hai già concesso questo ruolo a un utente, non è necessario concederlo di nuovo. Per informazioni dettagliate sulle autorizzazioni incluse in questo ruolo, consulta Ruoli GKE Hub nella documentazione IAM.

    Nei comandi seguenti, sostituisci PROJECT_ID con l'ID progetto 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 IAM.

Configurare 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 comandi kubectlche passano tramite Connect Gateway dagli utenti e dagli account servizio specificati. Per assicurarti che ciò avvenga, 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 le seguenti norme:

  • Un criterio di rappresentazione 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 dispone l'utente sul cluster. 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 come role/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ù ampie, ad esempio 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 risorsa ClusterRole RBAC,cloud-console-reader nel cluster.

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

kubectl

Per creare il cloud-console-reader ClusterRole e applicarlo al cluster, esegui il comando seguente:

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 mostrato come creare e applicare i criteri RBAC richiesti. Il modo più semplice per farlo è utilizzare lgcloud 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 suo parco risorse. Puoi scoprire come controllare il nome dell'abbonamento del tuo cluster in Ottenere lo stato dell'abbonamento al parco risorse.
  • ROLE: il ruolo Kubernetes che vuoi concedere agli utenti del 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 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 è archiviato il file kubeconfig contenente una voce per il cluster. Nella maggior parte dei casi è $HOME/.kube/config.
  • KUBECONFIG_CONTEXT: il contesto del cluster così come appare nel file kubeconfig. Puoi ottenere il contesto corrente dalla riga di comando eseguendo kubectl config current-context. Indipendentemente dall'utilizzo o meno del 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, vedrai qualcosa di simile al seguente alla fine dell'output, che è troncato per 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 di connessione.

Per ulteriori 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 la tua Google Cloud CLI seguendo la guida all'aggiornamento.

kubectl

Il seguente esempio mostra come creare criteri appropriati per un utente (dana@example.com) e un account di servizio (test@example-project.iam.gserviceaccount.com), assegnando a entrambi le autorizzazionicluster-admin sul cluster e salvando il file delle norme come /tmp/gateway-rbac.yaml. I criteri vengono poi 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

Scopri di più su come specificare le 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 iGoogle Cloud servizi indipendentemente da Identity and Access Management (IAM). Sebbene IAM consenta un controllo degli accessi basato sull'identità granulare, i Controlli di servizio VPC consentono una sicurezza del perimetro basata sul contesto più ampia, incluso il controllo dell'esportazione dei dati all'interno del perimetro. Ad esempio, puoi specificare che solo determinati progetti possono accedere ai tuoi dati BigQuery. Puoi scoprire di più sul funzionamento dei Controlli di servizio VPC per proteggere i tuoi dati nella Panoramica dei Controlli di servizio VPC.

Puoi utilizzare i Controlli di servizio VPC con il gateway Connect per una maggiore sicurezza dei dati, dopo aver verificato che sia possibile accedere alle API necessarie per utilizzare il gateway dal perimetro di servizio specificato.

Passaggi successivi