Configurazione dei ruoli di autorizzazione

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

Ruoli di autorizzazione

La modalità privata di Anthos viene fornita con quattro ruoli di autorizzazione preimpostati:

Nome del ruolo	Nome ClusterRole Kubernetes (sul cluster di amministrazione)	Autorizzazioni
Operatore dell'infrastruttura	cluster-admin	Accesso completo in lettura/scrittura a tutte le risorse.
Operatore dell'infrastruttura (sola lettura)	vista	Accesso in sola lettura alla maggior parte degli elementi del Centro gestione, ad eccezione di ruoli, associazioni di ruoli e secret. Attualmente gli utenti dispongono dell'accesso in scrittura a Grafana per modificare le dashboard.
Amministratore piattaforma	anthos-piattaforma-amministratore	Accesso in lettura/scrittura a cluster utente, gestione delle funzionalità di Anthos, servizio Anthos Identity e Anthos Config Management. Accesso in lettura ed eliminazione ai computer. Accesso in sola lettura al servizio Bootstrap.
Amministratore piattaforma (Sola lettura)	anthos-platform-admin-sola lettura	Accesso in sola lettura a tutto ciò che può essere visualizzato da un amministratore della piattaforma. Attualmente gli utenti dispongono dell'accesso in scrittura a Grafana per modificare le dashboard.

Chiunque abbia accesso all'account ADMIN_KUBECONFIG viene autenticato come membro nel gruppo system:master di Kubernetes, il che consente qualsiasi azione al server API di Kubernetes. Ad esempio, possono elencare tutti i secret eseguendo:

kubectl get secrets --all-namespaces --kubeconfig=${ADMIN_KUBECONFIG}

L'accesso tramite ADMIN_KUBECONFIG viene autenticato come nome utente generico admin e rende difficile il monitoraggio della persona che esegue il comando. Di conseguenza, è importante mantenere ADMIN_KUBECONFIG in un luogo sicuro e utilizzarlo solo quando è necessario (ad esempio, quando si configurano le associazioni di ruoli iniziali dell'operatore della piattaforma o si recuperano gli errori dovuti a OIDC).

IMPORTANTE: assicurati che gli utenti e i gruppi non abbiano il prefisso system:. Il prefisso system: è riservato al sistema Kubernetes.

Accesso alle metriche di Web Console e AMP

La modalità privata di Anthos sincronizza automaticamente tutti gli utenti associati a questi quattro ruoli nella lista consentita dell'accesso alle metriche e al Centro gestione (Grafana).

I ruoli con diritti di accesso in sola lettura vengono rifiutati se tenti di eseguire un'azione di scrittura nel Centro di gestione.

Associazioni di ruoli

Durante la configurazione dell'OIDC nella console web, puoi impostare un utente iniziale associato al ruolo Amministratore di piattaforma. Una volta eseguito l'accesso a kubeconfig per l'utente amministratore di piattaforma, esistono due approcci per associare un altro utente al ruolo amministratore piattaforma:

Approccio I: (consigliato) configurare GroupMembership nel provider OIDC e creare associazioni di ruoli in base al gruppo

Questo approccio associa uno dei tuoi gruppi a un ruolo preimpostato per concedere a tutti i membri del gruppo gli stessi diritti di accesso del ruolo preimpostato.

Prima di iniziare, verifica quanto segue:

• Determina il provider OIDC da cui proviene il gruppo.
• Il campo "Rivendicazione di gruppi" nella scheda "Profilo OIDC" deve corrispondere al nome della rivendicazione che contiene informazioni sull'iscrizione al gruppo sul lato provider OIDC. La modalità privata di Anthos assegna un valore predefinito: groups, ma se il tuo provider OIDC ne ha uno diverso, assicurati di averlo impostato nella scheda "Profilo OIDC".
• Prendi nota della scheda "Prefisso del gruppo" nella scheda "Profilo OIDC". Devi includere il prefisso del gruppo prima di tutti i nomi dei gruppi. Ad esempio, se hai gid- come prefisso del gruppo e "group-admin"" nel tuo provider OIDC, devi utilizzare gid-admin-group. Tieni presente che il separatore - fa parte del prefisso del gruppo e il sistema non aggiunge alcun separatore per te.

Puoi utilizzare la scheda Gestione degli accessi nell'interfaccia utente del Centro gestione per gestire le associazioni dei ruoli in base ai gruppi.

