Despre Linux

Role-based access control (RBAC) în Kubernetes

By Un comentariu

RBAC este o metodă de reglementare a accesului la un computer sau la o rețea și se bazează pe rolurile utilizatorilor individuali.

În Kubernetes, autorizarea RBAC folosește grupul API rbac.authorization.k8s.io pentru a lua deciziile de autorizare, permițând configurarea dinamică a politicilor de acces prin intermediul API-ului Kubernetes.

Pentru a activa RBAC, API serverul trebuie pornit cu flagul --authorization-mode setat pe RBAC:

--authorization-mode=RBAC

Pe scurt, un utilizator/ServiceAccount se leagă la un rol: user --> rolebinding --> role.

Rolurile pot fi definite la nivel de namespace sau la nivel de cluster (ClusterRole). Cu ajutorul RBAC, controlăm la nivel granular ceea ce utilizatorii finali (users sau ServiceAccounts) au voie să facă. Putem atribui anumite drepturi administratorilor, dezvoltatorilor sau altor grupe de utilizatori.

Pentru tutorialul de azi, poate fi folosit atât clusterul Kubernetes făcut cu k3s din Oracle Cloud, cât și un alt cluster k8s instalat local în KVM sau Virtualbox.

Exerciții RBAC

Cerințe:

  1. crearea a două namespace-uri: ns1 și ns2
  2. crearea unui ServiceAccount exemplu în fiecare din cele 2 namespace-uri
  3. aceste ServiceAccount-uri trebuie să poată vizualiza aproape totul în cluster - poate fi folosit ClusterRolul existent view
  4. ServiceAccount-urile trebuie să poată crea și șterge deploymenturi în namespace-urile ns1 și ns2
  5. verificare

Creare namespace-uri

kubectl create ns ns1
kubectl create ns ns2

Creare ServiceAccounts

kubectl create sa prince -n ns1
kubectl create sa prince -n ns2
kubectl get sa -A | grep prince

Vizualizarea întregului cluster

Vom vedea ce poate face clusterrolul view existent în cluster:

kubectl get clusterrole view
kubectl describe clusterrole view

Acum, trebuie să legăm ServiceAccountul prince din cele 2 namespace-uri de ClusterRolul view. Pentru asta, vom crea un ClusterRoleBinding:

kubectl create clusterrolebinding --help  --> obținem informații ajutătoare și exemple despre comandă
kubectl create clusterrolebinding prince-view --clusterrole view --serviceaccount ns1:prince --serviceaccount ns2:prince
kubectl get clusterrolebinding | grep prince
kubectl describe clusterrolebinding prince-view

Observăm că noul ClusterRoleBinding creat leagă ClusterRolul view de cele două ServiceAccounturi create anterior:

kubectl describe clusterrolebinding
kubectl describe clusterrolebinding

RBAC: gestionarea deploymenturilor în cele 2 namespaceuri

Pentru a permite celor 2 SA să poată crea și șterge deploymenturi în namespaceurile ns1 și ns2, avem 2 variante:

  • crearea unui clusterrole care va fi legat prin intermediul a două rolebinding-uri de cele două serviceaccounturi:
kubectl create clusterrole -h ---> exemple de utilizare a comenzii
kubectl create clusterrole prince-deployment-manager --verb create,delete --resource deployments
kubectl describe clusterrole prince-deployment-manager ---> vedem descrierea noului clusterrole 

# creare rolebindings
kubectl create rolebinding -h ---> exemple de utilizare a comenzii
kubectl -n ns1 create rolebinding prince-deployment-manager --clusterrole prince-deployment-manager --serviceaccount ns1:prince
kubectl -n ns2 create rolebinding prince-deployment-manager --clusterrole prince-deployment-manager --serviceaccount ns2:prince

# descriere a noilor rolebindings
kubectl describe rolebinding prince-deployment-manager -n ns1
kubectl describe rolebinding prince-deployment-manager -n ns2
  • crearea a două roluri identice în cele 2 ns-uri care vor fi legate prin 2 rolebinding-uri de cele două serviceaccounturi:
kubectl create role -h ---> exemple de folosire a comenzii
kubectl create role prince-deployment-manager --verb create,delete --resource deployments -n ns1
kubectl create role prince-deployment-manager --verb create,delete --resource deployments -n ns2

kubectl create rolebinding -h ---> exemple de folosire a comenzii
kubectl -n ns1 create rolebinding prince-deployment-manager -n ns1 --role prince-deployment-manager --serviceaccount ns1:prince
kubectl -n ns2 create rolebinding prince-deployment-manager -n ns2 --role prince-deployment-manager --serviceaccount ns2:prince

Verificare

Vom folosi comanda kubectl auth can-i - câteva explicații despre referențierea namespace-serviceaccount aici.

kubectl auth can-i --help ---> exemple pentru folosirea comenzii

kubectl auth can-i delete deployments --as system:serviceaccount:ns1:prince -n ns1 ---> este PERMIS
kubectl auth can-i create deployments --as system:serviceaccount:ns1:prince -n ns1 ---> este PERMIS
kubectl auth can-i update deployments --as system:serviceaccount:ns1:prince -n ns1 ---> NU este permis actualizarea deploymenturilor în ns-ul ns1
kubectl auth can-i update deployments --as system:serviceaccount:ns1:prince -n default ---> NU este permisă actualizarea depliymenturilor în ns-ul default
kubectl auth can-i delete deployments --as system:serviceaccount:ns1:prince -n default ---> NU este permisă ștergerea deploymenturilor în ns-ul default
kubectl auth can-i delete deployments --as system:serviceaccount:ns2:prince -n ns2 ---> este PERMIS
kubectl auth can-i create deployments --as system:serviceaccount:ns2:prince -n ns2 ---> este PERMIS
kubectl auth can-i update deployments --as system:serviceaccount:ns2:prince -n ns2 ---> NU este permis actualizarea deploymenturilor în ns-ul ns2
kubectl auth can-i update deployments --as system:serviceaccount:ns2:prince -n default ---> NU este permisă actualizarea depliymenturilor în ns-ul default
kubectl auth can-i delete deployments --as system:serviceaccount:ns2:prince -n default ---> NU este permisă ștergerea deploymenturilor în ns-ul default
kubectl auth can-i list deployments --as system:serviceaccount:ns1:prince -n ns1 ---> este PERMISĂ listaera deploymenturilor în ns1
kubectl auth can-i list deployments --as system:serviceaccount:ns1:prince -A ---> este PERMISĂ listarea deploymenturilor în TOATE namespaceurile
kubectl auth can-i list pods --as system:serviceaccount:ns1:prince -A  ---> este PERMISĂ listarea podurilor în TOATE namespaceurile
kubectl auth can-i list pods --as system:serviceaccount:ns2:prince -A ---> este PERMISĂ listarea podurilor în TOATE namespaceurile
kubectl auth can-i list secrets --as system:serviceaccount:ns1:prince -A ---> NU este permisă listarea secretelor (rolul default view NU permite acest lucru)
kubectl auth can-i list secrets --as system:serviceaccount:ns2:prince -A ---> NU este permisă listarea secretelor (rolul default view NU permite acest lucru)

Observăm că ClusterRolul view nu permite vizualizarea secretelor în niciun namespace.

6. Demonstrație

Concluzii

Gestionarea și auditul accesului la un cluster kubernetes sunt esențiale pentru securitatea informațiilor. Securitatea este menținută mai ușor prin limitarea accesului inutil al persoanelor la anumite informații sensibile, limitare care se realizează ușor pe baza rolurilor stabilite pentru fiecare utilizator sau ServiceAccount.

Întotdeauna vom căuta să ne ghidăm după principiul celui mai mic privilegiu acordat userilor sau ServiceAccounturilor (PoLP - Least Privilege Principle). Vom acorda o atenție deosebită ClusterRoleBindings deoarece acestea oferă acces la întregul cluster (cluster-wide access) atât în namespaceurile existente, cât și în cele viitoare.

Trackbacks

Lasă un răspuns

Acest site folosește Akismet pentru a reduce spamul. Află cum sunt procesate datele comentariilor tale.