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 e con ambito di progetto con 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 Configurazioni dei cluster Kubernetes.

Questo documento è destinato ai gruppi di operatori di applicazioni, come le operazioni di sviluppo o i data scientist, che devono gestire e proteggere le risorse all'interno dei progetti GDC. Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC air-gapped.

Prima di iniziare

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

Richiedere 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.
  • Amministratore cluster standard (standard-cluster-admin): crea, aggiorna ed elimina i binding dei ruoli all'interno di un cluster standard specifico.

prepara l'ambiente

Concedi le autorizzazioni per l'accesso standard al cluster

Un utente con il ruolo Amministratore IAM progetto (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 Amministratore cluster standard (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 a cui 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 la sezione Stabilire la connessione a un provider di identità.

    L'esempio seguente concede il ruolo di amministratore del cluster standard a user@example.com, supponendo 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

Gestire l'accesso all'interno del cluster standard

Un utente con il ruolo Amministratore cluster standard (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 scegliere come target 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 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 RoleBinding per 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 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