Best practice per RBAC in GKE

Questa pagina fornisce buone pratiche per la pianificazione dei criteri di controllo dell'accesso basato sui ruoli (RBAC). Per scoprire come implementare RBAC in Google Kubernetes Engine (GKE), consulta le Configurare il controllo degli accessi basato su ruoli

RBAC è una funzionalità di sicurezza fondamentale in 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 legare questi ruoli a soggetti, ovvero utenti autenticati, come o gruppi Google.

Prima di iniziare

Assicurati di conoscere i seguenti concetti:

Per un elenco di controllo di queste indicazioni, consulta Riepilogo dell'elenco di controllo.

Come funziona RBAC

RBAC supporta i seguenti tipi di ruoli e associazioni:

  • ClusterRole: un insieme di autorizzazioni che può essere applicato a qualsiasi spazio dei nomi o all'intero cluster.
  • Ruolo: un insieme di autorizzazioni limitato a un singolo spazio dei nomi.
  • ClusterRoleBinding: associa un ClusterRole a un utente o a un gruppo per tutti gli spazi dei nomi del cluster.
  • RoleBinding: associa un Role o un ClusterRole a un utente o a un gruppo all'interno di uno spazio dei nomi specifico.

Puoi definire le autorizzazioni come rules in Role o ClusterRole. Ogni campo rules in un ruolo è costituito da un gruppo di API, dalle risorse API all'interno di quel gruppo di API e dai verbi (azioni) consentiti su queste risorse. Se vuoi, puoi limitare i verbi a istanze denominate di risorse API utilizzando il campo resourceNames. Per un esempio, vedi Limita l'accesso a istanze di risorse specifiche.

Dopo aver definito un ruolo, puoi utilizzare un RoleBinding o un ClusterRoleBinding per eseguire l'associazione il ruolo a un soggetto. Scegli il tipo di associazione in base a se vuoi concedere le autorizzazioni in un singolo spazio dei nomi o in più spazi dei nomi.

Progettazione dei ruoli RBAC

Applicare il principio del privilegio minimo

Quando si assegnano le autorizzazioni in un ruolo RBAC, utilizza il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. Utilizzando il principio del privilegio minimo riduce la possibilità di escalation dei privilegi se è compromesso e riduce la probabilità che un accesso eccessivo in un incidente di sicurezza.

Quando progetti i ruoli, valuta attentamente i rischi comuni di riassegnazione dei privilegi, come i verbi escalate o bind, l'accesso create per i PersistentVolume o l'accesso create per le richieste di firma del certificato. Per un elenco dei rischi, consulta Kubernetes RBAC - privilege escalation risks.

Evitare ruoli e gruppi predefiniti

Kubernetes crea un set di ClusterRoles e ClusterRoleBinding predefiniti che puoi utilizzare per il rilevamento API e per abilitare la funzionalità dei componenti gestiti. La autorizzazioni concesse da questi ruoli predefiniti potrebbero essere estese a seconda ruolo. Kubernetes favorisce inoltre ha un insieme di utenti e gruppi di utenti predefiniti, identificati dal prefisso system:. Per impostazione predefinita, Kubernetes e GKE associano automaticamente questi ruoli ai gruppi predefiniti e a vari soggetti. Per un elenco completo dei ruoli predefiniti e le associazioni create da Kubernetes, fanno riferimento Ruoli e associazioni di ruoli predefiniti.

La tabella seguente descrive alcuni ruoli, utenti e gruppi predefiniti. Me di evitare di interagire con questi ruoli, utenti e gruppi, a meno che sono stati valutati attentamente, perché interagire con queste risorse può avere e conseguenze indesiderate per la security posture del cluster.

Nome Tipo Descrizione
cluster-admin ClusterRole Concede a un soggetto l'autorizzazione a eseguire qualsiasi operazione su qualsiasi risorsa nel cluster.
system:anonymous Utente

Kubernetes assegna questo utente alle richieste del server API per le quali non sono state fornite informazioni di autenticazione.

L'associazione di un ruolo a questo utente concede a qualsiasi utente non autenticato le autorizzazioni concesse dal ruolo.
system:unauthenticated Gruppo

Kubernetes assegna questo gruppo alle richieste del server dell'API per le quali non sono state fornite informazioni di autenticazione.

L'associazione di un ruolo a questo gruppo concede a qualsiasi utente non autenticato autorizzazioni concesse da quel ruolo.
system:authenticated Gruppo

GKE assegna questo gruppo alle richieste del server API effettuate da qualsiasi utente che ha eseguito l'accesso con un Account Google, inclusi tutti account Gmail. In pratica, non si tratta notevolmente diverso da system:unauthenticated perché chiunque può creare un Account Google.

L'associazione di un ruolo a questo gruppo concede a qualsiasi utente con un Account Google, inclusi tutti gli account Gmail, le autorizzazioni concesse dal ruolo.
system:masters Gruppo

Kubernetes assegna il ruolo cluster-admin ClusterRole a questo gruppo per impostazione predefinita per abilitare la funzionalità di sistema.

Se a questo gruppo aggiungi dei soggetti, questi possono eseguire qualsiasi azione sulle risorse nel cluster.

Se possibile, evita di creare associazioni che coinvolgano utenti, ruoli e gruppi specifici. Questo può avere conseguenze indesiderate sulla sicurezza del cluster postura. Ad esempio:

  • Associazione del ClusterRole predefinito cluster-admin al cluster Il gruppo system:unauthenticated concede a qualsiasi utente non autenticato l'accesso a tutti risorse nel cluster (inclusi i secret). Questi privilegiati associazioni sono attivamente presi di mira da attacchi come le campagne di malware di massa.
  • L'associazione di un ruolo personalizzato al gruppo system:unauthenticated consente di ottenere le autorizzazioni concesse da quel ruolo agli utenti non autenticati.

Se possibile, segui queste linee guida:

  • Non aggiungere soggetti personali al gruppo system:masters.
  • Non associare il gruppo system:unauthenticated a nessun ruolo RBAC.
  • Non associare il gruppo system:authenticated a nessun ruolo RBAC.
  • Non associare l'utente system:anonymous a nessun ruolo RBAC.
  • Non associare il ClusterRole cluster-admin ai tuoi soggetti o a nessuno gli utenti e i gruppi predefiniti. Se la tua applicazione richiede molte autorizzazioni, determina le autorizzazioni esatte richieste e crea un ruolo specifico a questo scopo.
  • Valuta le autorizzazioni concesse da altri ruoli predefiniti prima dell'associazione soggetti.
  • Valuta i ruoli associati ai gruppi predefiniti prima di modificare i membri di quei gruppi.

Impedire l'utilizzo dei gruppi predefiniti

Puoi utilizzare gcloud CLI per disabilitare le associazioni RBAC non predefinite in un che fanno riferimento a system:unauthenticated e system:authenticated gruppi o l'utente system:anonymous. Utilizza uno o entrambi i seguenti flag quando crei un nuovo cluster GKE o aggiorni un cluster esistente. L'utilizzo di questi flag non disattiva le associazioni Kubernetes predefinite che fanno riferimento a questi gruppi. Questi flag richiedono GKE versione 1.30.1-gke.1283000 o successiva.

Rilevare e rimuovere l'utilizzo di ruoli e gruppi predefiniti

Devi valutare i cluster per identificare se hai associato l'utente system:anonymous o l'system:unauthenticated oppure system:authenticated gruppi che utilizzano sia ClusterRoleBindings che RoleBinding.

ClusterRoleBindings

  1. Elenca i nomi di tutti i ClusterRoleBinding con l'oggetto system:anonymous, system:unauthenticated o system:authenticated:

    kubectl get clusterrolebindings -o json \
  | jq -r '["Name"], ["-----"], (.items[] | select((.subjects | length) > 0) | select(any(.subjects[]; .name == "system:anonymous" or .name == "system:unauthenticated" or .name == "system:authenticated")) | [.metadata.namespace, .metadata.name]) | @tsv'

    L'output dovrebbe elencare solo i seguenti ClusterRoleBinding:

    Name