Impossibile aggiungere o aggiornare un'associazione a un ruolo con più privilegi rispetto all'account attualmente collegato. Ad esempio, se hai eseguito l'accesso come amministratore di piattaforma, non puoi associare un gruppo a un ruolo di operatore dell'infrastruttura.

In alternativa, esegui il comando seguente per creare un'associazione dei ruoli basata su Gruppi. Il valore trasmesso a group= deve corrispondere al nome del tuo gruppo nel provider OIDC preceduto dal prefisso del gruppo:

kubectl create clusterrolebinding anthos-platform-admin-group-binding \
--kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin \
--group=gid-anthos-platform-admin-group

Ora qualsiasi utente che hai aggiunto a anthos-platform-admin-group nel provider OIDC ha tutte le autorizzazioni come amministratore di piattaforma

Allo stesso modo, puoi utilizzare il comando seguente per associare un gruppo al ruolo Amministratore di piattaforma (sola lettura):

kubectl create clusterrolebinding anthos-platform-admin-read-only-group-binding \
  --kubeconfig=${ADMIN_OIDC_KUBECONFIG} --clusterrole=anthos-platform-admin-read-only \
  --group=gid-anthos-platform-admin-read-only-group

Per impedire l'escalation dei privilegi, un amministratore della piattaforma non può vincolare un gruppo a un ruolo Operatore dell'infrastruttura o operatore dell'infrastruttura (sola lettura). Per inizializzare il primo gruppo di Operator Infrastructure, devi disporre di ADMIN-KUBECONFIG:

kubectl create clusterrolebinding anthos-platform-operator-group-binding \
  --kubeconfig=${ADMIN_KUBECONFIG} --clusterrole=cluster-admin --group=gid-anthos-platform-operator-group

In seguito, puoi utilizzare un KUBECONFIG con un account Operatore dell'infrastruttura collegato per associare altri gruppi a qualsiasi ruolo:

# Bind a group to Infrastructure Operator (Read Only):
kubectl create clusterrolebinding anthos-platform-operator-read-only-binding \
  --clusterrole=view --group=gid-anthos-platform-operator-read-only-group --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Approccio II: crea associazioni di ruoli basate sull'utente

Puoi anche creare associazioni di ruoli in base al ruolo Utente. I comandi per creare associazioni di ruoli sono simili a quelli del gruppo. Devi sostituire --group con --user.

Devi anche aggiungere il prefisso utente del tuo profilo OIDC a ogni nome utente. Ad esempio, se il tuo provider OIDC è impostato per avere un prefisso utente uid- e vuoi associare [e-mail] a un ruolo, utilizza [e-mail].

Puoi anche utilizzare la scheda Gestione degli accessi per gestire le associazioni dei ruoli per gli utenti.

Di seguito è riportato un comando di esempio per creare un'associazione dei ruoli per [e-mail] e concedergli le autorizzazioni di amministratore della piattaforma:

kubectl create clusterrolebinding charlie-platform-admin-binding \
  --clusterrole=anthos-platform-admin --user=[e-mail] --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Per eliminare un'associazione di ruolo e rimuovere i diritti di accesso di un utente, puoi aggiornare le associazioni esistenti anziché eliminarle (ad esempio, revocare il diritto di amministratore Platform di [e-mail]):

kubectl patch clusterrolebinding charlie-platform-admin-binding \
  -p '{"subjects":[]}' --kubeconfig=${ADMIN_OIDC_KUBECONFIG}

Puoi anche chiedere all'operatore della tua infrastruttura di eliminare ClusterRoleBinding.

BEST PRACTICE: Kubernetes non impedisce a un utente con diritti di accesso inferiori di eliminare le associazioni per gli utenti che dispongono di più diritti di accesso, pertanto l'amministratore della piattaforma non è autorizzata ad eliminare il diritto su ClusterRoleBinding. L'utilizzo dei gruppi nel tuo provider OIDC per la gestione degli utenti è preferibile perché puoi eliminare un utente dal gruppo corrispondente.

Note

