Explicaţie:
Pentru ce este destinat CAPSYSADMIN?
Capacitățile Linux sunt un subiect larg în sine, dar pe scurt, după cum puteți citi Aici:
Începând cu kernelul 2.2, Linux împarte privilegiile
asociat în mod tradițional cu superutilizatorul în unități distincte,
cunoscut sub numele de capabilități, care pot fi activate independent și
dezactivat. Capabilitățile sunt un atribut pe fir.
Deci, cu alte cuvinte, sunt unități distincte care pot fi folosite pentru a controla escaladarea privilegiilor în sistemul de operare Linux.
Și CAP_SYS_ADMIN este unul dintre ele și, de fapt, este unul destul de puternic. Permite efectuarea unei game de operațiuni de administrare a sistemului, privilegiate care nu pot fi efectuate de un utilizator normal. Pentru lista completă vă rugăm să consultați acest document și Ctrl+f pentru CAP_SYS_ADMIN.
După cum vă puteți imagina, din perspectiva securității, utilizarea acestei capacități nu este recomandată, cu excepția cazului în care este absolut necesar. Acest lucru este în conformitate cu principiul cel mai mic privilegiu ceea ce înseamnă practic „acordarea unui cont de utilizator sau procesarea numai a acelor privilegii care sunt esențiale pentru a-și îndeplini funcția prevăzută”.
Dar să revenim la contextul kubernetes, AKS și Azur deoarece probabil că ești încă curios cum se potrivește tot ceea ce am menționat mai sus acolo.
Pod-urile sunt activate implicit cu această proprietate?
Nu, nu este decât dacă îl activați în mod explicit în a Pod definiție. Deci avertismentul pe care îl primiți nu este despre faptul că această capacitate este utilizată de oricare dintre podurile dvs., ci mai degrabă despre posibilitatea ca această proprietate să poată fi utilizată de oricare dintre utilizatorii dvs. care sunt autorizați să creeze noi poduri în AKS cluster. Cu alte cuvinte, în acest moment, păstăi care fac pârghie CAP_SYS_ADMIN capacitatea poate fi creată pe dvs AKS cluster.
Mai jos puteți vedea un exemplu de astfel de Pod:
apiVersion: v1
fel: Pod
metadate:
nume: security-context-demo-4
specificație:
containere:
- nume: sec-ctx-4
imagine: gcr.io/google-samples/node-hello:1.0
securityContext:
capacitati:
adăugați: ["SYS_ADMIN"]
Pentru mai multe detalii vă rugăm să consultați Setați capabilități pentru un container secțiunea din documentele oficiale kubernetes.
Îl poți testa cu ușurință pe cont propriu și vei vedea că cele de mai sus Pod va fi creat cu succes deoarece nu este interzis acum în niciun fel.
Atunci poți kubectl exec la asa ceva Pod și verifică asta CAP_SYS_ADMIN capacitatea este într-adevăr folosită de acesta. Pur și simplu rulați:
kubectl exec -it security-context-demo-4 -- /bin/bash
Odată conectat la Pod poti rula:
capsh --print | grep cap_sys_admin
Și o să vezi asta cap_sys_admin capacitatea este activată.
Puteți verifica același lucru în a Pod care nu folosește această capacitate:
apiVersion: v1
fel: Pod
metadate:
nume: security-context-demo-4-1
specificație:
containere:
- nume: sec-ctx-4
imagine: gcr.io/google-samples/node-hello:1.0
Cand tu kubectl exec în ea:
kubectl exec -ti security-context-demo-4-1 -- /bin/bash
și rulați aceeași comandă:
capsh --print | grep cap_sys_admin
veți vedea că nu este activat implicit.
Soluţie:
Cu toate că AKS este un serviciu kubernetes gestionat și, de fapt, o mulțime de straturi de securitate sunt deja gestionate pentru dvs. de către Microsoft, încă vi se acordă o gamă destul de largă de responsabilități atunci când vine vorba de gestionarea dvs. AKS cluster. Puteți de ex. efectuați câteva acțiuni suplimentare pe cont propriu pentru a-l face și mai sigur.
Vestea bună este că nu ești lăsat complet singur cu astfel de sarcini și ți se oferă o mulțime de soluții gata pe care le poți aplica pur și simplu în mediul tău Azure.
Unul dintre ei este Centrul de securitate Azure, ceea ce vă scutește de sarcina de a detecta pe cont propriu noi amenințări potențiale în configurația actuală. După cum puteți citi Aici recomandarea Clusterele Kubernetes nu ar trebui să acorde capabilități de securitate CAPSYSADMIN face parte din Noi recomandări pentru consolidarea clusterelor Kubernetes care sunt încă în previzualizare, așa că este posibil să nu le fi văzut până acum:
Noi recomandări pentru consolidarea clusterelor Kubernetes (în previzualizare)
Următoarele recomandări vă permit să vă întăriți și mai mult
clustere Kubernetes
- Clusterele Kubernetes nu ar trebui să utilizeze spațiul de nume implicit - Pentru a proteja împotriva accesului neautorizat pentru ConfigMap, Pod, Secret,
Tipurile de resurse Service și ServiceAccount împiedică utilizarea
spațiu de nume implicit în clusterele Kubernetes.
- Clusterele Kubernetes ar trebui să dezactiveze montarea automată a acreditărilor API - Pentru a preveni o resursă Pod potențial compromisă
de la rularea comenzilor API împotriva clusterelor Kubernetes, dezactivați
montarea automată a acreditărilor API.
- Clusterele Kubernetes nu ar trebui să acorde capabilități de securitate CAPSYSADMIN
Atunci care va fi motivul acestei alerte?
Având în vedere cele de mai sus, se poate răspunde la această întrebare: pentru a vă oferi posibilitatea de a vă îmbunătăți securitatea clusterului kubernetes reducând suprafața potențială de atac a containerelor dumneavoastră. Dar depinde în întregime de tine dacă te hotărăști să urmezi sau nu această recomandare.
Atât pentru partea de detectare a amenințărilor. Dar partea de remediere?
Și cum putem remedia această alertă?
Politici Azure este raspunsul pentru asta. Poate ai auzit deja despre ele. Din fericire, pentru a remedia această amenințare specială, nu trebuie să vă scrieți propria politică personalizată, așa cum o oferă Azure definiții de politică încorporate pentru Azure Kubernetes Service și puteți pur și simplu să le folosiți pe dvs AKS cluster.
În prima coloană vi se oferă link direct către portalul Azure, care vă va duce la pagina de definire a politicii, unde puteți examina detaliile acesteia și unde poate fi atribuită unui anumit abonament și grup de resurse:
Pentru mai multe detalii vă rugăm să consultați:
Alte link-uri utile:
