Questa pagina mostra come autorizzare le azioni sulle risorse in Cluster Google Kubernetes Engine (GKE) che utilizzano il controllo dell'accesso integrato basato sui ruoli meccanismo RBAC in Kubernetes.
RBAC è una funzionalità di sicurezza fondamentale di Kubernetes che consente di creare cluster autorizzazioni per gestire le azioni che utenti e carichi di lavoro possono eseguire sulle risorse nei tuoi cluster. In qualità di amministratore di piattaforma, puoi creare ruoli RBAC e associare quei ruoli agli soggetti, ovvero gli utenti autenticati, come o Gruppi. Kubernetes RBAC è abilitato per impostazione predefinita.
Prima di iniziare
Prima di iniziare, assicurati di aver eseguito le seguenti attività:
- Attiva l'API Google Kubernetes Engine. Abilita l'API Google Kubernetes Engine .
- Se vuoi utilizzare Google Cloud CLI per questa attività,
install e poi
inizializzare
con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente
eseguendo
gcloud components update
.
- Letto Best practice per RBAC in GKE per conoscere le linee guida per migliorare la struttura dei criteri RBAC.
Interazione con Identity and Access Management
Puoi utilizzare sia Identity and Access Management (IAM) che Kubernetes RBAC per controllare l'accesso al tuo cluster GKE:
IAM non è specifico per Kubernetes; fornisce l'identità per più prodotti Google Cloud e opera principalmente presso del progetto Google Cloud.
Kubernetes RBAC è un componente fondamentale di Kubernetes e ti consente creare e concedere ruoli (insiemi di autorizzazioni) per qualsiasi oggetto o tipo di all'interno del cluster.
Per autorizzare un'azione, GKE cerca un RBAC per prima cosa. Se non esiste un criterio RBAC, GKE verifica 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 dei due strumenti. Questa è una parte importante del bootstrap cluster GKE, poiché per impostazione predefinita gli utenti Google Cloud un RoleBinding RBAC di Kubernetes.
Per autorizzare gli utenti utilizzando account Google Cloud, il client deve
siano configurate correttamente per l'autenticazione
usando 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, è possibile utilizzare Kubernetes RBAC al posto di IAM.
Per gli utenti GKE, almeno il container.clusters.get
Autorizzazione IAM nel progetto che contiene il cluster.
Questa autorizzazione è inclusa nel ruolo container.clusterViewer
e in altre
ruoli con privilegi più elevati. L'autorizzazione container.clusters.get
è
richiesta agli utenti di autenticarsi nei cluster nel progetto, ma
non autorizzarli a eseguire azioni all'interno dei cluster. Autorizzazione
può quindi essere fornito da IAM o Kubernetes RBAC.
Definisci e assegna le autorizzazioni
Puoi definire le regole RBAC negli oggetti ClusterRole
e Role
e poi assegnare
queste regole con oggetti ClusterRoleBinding
e RoleBinding
, come segue:
- ClusterRole: un raggruppamento a livello di cluster di risorse e operazioni consentite
che puoi assegnare a un utente o a un gruppo utilizzando un
RoleBinding
o unClusterRoleBinding
. - Ruolo: un raggruppamento con spazio dei nomi di risorse e operazioni consentite
può assegnare a un utente o a un gruppo di utenti utilizzando un
RoleBinding
. - ClusterRoleBinding: assegna
ClusterRole
a un utente o a un gruppo per tutti di più spazi dei nomi all'interno del cluster. - RoleBinding: assegna un
Role
o unClusterRole
a un utente o a un gruppo all'interno uno spazio dei nomi specifico.
Quando utilizzi un RoleBinding
per assegnare ClusterRole
a un utente o gruppo, questi
utenti e gruppi possono accedere alle risorse solo nello spazio dei nomi specificato
RoleBinding
. Se vuoi che gli utenti o i gruppi accedano alla risorsa su tutti
usa invece un valore ClusterRoleBinding
.
Definisci le autorizzazioni utilizzando Roles o ClusterRoles
Puoi definire le autorizzazioni all'interno di un oggetto Role o ClusterRole. Un ruolo definisce alle risorse all'interno di un singolo spazio dei nomi, mentre un ClusterRole definisce e l'accesso alle risorse nell'intero cluster.
I ruoli Role e ClusterRole hanno la stessa sintassi. Ognuno ha una sezione rules
, in cui
devi definire le risorse a cui si applica la regola e le operazioni consentite per
Ruolo. Ad esempio, il seguente ruolo 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"]
Fai riferimento al Ruolo e ClusterRole Documentazione dell'API per un elenco completo dei campi consentiti.
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 puoi farlo con i Ruoli. Queste includono:
- Risorse con ambito cluster come i nodi
- Endpoint REST senza risorse come
/healthz
- Risorse con pacing dei nomi in tutti gli spazi dei nomi (ad esempio, tutti i pod nel nell'intero cluster, indipendentemente dallo spazio dei nomi)
Assegnare ruoli utilizzando RoleBindings o ClusterRoleBindings
Dopo aver creato un Role o ClusterRole, lo assegni a un utente o a un gruppo di utenti
creando un oggetto RoleBinding o un ClusterRoleBinding. Utenti e gruppi vengono chiamati
subjects
e possono essere:
Tipo di soggetto | Valore per kind |
Valore per name |
---|---|---|
Account utente Google Cloud | User |
Indirizzo email registrato per Google Cloud |
Service account Kubernetes | ServiceAccount |
Il nome di un oggetto ServiceAccount di Kubernetes nel cluster |
Account di servizio IAM | User |
Indirizzo email dell'account di servizio IAM generato automaticamente |
Indirizzo del gruppo Google su un dominio verificato | Group |
Indirizzo email di un gruppo Google Workspace che è membro del gruppo gke-security-groups . Per istruzioni su come configurare Google Gruppi per RBAC, vedi Configurare Google Gruppi per RBAC. |
La seguente associazione RoleBinding assegna il ruolo pod-reader
a un utente, un
un account di servizio Kubernetes, un account di servizio IAM e un account
Gruppo:
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 API. In qualità di amministratore di piattaforma, potresti dover impersonare gli utenti per determinare quali azioni possono eseguire. Puoi usare auth can-i
e passare 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 le risorse
Role
e RoleBinding
oggetti per RBAC.
Per ulteriori informazioni, consulta Verifica dell'accesso all'API.
Utilizzo delle API ed esempi
Per informazioni complete sull'utilizzo dell'API Kubernetes per creare i necessari
Role
, ClusterRole
, RoleBinding
e ClusterRoleBinding
di oggetti per
RBAC, consulta Utilizzo dell'autorizzazione per il controllo degli accessi basato sui ruoli
nella documentazione di Kubernetes.
Risoluzione dei problemi e debug
Per eseguire il debug dei problemi relativi a RBAC, utilizza la classe
log di controllo delle attività di amministrazione, che
è abilitato su tutti i cluster per impostazione predefinita. Se l'accesso a una risorsa o a un'operazione
negata poiché in mancanza di autorizzazioni sufficienti, il server API registra un RBAC DENY
insieme a informazioni aggiuntive quali i dati impliciti e
esplicita appartenenza al gruppo. Se utilizzi Google Gruppi per RBAC, google groups
viene visualizzato nel messaggio di log.
Limitazioni
Le seguenti sezioni descrivono interazioni che potrebbero non sembrare ovvie quando che lavora con RBAC e IAM di Kubernetes.
Ruoli predefiniti per il rilevamento
I cluster vengono creati con un insieme
ClusterRoles e ClusterRoleBindings predefiniti.
Le richieste effettuate con credenziali valide vengono inserite in system:authenticated
mentre tutte le altre richieste rientrano in system:unauthenticated
.
Il ClusterRole system:basic-user
consente agli utenti di
SelfSubjectAccessReviews
per testare le proprie autorizzazioni nel cluster. La
Il ruolo system:discovery
consente agli utenti di leggere le API di rilevamento, che possono rivelare informazioni
informazioni su
CustomResourceDefinitions
aggiunte al cluster.
Gli utenti anonimi (system:unauthenticated
) ricevono l'autorizzazione
system:public-info-viewer
ClusterRole, che concede l'accesso in sola lettura
alle API /healthz
e /version
.
Per visualizzare gli endpoint API consentiti dall'oggetto ClusterRole system:discovery
, esegui il
seguente comando:
kubectl get clusterroles system:discovery -o yaml
Errore non consentito per gli account di servizio sulle istanze VM di Google Cloud
Il seguente errore può verificarsi quando l'istanza VM non ha
userinfo-email
ambito:
Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...
Ad esempio, supponiamo che la VM abbia cloud-platform
ambito, ma
senza ambito userinfo-email
. Quando la VM riceve un token di accesso, Google Cloud
associa il token all'ambito cloud-platform
. Quando l'API Kubernetes
richiede 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 correttamente l'autenticazione, crea una nuova VM con userinfo-email
l'ambito o crea una nuova associazione di ruolo che utilizza 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 utilizza l'ID univoco dell'account di servizio per un VM esistente, segui questi passaggi:
Identifica l'ID univoco dell'account di servizio:
gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL
Ad esempio, l'output seguente visualizza il
uniqueId
per il 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 dei ruoli utilizzando il valore
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 solo un ruolo o un'associazione di ruoli con autorizzazioni specifiche se soddisfi le seguenti condizioni:
- Crea o aggiorna un ruolo: devi già disporre delle stesse autorizzazioni
che vuoi concedere al ruolo. In alternativa, devi avere
a eseguire il verbo
escalate
nel ruolo. - Crea o aggiorna un'associazione di ruoli: devi avere già lo stesso
alle autorizzazioni concesse nel ruolo associato, con lo stesso
l'ambito come associazione del ruolo. In alternativa, devi disporre dell'autorizzazione
per eseguire il verbo
bind
sul ruolo a cui viene fatto riferimento.
Se le autorizzazioni che concedi nel ruolo erano originariamente
mediante un criterio di autorizzazione IAM anziché RBAC,
la richiesta del ruolo o dell'associazione del ruolo
potrebbe non andare a buon fine. Ad esempio, considera
successiva a una richiesta di creazione del ruolo, da un utente a cui è stato concesso
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 tramite IAM, potrebbe verificarsi 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 mitigare questo limite, concedi al chiamante le autorizzazioni nel tramite RBAC al posto di IAM.
In alternativa, puoi utilizzare RBAC o IAM per concedere
chiama il verbo escalate
, il verbo bind
o entrambi. Tuttavia,
GKE sconsiglia questo approccio, perché il chiamante
può concedere qualsiasi autorizzazione a qualsiasi ruolo.
Passaggi successivi
- Scopri come creare criteri IAM.
- Scopri come configurare Google Gruppi per RBAC.