• Ulteriori informazioni sono disponibili sul controllo dell'accesso basato sui ruoli (RBAC) nella documentazione ufficiale.
• Non sono stati impostati ruoli di autorizzazione preimpostati nei cluster utente. L'accesso del server API Kubernetes in ogni accesso al cluster utente è aperto a chiunque abbia la proprietà kubeconfig.
• Gli amministratori della piattaforma non possono eliminare un'associazione di ruolo per impedire agli amministratori della piattaforma di eliminare le associazioni per gli utenti con privilegi più elevati. Per revocare l'accesso di un utente, puoi aggiornare l'associazione di ruolo che vincola l'utente a un elenco di oggetti vuoto. L'azione di eliminazione nell'interfaccia utente di gestione degli accessi aggiorna anche le associazioni di ruoli con un elenco di oggetti vuoto, anziché eliminare le associazioni per lo stesso motivo.
• Il nome del ClusterRoleBinding deve essere univoco. Soltanto l'ultima applicata o creata avrà effetto quando sono presenti più associazioni di ruoli cluster con lo stesso nome.

Diritti di accesso alle risorse Kubernetes per ogni ruolo preimpostato

Questa sezione fornisce i dettagli di tutti i diritti di accesso alle risorse Kubernetes per ciascun ruolo preimpostato.

Operatore dell'infrastruttura

L'operatore dell'infrastruttura corrisponde al ruolo cluster-admin integrato di Kubernetes , che può eseguire qualsiasi verbo su qualsiasi risorsa.

Operatore dell'infrastruttura (sola lettura)

L'operatore dell'infrastruttura (sola lettura) corrisponde al ruolo view k8s integrato, che può leggere tutte le risorse tranne Role, ClusterRole, RoleBinding, ClusterRoleBinding e Secret.

Molte informazioni utili, come il cluster utente kubeconfig, vengono archiviate come Secrets, pertanto l'operatore Infrastructure (sola lettura) non è completamente funzionante.

Amministratore piattaforma

L'amministratore della piattaforma può disporre dei seguenti diritti di accesso:

Risorsa	Verbi
spazi dei nomi	trova, elenca, guarda, crea, aggiorna
pods	trova, elenca, guarda
services	trova, elenca, guarda
events	trova, elenca, guarda
configmaps	trova, elenca, guarda
deployment	trova, elenca, guarda
daemonsets	trova, elenca, guarda
set di repliche	trova, elenca, guarda
statefulsets	trova, elenca, guarda
job	trova, elenca, guarda
cronjobs	trova, elenca, guarda
memberships.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
onpremuserclusters.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
clusters.baremetal.cluster.gke.io	trova, elenca, guarda, crea
nodepools.baremetal.cluster.gke.io	trova, elenca, guarda, crea
clusters.cluster.x-k8s.io	trova, elenca, guarda
machines.baremetal.cluster.gke.io	trova, elenca, guarda
inventorymachines.baremetal.cluster.gke.io	trova, elenca, guarda
addresspools.managementcenter.anthos.cloud.google.com	trova, elenca, guarda
bootstrapservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
bootstrapservices.managementcenter.anthos.cloud.google.com	trova, elenca, guarda
bootstrapservicebindingitems.managementcenter.anthos.cloud.google.com	trova, elenca, guarda
adminoperators.managementcenter.anthos.cloud.google.com	trova, elenca, guarda
clientconfigs.authentication.gke.io	get, list, watch, create, update, delete
configmanagementbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
configmanagementbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshfeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
servicemeshbindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicefeaturespecs.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
identityservicebindingitems.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
updatablecomponents.managementcenter.anthos.cloud.google.com	trova, elenca, guarda
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
domainidpmappings.managementcenter.anthos.cloud.google.com	get, list, watch, create, update, delete
logmons.addons.gke.io	get, list, watch, create, update, delete
clusterrolebindings.rbac.authorization.k8s.io	trova, elenca, guarda, crea, aggiorna

L'amministratore della piattaforma ha anche accesso in lettura a secrets per consentire di ottenere un kubeconfig che venga autenticato come ruolo cluster-admin in un cluster utente.

Per configurare Logmon, gli amministratori della piattaforma possono anche leggere e scrivere secrets e configmaps con un'etichetta logmon in kube-system.

Amministratore piattaforma (sola lettura)

L'amministratore della piattaforma (sola lettura) ha gli stessi diritti di accesso dell'amministratore della piattaforma, ad eccezione di:

• Tutti i verbi relativi alla scrittura (creazione, aggiornamento ed eliminazione) non sono consentiti.
• Per accedere a un cluster utente, l'amministratore piattaforma (sola lettura) può leggere solo un kubeconfig che viene autenticato come ruolo view nel cluster utente.