Despre Linux

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

Din nou despre RBAC în Kubernetes

4 august 2021 By Bobses Lasă un comentariu

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

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

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}