Gestire l'accesso ai cluster standard

Questo documento spiega come gestire le autorizzazioni per i cluster standard in Google Distributed Cloud (GDC) con air gap utilizzando la CLI gdcloud. I cluster standard sono ambienti Kubernetes configurabili con ambito di progetto e servizi predefiniti minimi che offrono maggiore flessibilità e controllo per i carichi di lavoro personalizzati.

Per saperne di più sui cluster standard e su altri tipi di cluster, consulta Configurazione dei cluster Kubernetes.

Questo documento è destinato ai gruppi di operatori di applicazioni, come gli operatori di sviluppo o i data scientist, che devono gestire e proteggere le risorse all'interno dei progetti GDC. Per saperne di più, consulta Pubblico per la documentazione di GDC con air gap.

Prima di iniziare

Prima di gestire l'accesso ai cluster standard, devi disporre delle autorizzazioni necessarie e preparare l'ambiente.

Richiedi i ruoli IAM

Contatta l'amministratore IAM dell'organizzazione per richiedere i seguenti ruoli in base alle attività che devi svolgere:

  • Project IAM Admin (project-iam-admin): crea, aggiorna ed elimina le associazioni di ruoli per i cluster standard all'interno di un progetto.
  • Standard Cluster Admin (standard-cluster-admin): crea, aggiorna ed elimina le associazioni di ruoli all'interno di un cluster standard specifico.

Prepara l'ambiente

Concedi le autorizzazioni per l'accesso al cluster standard

Un utente con il ruolo Project IAM Admin (project-iam-admin) può concedere ad altri utenti i ruoli necessari per gestire l'accesso all'interno dei cluster standard:

  1. Accedi con il provider di identità configurato utilizzando gcloud CLI.

  2. Concedi all'utente il ruolo Standard Cluster Admin (standard-cluster-admin) per il progetto. Questo comando associa l'utente al ruolo, consentendogli di gestire l'accesso all'interno del cluster standard.

    Per saperne di più sui ruoli, consulta Descrizioni dei ruoli predefiniti e Definizioni dei ruoli per i progetti.

    gdcloud projects add-iam-policy-binding PROJECT \
  --role=ROLE \
  --member=user:USER_ACCOUNT

    Sostituisci le seguenti variabili:

    • PROJECT: il nome del progetto in cui esiste il cluster standard.
    • ROLE: il nome del ruolo che vuoi concedere (ad esempio standard-cluster-admin).
    • USER_ACCOUNT: l'account utente per il quale vuoi concedere il ruolo, incluso il prefisso del provider di identità associato alla tua organizzazione (ad esempio idpprefix-user@example.com). Il prefisso specifico utilizzato dipende dalla configurazione dell'IdP della tua organizzazione. Per saperne di più, consulta Connetti a un provider di identità.

    L'esempio seguente concede il ruolo Standard Cluster Admin a user@example.com, presupponendo che il prefisso del provider di identità sia fop- per il progetto foo:

    gdcloud projects add-iam-policy-binding foo \
  --role=standard-cluster-admin \
  --member=user:fop-user@example.com

Gestisci l'accesso all'interno del cluster standard

Un utente con il ruolo Standard Cluster Admin (standard-cluster-admin) può concedere l'accesso all'interno di un cluster standard:

  1. Accedi con il provider di identità configurato utilizzando gcloud CLI.

  2. Genera un file kubeconfig per un cluster standard utilizzando il flag --standard. Questo flag è obbligatorio per il targeting di un cluster standard.

    export KUBECONFIG=KUBECONFIG_FILE
gdcloud clusters get-credentials STANDARD_CLUSTER_NAME --standard --project=PROJECT

    Sostituisci le seguenti variabili:

    • KUBECONFIG_FILE: il percorso del file kubeconfig, ad esempio standard-cluster-kubeconfig.yaml.
    • STANDARD_CLUSTER_NAME: il nome del cluster standard.
    • PROJECT: il nome del progetto in cui esiste il cluster standard.

  3. Definisci le autorizzazioni all'interno del cluster standard utilizzando kubectl.

    Gli utenti con autorizzazioni standard-cluster-admin possono creare oggetti Role e ClusterRole personalizzati. Per concedere queste autorizzazioni, possono creare gli oggetti Rolebinding e ClusterRoleBinding corrispondenti per associare i ruoli a soggetti specifici, come utenti o service account.

    L'esempio seguente utilizza kubectl per creare un oggetto Role personalizzato di esempio denominato test-role nello spazio dei nomi test:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test-role
  namespace: test
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
EOF

    L'esempio seguente crea l'oggetto RoleBinding per l'oggetto Role denominato test-role nello spazio dei nomi test. Concede le autorizzazioni all'utente alice@example.com con il prefisso del provider di identità fop-, nonché a un oggetto ServiceAccount denominato my-service-account nello spazio dei nomi default:

    kubectl apply -f - <<EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test-role-binding
  namespace: test
subjects:
- kind: User
  name: fop-alice@example.com
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: test-role
  apiGroup: rbac.authorization.k8s.io
EOF