Sysdig
Learn Cloud Native

Sign up to receive our newsletter

RBAC di Kubernetes: concetti chiave ed esempi

Kubernetes non è una piattaforma per la sicurezza. Manca infatti degli strumenti nativi per gestire la maggior parte delle attività legate alla sicurezza, come il rilevamento delle vulnerabilità delle applicazioni e il monitoraggio delle violazioni.

Tuttavia, esiste un task di sicurezza che Kubernetes gestisce benissimo in modo nativo: il controllo degli accessi basato sui ruoli, o Role-Based Access Control (RBAC). Kubernetes offre un sistema RBAC integrato e completo. Utilizzare a proprio vantaggio questo sistema è il primo passo per proteggere i cluster e le applicazioni su Kubernetes.

Questo articolo spiega i concetti chiave alla base di RBAC di Kubernetes, dimostra in che modo utilizzare le policy RBAC e mette in evidenza le migliori prassi da seguire e gli errori da evitare quando si lavora con RBAC.

RBAC di Kubernetes: concetti di base

Con una certa probabilità, chi ci legge conoscerà già l’RBAC come principio generale. In molti contesti (come i sistemi operativi e il cloud pubblico), i sistemi RBAC possono essere utilizzati per definire chi può accedere a cosa in base alle identità degli utenti.

RBAC di Kubernetes si basa proprio su questi concetti. Tuttavia, differisce in alcuni aspetti da molti degli altri sistemi RBAC:

Account utente vs. account di servizio

In Kubernetes, le policy RBAC possono essere utilizzate per definire i diritti di accesso di utenti umani (o gruppi di utenti umani). Kubernetes identifica gli utenti umani come account utenti.

Tuttavia, le policy RBAC possono anche gestire il comportamento di risorse software, che Kubernetes identifica come account di servizio.

Sebbene Kubernetes operi una distinzione tra account utente e account di servizio a livello concettuale, la differenza non è realmente rilevante per le policy RBAC. Questo rende RBAC di Kubernetes diverso da qualunque altro sistema RBAC, che di solito si concentra sulla gestione delle autorizzazioni di utenti umani (in base a fattori quali il loro ruolo o il tipo di account) e non sulla gestione degli accessi di servizi software.

Definizioni di risorse flessibili

Kubernetes definisce in maniera piuttosto ampia le entità che le policy RBAC possono gestire.

Kubernetes si riferisce a queste entità come “risorse,” che in realtà possono essere quasi tutto ciò che si desidera: pod, registri, controller di ingresso o qualunque altro tipo di risorsa personalizzata si scelga di definire.

Molti sistemi RBAC tendono a essere più restrittivi circa i tipi di risorse che è possibile gestire. Per esempio, gli strumenti IAM cloud sono pensati per gestire solo alcuni tipi predefiniti di risorse, come le macchine virtuali o i bucket di archiviazione. (Potrebbe essere possibile anche utilizzare tag per controllare quali policy applicare a quali risorse, ma questa operazione risulta meno scalabile rispetto all’approccio di Kubernetes, perché ogni tag dovrebbe essere creato manualmente).

Roles vs. ClusterRoles

Una peculiarità piuttosto semplice ma importante del sistema RBAC di Kubernetes è che opera una distinzione tra le autorizzazioni che si riferiscono alle risorse all’interno di un namespace, gestite attraverso Roles, e quelle che si riferiscono a tutto il cluster, gestite attraverso ClusterRoles.

In molti casi si lavora con i Roles, che possono essere utilizzati per gestire le autorizzazioni su base più granulare (ovvero, all’interno di singoli namespace). Ma a volte potrebbe essere necessario utilizzare ClusterRoles per gestire regole relative a risorse che esistono solo a livello di cluster, come i nodi.

Gestione delle autorizzazioni mediante “verbi”

Diversamente dai sistemi di controllo che possono solo consentire o negare gli accessi, o dai sistemi che suddividono i diritti di accesso in categorie generiche quali “leggere”, “scrivere” ed “eseguire”, RBAC di Kubernetes prevede una serie di “verbi” che definiscono azioni specifiche che gli account possono svolgere sulle risorse.

