Questa pagina mostra come autorizzare le azioni sulle risorse nei cluster Google Kubernetes Engine (GKE) utilizzando il meccanismo di controllo dell'accesso basato sui ruoli (RBAC) integrato in Kubernetes.
RBAC è una funzionalità di sicurezza di base in Kubernetes che consente di creare autorizzazioni granulari per gestire le azioni che utenti e carichi di lavoro possono eseguire sulle risorse nei cluster. In qualità di amministratore di piattaforma, puoi creare ruoli RBAC e associarli a soggetti, che sono utenti autenticati, come account di servizio o Gruppi. Kubernetes RBAC è abilitato per impostazione predefinita.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Abilita l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine
- Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo
gcloud components update
.
- Leggi le best practice per GKE RBAC per linee guida su come migliorare la progettazione dei tuoi criteri RBAC.
Interazione con Identity and Access Management
Puoi utilizzare sia Identity and Access Management (IAM) sia Kubernetes RBAC per controllare l'accesso al tuo cluster GKE:
IAM non è specifico di Kubernetes; fornisce la gestione delle identità per più prodotti Google Cloud e opera principalmente a livello di progetto Google Cloud.
Kubernetes RBAC è un componente fondamentale di Kubernetes e ti consente di creare e concedere ruoli (insiemi di autorizzazioni) per qualsiasi oggetto o tipo di oggetto all'interno del cluster.
Per autorizzare un'azione, GKE verifica prima la presenza di un criterio RBAC. Se non esistono criteri RBAC, GKE controlla le autorizzazioni IAM.
In GKE, IAM e Kubernetes RBAC sono integrati per autorizzare gli utenti a eseguire azioni se dispongono di autorizzazioni sufficienti in base a uno degli strumenti. Questa è una parte importante del bootstrap di un cluster GKE, poiché per impostazione predefinita gli utenti Google Cloud non dispongono di RoleBinding RBAC di Kubernetes.
Per autorizzare gli utenti utilizzando account Google Cloud, il client deve essere prima configurato correttamente per l'autenticazione utilizzando questi account. Ad esempio,
se utilizzi kubectl
, devi
configurare il comando kubectl
per l'autenticazione su Google Cloud
prima di eseguire qualsiasi comando che richieda l'autorizzazione.
In quasi tutti i casi, RBAC di Kubernetes può essere utilizzato al posto di IAM.
Gli utenti GKE devono disporre almeno dell'autorizzazione IAM container.clusters.get
nel progetto che contiene il cluster.
Questa autorizzazione è inclusa nel ruolo container.clusterViewer
e in altri ruoli con privilegi più elevati. L'autorizzazione container.clusters.get
è necessaria per consentire agli utenti di autenticarsi nei cluster del progetto, ma non autorizzali a eseguire azioni all'interno di questi cluster. L'autorizzazione può quindi essere fornita da IAM o Kubernetes RBAC.
Definisci e assegna le autorizzazioni
Puoi definire le regole RBAC negli oggetti ClusterRole
e Role
e assegnarle
agli oggetti ClusterRoleBinding
e RoleBinding
nel seguente modo:
- ClusterRole: un raggruppamento di risorse e operazioni consentite a livello di cluster che puoi assegnare a un utente o a un gruppo utilizzando un
RoleBinding
o unClusterRoleBinding
. - Ruolo: un raggruppamento di risorse e operazioni consentite con spazio dei nomi che puoi assegnare a un utente o a un gruppo di utenti utilizzando un
RoleBinding
. - ClusterRoleBinding: assegna un
ClusterRole
a un utente o a un gruppo per tutti gli spazi dei nomi nel cluster. - RoleBinding: assegna un
Role
o unClusterRole
a un utente o a un gruppo all'interno di uno spazio dei nomi specifico.
Quando utilizzi un RoleBinding
per assegnare un ClusterRole
a un utente o a un gruppo, questi
utenti e gruppi possono accedere solo alle risorse nello spazio dei nomi specificato in
RoleBinding
. Se vuoi che gli utenti o i gruppi accedano alle risorse in tutti gli spazi dei nomi, utilizza invece un ClusterRoleBinding
.
Definisci le autorizzazioni utilizzando Role o ClusterRoles
Puoi definire le autorizzazioni all'interno di un oggetto Role o ClusterRole. Un Ruolo definisce l'accesso alle risorse all'interno di un singolo spazio dei nomi, mentre un ClusterRole definisce l'accesso alle risorse nell'intero cluster.
I ruoli e i ClusterRole hanno la stessa sintassi. Ognuno ha una sezione rules
in cui definisci le risorse a cui si applica la regola e le operazioni consentite per il ruolo. Ad esempio, il ruolo seguente concede l'accesso in lettura (get
, watch
e
list
) a tutti i pod nello spazio dei nomi accounting
:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: accounting
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Per un elenco completo dei campi consentiti, consulta la documentazione dell'API Role e ClusterRole.
Role
rispetto a ClusterRole
Poiché le autorizzazioni concesse da un ClusterRole si applicano all'intero cluster, puoi utilizzare ClusterRoles per controllare l'accesso a diversi tipi di risorse rispetto a Role. Questi includono:
- Risorse con ambito cluster come i nodi
- Endpoint REST non di risorse come
/healthz
- Risorse con pacing dei nomi in tutti gli spazi dei nomi (ad esempio, tutti i pod nell'intero cluster, indipendentemente dallo spazio dei nomi)
Assegna i ruoli utilizzando RoleBindings o ClusterRoleBinding
Dopo aver creato un oggetto Role o ClusterRole, lo assegni a un utente o a un gruppo di utenti creando un oggetto RoleBinding o ClusterRoleBinding. Gli utenti e i gruppi vengono chiamati
subjects
e possono essere:
Tipo di soggetto | Valore per kind |
Valore per name |
---|---|---|
Account utente Google Cloud | User |
Indirizzo email registrato di Google Cloud |
Account di servizio Kubernetes | ServiceAccount |
Il nome di un oggetto ServiceAccount Kubernetes nel cluster |
Account di servizio IAM | User |
Indirizzo email dell'account di servizio IAM generato automaticamente |
Indirizzo di Google Gruppi su un dominio verificato | Group |
Indirizzo email di un gruppo Google Workspace membro del gruppo gke-security-groups . Per istruzioni su come configurare Google Gruppi per RBAC, vedi Configurare Google Gruppi per RBAC. |
La seguente risorsa RoleBinding concede il ruolo pod-reader
a un utente, un account di servizio Kubernetes, un account di servizio IAM e un gruppo Google:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: pod-reader-binding
namespace: accounting
subjects:
# Google Cloud user account
- kind: User
name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
name: johndoe
# IAM service account
- kind: User
name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
name: accounting-group@example.com
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Verifica l'accesso all'API utilizzando kubectl
kubectl
fornisce il sottocomando auth can-i
per eseguire rapidamente query sul livello di autorizzazione dell'API. In qualità di amministratore della piattaforma, potresti dover rubare l'identità degli utenti per determinare quali azioni possono eseguire. Puoi usare l'auth can-i
e trasmettere un ulteriore flag --as
.
Quando esegui il comando kubectl auth can-i
senza il flag --as
, Identity and Access Management (IAM) esegue l'autorizzazione. Invece, quando aggiungi il flag --as
, Kubernetes RBAC esegue l'autorizzazione. Pertanto, dovrai creare gli oggetti Role
e RoleBinding
necessari per RBAC.
Per ulteriori informazioni, consulta la sezione Verifica dell'accesso all'API.
Utilizzo dell'API ed esempi
Per informazioni complete sull'utilizzo dell'API Kubernetes per creare gli oggetti Role
, ClusterRole
, RoleBinding
e ClusterRoleBinding
necessari per RBAC, consulta Utilizzo dell'autorizzazione per il controllo degli accessi basato su ruoli nella documentazione di Kubernetes.
Risoluzione dei problemi e debug
Per eseguire il debug dei problemi con RBAC, utilizza l'audit log dell'attività di amministrazione, che è abilitato per tutti i cluster per impostazione predefinita. Se l'accesso a una risorsa o a un'operazione viene negato per mancanza di autorizzazioni sufficienti, il server API registra un errore RBAC DENY
e informazioni aggiuntive come l'appartenenza implicita ed esplicita al gruppo dell'utente. Se utilizzi Google Gruppi per RBAC, nel messaggio di log verrà visualizzato google groups
.
Limitazioni
Le seguenti sezioni descrivono le interazioni che potrebbero non sembrare ovvie quando si utilizzano Kubernetes RBAC e IAM.
Ruoli rilevamento predefiniti
I cluster vengono creati con un set di ClusterRoles e ClusterRoleBinding predefiniti.
Le richieste effettuate con credenziali valide vengono inserite nel gruppo system:authenticated
, mentre tutte le altre richieste rientrano in system:unauthenticated
.
Il ClusterRole system:basic-user
consente agli utenti di impostare SelfSubjectAccessReviews
per testare le proprie autorizzazioni nel cluster. Il ruolo system:discovery
consente agli utenti di leggere le API di rilevamento, che possono rivelare informazioni su CustomResourceDefinitions
aggiunte al cluster.
Gli utenti anonimi (system:unauthenticated
) ricevono invece il ClusterRole system:public-info-viewer
, che concede l'accesso in sola lettura alle API /healthz
e /version
.
Per visualizzare gli endpoint API consentiti dal ClusterRole system:discovery
, esegui questo comando:
kubectl get clusterroles system:discovery -o yaml
Errore vietato per gli account di servizio nelle istanze VM di Google Cloud
Quando l'istanza VM non ha l'ambito userinfo-email
, può verificarsi il seguente errore:
Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...
Ad esempio, supponi che la VM abbia un ambito cloud-platform
ma
non ha un ambito userinfo-email
. Quando la VM riceve un token di accesso, Google Cloud lo associa all'ambito cloud-platform
. Quando il server API Kubernetes chiede a Google Cloud l'identità associata al token di accesso, riceve l'ID univoco dell'account di servizio, non l'email dell'account di servizio.
Per eseguire l'autenticazione correttamente, crea una nuova VM con l'ambito userinfo-email
o crea una nuova associazione di ruolo che utilizzi l'ID univoco.
Per creare una nuova istanza VM con l'ambito userinfo-email
, esegui questo comando:
gcloud compute instances create INSTANCE_NAME \
--service-account SERVICE_ACCOUNT_EMAIL \
--scopes userinfo-email
Per creare una nuova associazione di ruoli che utilizzi l'ID univoco dell'account di servizio per una VM esistente, segui questi passaggi:
Identifica l'ID univoco dell'account di servizio:
gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL
Ad esempio, nell'output seguente viene visualizzato
uniqueId
per l'account di serviziomy-iam-account@somedomain.com
:displayName: Some Domain IAM service account email: my-iam-account@somedomain.com etag: BwWWja0YfJA name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com oauth2ClientId: '123456789012345678901' projectId: project-name uniqueId: '123456789012345678901'
Crea un'associazione di ruoli utilizzando il
uniqueId
dell'account di servizio:kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \ --clusterrole cluster-admin \ --user UNIQUE_ID
Autorizzazione per creare o aggiornare ruoli e associazioni di ruoli
In Kubernetes, puoi creare o aggiornare un ruolo o un'associazione di ruoli con autorizzazioni specifiche solo se soddisfi le seguenti condizioni:
- Crea o aggiorna un ruolo: devi già avere le stesse autorizzazioni
che vuoi concedere al ruolo. In alternativa, devi disporre dell'autorizzazione per eseguire il verbo
escalate
nel ruolo. - Crea o aggiorna un'associazione di ruoli: devi già disporre delle stesse
autorizzazioni concesse nel ruolo associato, con lo stesso ambito
dell'associazione dei ruoli. In alternativa, devi disporre dell'autorizzazione
per eseguire il verbo
bind
nel ruolo indicato.
Se le autorizzazioni che stai concedendo nel ruolo ti sono state concesse in origine utilizzando un criterio di autorizzazione IAM anziché RBAC, la richiesta di associazione del ruolo o del ruolo potrebbe non riuscire. Ad esempio, considera la seguente richiesta di creazione del ruolo da parte di un utente a cui sono state concesse le autorizzazioni IAM container.pods.*
e container.roles.create
:
kubectl create role allowed-to-view-pods --resource pods --verb list,get
Se all'utente sono state concesse le autorizzazioni solo utilizzando IAM, è possibile che si verifichi il seguente errore:
Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}
Per limitare questa limitazione, concedi al chiamante le autorizzazioni nel ruolo utilizzando RBAC anziché IAM.
In alternativa, puoi utilizzare RBAC o IAM per concedere al chiamante il verbo escalate
, il verbo bind
o entrambi. Tuttavia, GKE sconsiglia questo approccio, perché il chiamante può quindi concedere qualsiasi autorizzazione a qualsiasi ruolo.
Passaggi successivi
- Scopri come creare criteri IAM.
- Scopri come configurare Google Gruppi per RBAC.