Despre Linux

  • Facebook
  • Twitter
  • LinkedIn
  • Acasă
  • Linux
    • Comenzi Linux
    • Tutoriale
  • Kubernetes
  • RHCSA
    • Exerciții RHCSA
    • SELinux
    • Permisiuni
  • General
    • Open source
  • Contact

Role-based access control (RBAC) în Kubernetes

26 iulie 2021 By Bobses 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.

Partajează asta:

  • Dă clic pentru a partaja pe Facebook(Se deschide într-o fereastră nouă)
  • Dă clic pentru a partaja pe LinkedIn(Se deschide într-o fereastră nouă)
  • Dă clic pentru a partaja pe Twitter(Se deschide într-o fereastră nouă)

Similare

Din categoria: Tutoriale Etichete: k8s, kubernetes, namespace, RBAC, serviceaccount

Trackbacks

  1. Din nou despre RBAC în Kubernetes | Despre Linux spune:
    4 august 2021 la 8:32

    […] 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. […]

    Răspunde

Lasă un răspuns Anulează răspunsul

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

Copyright © 2023 · Bobses

Administrează consimțămintele pentru cookie-uri
Pentru a oferi cea mai bună experiență, folosim tehnologii, cum ar fi cookie-uri, pentru a stoca și/sau accesa informațiile despre dispozitive. Consimțământul pentru aceste tehnologii ne permite să procesăm date, cum ar fi comportamentul de navigare sau ID-uri unice pe acest site. Dacă nu îți dai consimțământul sau îți retragi consimțământul dat poate avea afecte negative asupra unor anumite funcționalități și funcții.
Funcționale Mereu activ
Stocarea tehnică sau accesul sunt strict necesare în scopul legitim de a permite utilizarea unui anumit serviciu cerut în mod explicit de către un abonat sau un utilizator sau în scopul exclusiv de a executa transmiterea unei comunicări printr-o rețea de comunicații electronice.
Preferințe
Stocarea tehnică sau accesul este necesară în scop legitim pentru stocarea preferințelor care nu sunt cerute de abonat sau utilizator.
Statistici
Stocarea tehnică sau accesul care sunt utilizate exclusiv în scopuri statistice. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
Stocarea tehnică sau accesul sunt necesare pentru a crea profiluri de utilizator pentru a trimite publicitate sau pentru a urmări utilizatorul pe un site web sau pe mai multe site-uri web în scopuri de marketing similare.
Administrează opțiunile Administrează serviciile Administrează vânzătorii Citește mai multe despre aceste scopuri
Vizualizează preferințele
{title} {title} {title}