----
"system:basic-user"
"system:discovery"
"system:public-info-viewer"

    Se l'output contiene associazioni non predefinite aggiuntive, svolgi i passaggi riportati di seguito per ogni associazione aggiuntiva. Se l'output non contiene valori non predefiniti associazioni, ignora i passaggi seguenti.

  2. Elenca le autorizzazioni del ruolo associato all'associazione:

    kubectl get clusterrolebinding CLUSTER_ROLE_BINDING_NAME -o json \
    | jq ' .roleRef.name +" " + .roleRef.kind' \
    | sed -e 's/"//g' \
    | xargs -l bash -c 'kubectl get $1 $0 -o yaml'

    Sostituisci CLUSTER_ROLE_BINDING_NAME con il nome del ruolo ClusterRoleBinding non predefinito.

    L'output è simile al seguente:

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
...
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - watch
  - list

    Se stabilisci che le autorizzazioni nell'output possono essere concesse in sicurezza al per utenti o gruppi predefiniti, non sono necessarie ulteriori azioni. Se determini che le autorizzazioni concesse dall'associazione non sono sicure, vai alla successiva passaggio.

  3. Elimina un'associazione non sicura dal cluster:

    kubectl delete clusterrolebinding CLUSTER_ROLE_BINDING_NAME

    Sostituisci CLUSTER_ROLE_BINDING_NAME con il nome di l'oggetto ClusterRoleBinding da eliminare.

RoleBinding

  1. Elenca lo spazio dei nomi e il nome di eventuali associazioni dei ruoli con l'oggetto system:anonymous, system:unauthenticated o system:authenticated:

    kubectl get rolebindings -A -o json \
  | jq -r '["Namespace", "Name"], ["---------", "-----"], (.items[] | select((.subjects | length) > 0) | select(any(.subjects[]; .name == "system:anonymous" or .name == "system:unauthenticated" or .name == "system:authenticated")) | [.metadata.namespace, .metadata.name]) | @tsv'

    Se il cluster è configurato correttamente, l'output dovrebbe essere vuoto. Se l'output contiene associazioni non predefinite, segui questi passaggi passaggi per ogni associazione aggiuntiva. Se l'output è vuoto, salta il passaggio i seguenti passaggi.

    Se conosci solo il nome del RoleBinding, puoi utilizzare il seguente comando per trovare i RoleBinding corrispondenti in tutti gli spazi dei nomi:

    kubectl get rolebindings -A -o json \
  | jq -r '["Namespace", "Name"], ["---------", "-----"], (.items[] | select((.subjects | length) > 0) | select(.metadata.name == "ROLE_BINDING_NAME") | [.metadata.namespace, .metadata.name]) | @tsv'

    Sostituisci ROLE_BINDING_NAME con il nome del RoleBinding non predefinito.

  2. Elenca le autorizzazioni del ruolo associato all'associazione:

    kubectl get rolebinding ROLE_BINDING_NAME --namespace ROLE_BINDING_NAMESPACE -o json \
    | jq ' .roleRef.name +" " + .roleRef.kind' \
    | sed -e 's/"//g' \
    | xargs -l bash -c 'kubectl get $1 $0 -o yaml --namespace ROLE_BINDING_NAMESPACE'

    Sostituisci quanto segue:

    • ROLE_BINDING_NAME: il nome del ruolo RoleBinding non predefinito.
    • ROLE_BINDING_NAMESPACE: lo spazio dei nomi del RoleBinding non predefinito.

    L'output è simile al seguente:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...
rules:
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - watch
  - list

    Se stabilisci che le autorizzazioni nell'output possono essere concesse in sicurezza al per utenti o gruppi predefiniti, non sono necessarie ulteriori azioni. Se determini che le autorizzazioni concesse dall'associazione non sono sicure, vai alla successiva passaggio.

  3. Elimina un'associazione non sicura dal cluster:

    kubectl delete rolebinding ROLE_BINDING_NAME --namespace ROLE_BINDING_NAMESPACE

    Sostituisci quanto segue:

    • ROLE_BINDING_NAME: il nome dell'associazione dei ruoli eliminare.
    • ROLE_BINDING_NAMESPACE: lo spazio dei nomi del RoleBinding da eliminare.

Definire le autorizzazioni di ambito a livello di spazio dei nomi

Utilizza le associazioni e i ruoli come segue, a seconda delle esigenze del tuo carico di lavoro o dell'utente:

  • Per concedere l'accesso alle risorse in uno spazio dei nomi, utilizza un Role con un RoleBinding.
  • Per concedere l'accesso alle risorse in più di uno spazio dei nomi, utilizza un ClusterRole con un RoleBinding per ogni spazio dei nomi.
  • Per concedere l'accesso alle risorse in ogni spazio dei nomi, utilizza un ClusterRole con un ClusterRoleBinding.

Concedi le autorizzazioni nel minor numero possibile di spazi dei nomi.

Non utilizzare caratteri jolly

Il carattere * è un carattere jolly che si applica a tutto. Evita di utilizzare caratteri jolly nelle regole. Specifica in modo esplicito gruppi di API, risorse e verbi in regole RBAC. Ad esempio, specificando * nel campo verbs verranno concesse le autorizzazioni get, list, watch, patch, update, deletecollection e delete sulle risorse. La tabella seguente mostra esempi di come evitare i caratteri jolly nelle tue regole:

Consigliato Non consigliato 
- rules:
    apiGroups: ["apps","extensions"]
    resources: ["deployments"]
    verbs: ["get","list","watch"]

Concede get, list e verbi watch specificamente per apps e extensions gruppi di API.

 
- rules:
    apiGroups: ["*"]
    resources: ["deployments"]
    verbs: ["get","list","watch"]

Concedi i verbi a deployments in qualsiasi gruppo di API.

 
- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch"]

Concede solo get, list e verbi watch per i deployment in apps e extensions gruppi di API.

 
- rules:
    apiGroups: ["apps", "extensions"]
    resources: ["deployments"]
    verbs: ["*"]

Concedi tutti i verbi, inclusi patch o delete.

Utilizza regole separate per concedere l'accesso con privilegi minimi a risorse specifiche

Quando pianifichi le regole, prova i seguenti passaggi di alto livello per un design più efficiente delle regole con privilegi minimi in ogni ruolo:

  1. Crea una bozza di regole RBAC separate per ogni verbo su ogni risorsa a cui un soggetto deve accedere.
  2. Dopo aver creato le regole, analizzale per verificare se sono presenti più regole hanno lo stesso elenco verbs. Combina queste regole in un'unica regola.
  3. Mantieni separate tutte le regole rimanenti.

Questo approccio consente di progettare regole più organizzate, in cui le regole che concedono gli stessi verbi a più risorse sono combinate e quelle che concedono verbi diversi alle risorse sono separate.

Ad esempio, se il carico di lavoro ha bisogno delle autorizzazioni per deployments risorsa, ma ha bisogno di list e watch sulle risorse daemonsets, dovresti usare regole separate quando si crea un ruolo. Quando colleghi il ruolo RBAC al tuo carico di lavoro, non potrà utilizzare watch su deployments.

Per fare un altro esempio, se il carico di lavoro ha bisogno di get e watch sia su pods e la risorsa daemonsets, puoi combinarle in un'unica perché il carico di lavoro ha bisogno degli stessi verbi su entrambe le risorse.

Nella tabella seguente, entrambi i layout delle regole funzionano, ma le regole di suddivisione sono più limitare l'accesso alle risorse in modo granulare in base alle tue esigenze:

Consigliato Sconsigliato 
- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get"]
- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]

Concede l'accesso get per i deployment e accessi watch e list per i DaemonSet. I soggetti non possono elencare i deployment.

 
- rules:
    apiGroups: ["apps"]
    resources: ["deployments", "daemonsets"]
    verbs: ["get","list","watch"]

Concedi i verbi sia ai deployment che ai DaemonSet. Un soggetto che potrebbe non richiedere l'accesso list agli oggetti deployments lo otterrebbe comunque.

 
- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets", "deployments"]
    verbs: ["list", "watch"]

Combina due regole perché il soggetto ha bisogno degli stessi verbi per le risorse daemonsets e deployments.

 
- rules:
    apiGroups: ["apps"]
    resources: ["daemonsets"]
    verbs: ["list", "watch"]
- rules:
    apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["list", "watch"]

Queste regole di suddivisione avrebbero lo stesso risultato della combinazione ma creare disordine non necessario nel file manifest del ruolo

Limita l'accesso a istanze di risorse specifiche