Per esempio, è possibile consentire a un utente di “creare” ed “elencare” una data risorsa specificando i verbi corrispondenti in una policy RBAC.

È possibile ottenere un elenco di tutti i verbi disponibili nel cluster eseguendo:

kubectl api-resources --verbs=list --namespaced -o name | xargs -n 1 kubectl get --show-kind --ignore-not-found -l <label>=<value> -n <namespace>
Code language: HTML, XML (xml)

Lavorare con RBAC di Kubernetes: passaggi ed esempi

Ora che conosciamo le nozioni di base di RBAC di Kubernetes, diamo un’occhiata a come utilizzarle.

Controllare se RBAC è supportato

Innanzi tutto, bisogna accertarsi del fatto che il cluster supporti RBAC. RBAC è stato introdotto con Kubernetes 1.6, e molti cluster lo abilitano in maniera predefinita, tuttavia non fa mai male controllare.

Bisogna cercare il file di configurazione RBAC in /etc/kubernetes/manifests sul nodo master o sul pod del server API di Kubernetes e controllare che contenga il flag:

--authorization-mode=Node,RBAC

Definire account utente e account di servizio

Successivamente, è necessario definire account utente e/o di servizio a cui più tardi verranno assegnate le autorizzazioni. Per semplificare, ecco i passaggi necessari per creare un account utente per un utente che si chiama John. 

Per iniziare, creare una nuova chiave privata:

openssl genrsa -out john.key 2048
Code language: CSS (css)

Successivamente, creare una richiesta di firma certificato contenente la chiave pubblica e altre

informazioni sul soggetto:

openssl req -new -key john.key -out john.csr -subj "/CN=john/ O=examplegroup"
Code language: PHP (php)

Si noti che Kubernetes utilizzerà il campo Organization (O=examplegroup) per determinare il gruppo a cui

appartiene l’utente per RBAC.

La richiesta di firma certificato verrà firmata utilizzando la root Kubernetes CA, che si trova in /etc/kubernetes/pki per questo esempio (la posizione del file potrebbe variare in base alla distribuzione):</p

openssl x509 -req -in john.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out john.crt Signature ok subject=/CN=john/O=examplegroup Getting CA Private Key
Code language: JavaScript (javascript)

Signature ok

subject=/CN=john/O=examplegroup

Ottenimento della chiave privata CA

È ora possibile controllare il nuovo certificato:

openssl x509 -in john.crt -text Certificate: Data: Version: 1 (0x0) Serial Number: 11309651818125161147 (0x9cf3f46850b372bb) Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes Validity Not Before: Apr 2 20:20:54 2018 GMT Not After : May 2 20:20:54 2018 GMT Subject: CN=john, O=examplegroup Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit)
Code language: PHP (php)

Infine, è necessario registrare le nuove credenziali e il contesto di configurazione:

kubectl config set-credentials john --client-certificate=/home/newusers/john.crt --client- key=/home/newusers/john.key kubectl config set-context [email protected] --cluster=kubernetes --user=john
Code language: JavaScript (javascript)

Creare un Role o ClusterRole

A questo punto, è necessario creare un Role o ClusterRole. Questo è il punto in cui si definiscono le azioni che possono essere effettuate su una risorsa.

Per esempio, ecco definito un ruolo che consente di ottenere, visualizzare ed elencare le autorizzazioni per i pod.

apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"]
Code language: PHP (php)

Creare un RoleBinding o ClusterRoleBinding

Infine, è necessario “legare” il nostro Role o ClusterRole all’utente o all’account creato. Questo procedimento è quello che consente a utenti o account specifici di svolgere le azioni assegnate al ruolo dato.

kubectl create rolebinding podreader-binding --user=john

Migliori prassi per RBAC di Kubernetes

RBAC di Kubernetes è uno strumento potente. Di seguito elenchiamo le migliori prassi per utilizzarlo nel modo più responsabile possibile.

Minimizzare i flag del server API

