Din nou despre RBAC în Kubernetes

Într-un alt articol am povestit un pic despre ce este și la ce ajută RBAC și am făcut un scurt exercițiu pentru a înțelege mai bine funcționarea sa cu ServiceAccounts. Vom continua exersarea RBAC în articolul de față, dar de această dată cu utilizatori reali.

Exercițiu

1. Creați un namespace apps.
2. Userul bobses trebuie să aibă permisiunea de a vizualiza resursele din toate namespaceurile, mai puțin pe cele de kube-system (se va folosi ClusterRole-ul default view).
3. Userul bobses trebuie să poată vizualiza secretele din namespace-ul apps. Doar secretele, fără date.
4. Verificare folosind comanda kubectl auth can-i.
5. Verificare folosind un user existent bobses creat ca în acest articol.

1. Creare namespace

kubectl create ns apps

2. RBAC - creare rol și rolebinding

kubectl -n apps create role bobses --verb create,delete --resource pods,deployments,sts
kubectl -n apps create rolebinding bobses --role bobses --user bobses

3. RBAC - vizualizare resurse, mai pușin pe cele din kube-system

Cu ajutorul RBAC putem doar crearea roluri care PERMIT ceva, nu care RESPING. Așadar, vom vedea prima dată care sunt namespace-urile existente și vom acorda drepturi de vizualizare userului bobses pe toate namespace-urile, mai puțin pe kube-system (vom face câte un rolebinding între rolul bobses și ClusterRolul existent view:

kubectl get ns
kubectl -n apps create rolebinding bobses-view --clusterrole view --user bobses
kubectl -n default create rolebinding bobses-view --clusterrole view --user bobses
kubectl -n kube-node-lease create rolebinding bobses-view --clusterrole view --user bobses
kubectl -n kube-public create rolebinding bobses-view --clusterrole view --user bobses

4. RBAC - vizualizare doar nume de secrete

NU se poate realiza acest lucru cu ajutorul RBAC - dacă, din greșeală, facem un rol și-i permitem să afișeze secretele (kubectl -n apps create role list-secrets --verb list --resource secrets, apoi kubectl -n apps create rolebinding bobses --role bobses --user bobses), la rularea comenzii kubectl get secrets -oyaml vom vedea și conținutul lor.

Ne reamintim căClusterRolul view nu permite vizualizarea secretelor în niciun namespace.

5. Verificare

kubectl auth can-i create deployments --as bobses -n apps <-- este PERMIS
kubectl auth can-i delete deployments --as bobses -n apps <-- este PERMIS
kubectl auth can-i delete pods --as bobses -n apps <-- este PERMIS
kubectl auth can-i delete sts --as bobses -n apps <-- este PERMIS
kubectl auth can-i delete secrets --as bobses -n apps <-- NU este PERMIS
kubectl auth can-i list deployments --as bobses -n apps <-- este PERMIS
kubectl auth can-i list secrets --as bobses -n apps <-- NU este PERMIS

# view in all namespaces but not kube-system
kubectl auth can-i list pods --as bobses -n default <-- este PERMIS
kubectl auth can-i list pods --as bobses -n apps <-- este PERMIS
kubectl auth can-i list pods --as bobses -n kube-public <-- este PERMIS
kubectl auth can-i list pods --as bobses -n kube-node-lease <-- este PERMIS
kubectl auth can-i list pods --as bobses -n kube-system <-- NU este PERMIS

6. Verificare cu user real bobses

Vom folosi petru verificare userul bobses creat în articolul precedent - Utilizatori și certificate în kubernetes.

Nu trebuie decât să schimbăm contextul și să începet să lucrăm ca userul bobses:

kubectl config get-contexts  <-- listăm contextele existente
kubectl config use-context bobses  <-- schimbăm contextul pe userul bobses
kubectl get no <-- nu putem afișa nodurile
kubectl get po <-- putem vizualiza podurile în ns-ul default
kubectl get po -n apps <-- putem vizualiza podurile în ns-ul apps

7. 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.