RBAC ti consente di utilizzare il campo resourceNames nelle regole per limitare l'accesso a per una specifica istanza con nome di una risorsa. Ad esempio, se stai scrivendo un ruolo RBAC che deve update il ConfigMap seccomp-high e nient'altro, puoi utilizzare resourceNames per specificare solo quel ConfigMap. Usa resourceNames ove possibile.

Consigliato Non consigliato 
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Limita il soggetto ad aggiornare solo il ConfigMap seccomp-high. L'oggetto non può aggiornare altri ConfigMap nello spazio dei nomi.

 
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update"]

L'oggetto può aggiornare il ConfigMap seccomp-high e qualsiasi altro ConfigMap nello spazio dei nomi.

 
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["list"]
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["seccomp-high"]
    verbs: ["update"]

Concede a list l'accesso a tutti i ConfigMap nello spazio dei nomi, incluso seccomp-high. Limita Accesso di update solo a seccomp-high o ConfigMap. Le regole sono suddivise perché non puoi concedere list per le risorse con nome.

 
- rules:
    apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["update", "list"]

Concede l'accesso update per tutti i ConfigMap, insieme a Accesso a list.

Non consentire agli account di servizio di modificare le risorse RBAC

Non associare risorse Role o ClusterRole con bind, escalate, Autorizzazioni create, update o patch in rbac.authorization.k8s.io da un gruppo API ad account di servizio in qualsiasi spazio dei nomi. In particolare, escalate e bind possono consentire a un malintenzionato di aggirare i meccanismi di prevenzione della riassegnazione integrati nel RBAC.

Account di servizio Kubernetes

crea un account di servizio Kubernetes per ogni carico di lavoro

Creare un account di servizio Kubernetes separato per ogni carico di lavoro. Associa un ruolo Role o ClusterRole con il privilegio minimo a quell'account di servizio.

Non utilizzare l'account di servizio predefinito

Kubernetes crea un account di servizio denominato default in ogni spazio dei nomi. L'account di serviziodefault viene assegnato automaticamente ai pod che non specificano esplicitamente un account di servizio nel file manifest. Evita di associare un Role o ClusterRole all'account di servizio default. Kubernetes potrebbe assegnare default a un pod che non necessita dell'accesso concesso in questi ruoli.

Non montare automaticamente i token degli account di servizio

Il campo automountServiceAccountToken nella specifica del pod indica a Kubernetes di iniettare un token delle credenziali per un account di servizio Kubernetes nel pod. Il pod può utilizzare questo token per effettuare richieste autenticate ai il server API Kubernetes. Il valore predefinito per questo campo è true.

In tutte le versioni di GKE, imposta automountServiceAccountToken=false nella specifica del pod se i pod non devono comunicare con l'API server.

Preferenza ai token temporanei rispetto ai token basati su secret

Per impostazione predefinita, il processo kubelet sul nodo recupera un token dell'account di servizio di breve durata e con rotazione automatica per ogni pod. Kubelet monta questo token sul pod come volume proiettato, a meno che non imposti il campo automountServiceAccountToken su false nella specifica del pod. Eventuali chiamate all'API Kubernetes dal pod utilizzano questo token per autenticarsi al server API.

Se recuperi manualmente i token dell'account di servizio, evita di utilizzare i secret Kubernetes per archiviare il token. I token degli account di servizio basati su secret sono credenziali legacy che non scadono e non vengono ruotate automaticamente. Se hai bisogno di credenziali per gli account di servizio, utilizza l'API TokenRequest per ottenere token di breve durata che vengono ruotati automaticamente.

Controlla continuamente le autorizzazioni RBAC

Rivedi regolarmente i ruoli e l'accesso RBAC per identificare potenziali percorsi di riassegnazione e regole ridondanti. Ad esempio, considera una situazione in cui non elimini un RoleBinding che lega un Role con privilegi speciali a un utente eliminato. Se un utente malintenzionato crea un account utente in quello spazio dei nomi con lo stesso nome dell'utente eliminato, saranno associati a quell'Role ed erediteranno lo stesso l'accesso. Le revisioni periodiche riducono al minimo questo rischio.

Riepilogo elenco di controllo

Passaggi successivi