L’API di Kubernetes presenta un numero di flag opzionali che, se attivati, possono semplificare alcuni aspetti gestionali di Kubernetes. Ma aumentano anche i rischi per la sicurezza. Evitare questi flag per quanto possibile:

  • –insecure-port: Apre l’accesso a richieste non autorizzate e non autenticate. Se questo

parametro è uguale a 0, significa che non sono presenti porte non sicure.

  • –insecure-bind-address: Idealmente, bisognerebbe evitare le connessioni non sicure in generale, ma nel caso in cui siano davvero necessarie, è possibile utilizzare questo parametro per legarle solo al localhost. Verificare che questo parametro non sia impostato, o che almeno non sia collegato a un indirizzo IP raggiungibile dalla rete.
  • –anonymous-auth: Consente richieste anonime alla porta sicura del server API.

Seguire il principio dei privilegi minimi

Come accade per qualunque sistema RBAC, anche il sistema RBAC di Kubernetes è più efficace se gli amministratori seguono il principio dei privilegi minimi, il che significa che ogni utente o account riceve solo i privilegi minimi necessari per svolgere il proprio lavoro.

In pratica, questo significa ad esempio utilizzare Roles al posto di ClusterRoles quando possibile. Anche se impostare i Roles per ciascun namespace sia un po’ più complesso che definire un ClusterRole per tutto il cluster, i Roles sono più sicuri perché si riferiscono a un numero minore di risorse.

Allo stesso modo, evitare gli asterischi [“*”] quando si definiscono i verbi o si accede alle risorse. Gli asterischi sono il “chmod 777” di Kubernetes: sono comodi da applicare ma aprono a qualunque tipo di accesso non autorizzato.

Evitare gli account di servizio predefiniti 

Kubernetes crea account di servizio predefiniti per individuare i processi in esecuzione in un pod.

Si potrebbe essere tentati di utilizzare questi account predefiniti per assegnare le autorizzazioni invece che prendersi la briga di impostare i propri account. Ma questa non è una migliore prassi. Piuttosto, è meglio creare account di servizio specifici per porre le basi di un controllo degli accessi più granulare.

E a proposito di questo argomento, Kubernetes non prevede account utente predefiniti, quindi non è necessario preoccuparsi di questo problema. Gli utenti devono essere tutti creati esplicitamente se si desidera assegnare loro Roles o ClusterRoles.

Aggiornare continuamente le policy RBAC

Il sistema RBAC di Kubernetes è efficace solo tanto quanto le policy che vengono create. E se le policy diventano obsolete, si potrebbe rapidamente finire per avere account utente o di servizio a cui sono assegnati permessi troppo eccessivi.

Per questa ragione, è fortemente consigliabile garantire che tutte le volte in cui si crea, si rimuove o si aggiorna un’autorizzazione per un account utente o di servizio, oppure quando si crea un namespace o un pod, si modifichino o eliminino anche tutte le policy RBAC associate all’entità in questione. Questa operazione potrebbe essere fastidiosa, dato che Kubernetes presenta diversi tipi di file associati a RBAC (Roles, RoleBindings, ClusterRoles e ClusterRoleBindings). Tuttavia, è importante fare sì che l’aggiornamento delle policy RBAC diventi una parte continua e sistematica della gestione di Kubernetes.

Sfruttare al massimo RBAC di Kubernetes

È impossibile eseguire un cluster Kubernetes sicuro di qualunque dimensione senza utilizzare RBAC. Sebbene potrebbe essere possibile cavarsela senza utilizzare le policy RBAC se si esegue un cluster a nodo singolo su un laptop a scopo di test, un cluster con più utenti, pod e namespace necessita di policy RBAC per definire chi e cosa può svolgere quale azione all’interno del cluster.

Quindi, sebbene l’approccio di Kubernetes a RBAC possa sembrare piuttosto strano per certi aspetti e non sia sempre il sistema più semplice con il quale lavorare, investire del tempo per comprendere come funziona il sistema RBAC in Kubernetes e in che modo possa essere usato efficacemente è la migliore prassi per proteggere un qualunque ambiente di produzione in Kubernetes.