ProHoster > Blog > Administrimi > ABC e sigurisë në Kubernetes: autentikimi, autorizimi, auditimi

ABC e sigurisë në Kubernetes: autentikimi, autorizimi, auditimi

ABC e sigurisë në Kubernetes: autentikimi, autorizimi, auditimi

Dhe njĂ« ditĂ«, nĂ« pĂ«rdorimin e çdo sistemi, ngrihet çështja e sigurisĂ«: garantimi i autentifikimit, ndarja e tĂ« drejtave, auditimi dhe detyra tĂ« tjera. PĂ«r Kubernetes ka tashmĂ« njĂ« shumĂ« zgjidhjesh, tĂ« cilat lejojnĂ« arritjen e pĂ«rputhshmĂ«risĂ« me standardet edhe nĂ« mjedise mjaft kĂ«rkuese
 Ky material Ă«shtĂ« i pĂ«rkushtuar ndaj aspekteve themelore tĂ« sigurimit, tĂ« realizuara brenda mekanizmave tĂ« integruar tĂ« K8s. NĂ« radhĂ« tĂ« parĂ«, kjo do tĂ« jetĂ« e dobishme pĂ«r ata qĂ« fillojnĂ« tĂ« njoftohen me Kubernetes, si njĂ« pikĂ«nisje pĂ«r studimin e çështjeve qĂ« lidhen me sigurinĂ«.

Autentifikimi

Në Kubernetes ka dy lloje përdoruesish:

  • LlogaritĂ« e ShĂ«rbimit — llogari e menaxhuar nga Kubernetes API;
  • PĂ«rdoruesit — pĂ«rdorues normalĂ«, tĂ« menaxhuar nga shĂ«rbime tĂ« jashtme dhe tĂ« pavarura.

Dallimi kryesor midis kĂ«tyre lirave Ă«shtĂ« se pĂ«r LlogaritĂ« e ShĂ«rbimit ekzistojnĂ« objekte speciale nĂ« Kubernetes API (ato quhen gjithashtu — LlogaritĂ« e ShĂ«rbimit), tĂ« cilat janĂ« tĂ« lidhura me hapĂ«sirĂ«n emĂ«rore dhe njĂ« grup tĂ« dhĂ«nash autorizimi, tĂ« ruajtura nĂ« klaster nĂ« objekte tĂ« tipit Secrets. KĂ«ta pĂ«rdorues (LlogaritĂ« e ShĂ«rbimit) janĂ« tĂ« destinuar kryesisht pĂ«r menaxhimin e tĂ« drejtave tĂ« aksesit nĂ« Kubernetes API tĂ« proceseve qĂ« funksionojnĂ« nĂ« klasterin Kubernetes.

Përdoruesit e zakonshëm nuk kanë regjistrime në Kubernetes API: menaxhimi i tyre duhet të kryhet nga mekanizma të jashtëm. Ato janë të destinuara për njerëz ose procese që jetojnë jashtë klasterit.

Çdo kĂ«rkesĂ« pĂ«r API Ă«shtĂ« e lidhur me njĂ« hesap shĂ«rbimi, njĂ« pĂ«rdorues, ose konsiderohet si anonime.

Të dhënat autentikuese të përdoruesit përfshijnë:

  • Emri i pĂ«rdoruesit — emri i pĂ«rdoruesit (varet nga rastisja!);
  • UID — njĂ« varg identifikimi qĂ« 'Ă«shtĂ« mĂ« konsistent dhe unik se emri i pĂ«rdoruesit';
  • Grupet — lista e grupeve tĂ« cilave i pĂ«rket pĂ«rdoruesi;
  • Extra — fusha shtesĂ« qĂ« mund tĂ« pĂ«rdoren nga mekanizmi i autorizimit.

Kubernetes mund të përdorë një numër të madh mekanizmash autentikimi: certifikata X509, Bearer tokena, proxy autentikimi, HTTP Basic Auth. Me këta mekanizma mund të realizohet një gamë e gjerë skemash autorizimi: nga një skedë statike me fjalëkalime deri në OpenID OAuth2.

Më tepër, lejohet përdorimi i disa skemave autorizimi njëkohësisht. Në mënyrë të parazgjedhur në klaster përdoren:

  • tokens e shĂ«rbimit — pĂ«r Hesape ShĂ«rbimi;
  • X509 — pĂ«r PĂ«rdoruesit.

Çështja e menaxhimit tĂ« ServiceAccounts del jashtĂ« kornizĂ«s sĂ« kĂ«tij artikulli, dhe atyre qĂ« dĂ«shirojnĂ« tĂ« njohin mĂ« shumĂ« rreth kĂ«tij problemi, rekomandoj tĂ« fillojnĂ« me faqen e dokumentacionit zyrtar. Ne do tĂ« shqyrtojmĂ« mĂ« thellĂ« çështjen e punĂ«s me sertifikatat X509.

Sertifikatat për përdoruesit (X.509)

Mënyra klasike e punës me sertifikatat supozon:

  • gjenerimin e çelĂ«sit:
    mkdir -p ~/mynewuser/.certs/
openssl genrsa -out ~/.certs/mynewuser.key 2048
  • gjenerimin e njĂ« kĂ«rkese pĂ«r sertifikatĂ«:
    openssl req -new -key ~/mynewuser/.certs/mynewuser.key -out ~/mynewuser/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"
  • pĂ«rpunimin e kĂ«rkesĂ«s pĂ«r sertifikatĂ« me ndihmĂ«n e çelĂ«save CA tĂ« klasterit Kubernetes, marrjen e sertifikatĂ«s sĂ« pĂ«rdoruesit (pĂ«r tĂ« marrĂ« sertifikatĂ«n, duhet tĂ« pĂ«rdoret njĂ« llogari qĂ« ka akses nĂ« çelĂ«sin e qendrĂ«s sĂ« sertifikimit tĂ« klasterit Kubernetes, i cili normalisht ndodhet nĂ« /etc/kubernetes/pki/ca.key):
    openssl x509 -req -in ~/mynewuser/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser/.certs/mynewuser.crt -days 500
  • krijimin e skedarit tĂ« konfigurimit:
    • pĂ«rshkrimi i klasterit (specifikoni adresĂ«n dhe vendndodhjen e skedarit tĂ« sertifikatĂ«s CA tĂ« instalimit tĂ« veçantĂ« tĂ« klasterit):
      kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443
    • ose — si nukopsioni i rekomanduar — nuk Ă«shtĂ« e nevojshme tĂ« specifikohet certifikata e rrĂ«njĂ«s (nĂ« kĂ«tĂ« rast kubectl nuk do tĂ« verifikojĂ« saktĂ«sinĂ« e api-server tĂ« klasterit):
      kubectl config set-cluster kubernetes --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443
    • shtimi i pĂ«rdoruesit nĂ« skedarin e konfigurimit:
      kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt --client-key=.certs/mynewuser.key
    • shtimi i kontekstit:
      kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser
    • caktimi i kontekstit si default:
      kubectl config use-context mynewuser-context

Pas manipulimeve të mësipërme, në skedarin .kube/config do të krijohet një konfigurim i tillë:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

Për lehtësimin e transferimit të konfiguracionit mes përdoruesve dhe serverëve është e dobishme të redaktohen vlerat e çelçave të mëposhtme:

  • certificate-authority
  • client-certificate
  • client-key

Për këtë mund të kodoni skedaret e specifikuara me base64 dhe t'i shkruani ato në konfigurim, duke shtuar në emrin e çelçave sufixin -data, dmth, duke marrë certificate-authority-data etj.

Certifikatat me kubeadm

Me lëshimin Kubernetes 1.15 punimi me certifikatat është bërë shumë më i lehtë falë mbështetjes në version alpha të tij në utilitarin kubeadm. Për shembull, ja se si mund të duket tani gjenerimi i skedarit të konfigurimit me çelësat e përdoruesit:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: E kërkuar adresa e reklamimit mund të shihet në konfigurimin e api-serverit, i cili ndodhet për default në /etc/kubernetes/manifests/kube-apiserver.yaml.

Konfiguimi rezultat do të dërgohet në stdout. Ai duhet të ruhet në ~/.kube/config llogarinë e përdoruesit ose në një skedar të caktuar në variablin e mjedisit KUBECONFIG.

Hidhuni më thellë

Për ata që dëshirojnë të kuptojnë më thellë çështjet e përshkruara:

Autorizimi

Llogaria e autorizuar për default nuk ka të drejta për veprime në klaster. Për të ofruar leje në Kubernetes, është implementuar një mekanizëm autorizimi.

Derisa në versionin 1.6 në Kubernetes përdorej një tip autorizimi, i njohur si ABAC (Kontrolli i qasjes mbi atributet). Detajet rreth tij mund të gjenden në dokumenti zyrtar. Aktualisht ky qasje konsiderohet i vjetruar (legacy), megjithatë ju mund ta përdorni atë njëkohësisht me lloje të tjera autorizimi.

Metoda më aktuale (dhe më fleksibël) për ndarjen e të drejtave të qasjes në një klaster quhet RBAC (Kontrolli i qasjes mbi bazën e rolit). Ai u shpall stabil nga versioni Kubernetes 1.8. RBAC implementon një model të të drejtave, ku gjithçka është e ndaluar përveç asaj që është shprehimisht e lejuar.
Për të aktivizuar RBAC, është e nevojshme të niset api-server Kubernetes me parametrin --authorization-mode=RBAC. Parametrat vendosen në manifenstimin me konfigurimin e api-server, i cili për default gjendet në rrugën /etc/kubernetes/manifests/kube-apiserver.yaml, në seksionin command. Megjithatë, për default, RBAC është tashmë e aktivizuar, prandaj ndoshta nuk ka nevojë për t'u shqetësuar për këtë: mund ta verifikoni këtë me vlerën authorization-mode (në atë që u përmend më parë kube-apiserver.yaml). Për më tepër, mes vlerave të tij mund të jenë edhe lloje të tjera autorizimi (node, webhook, always allow), por shqyrtimi i tyre do ta lërë jashtë kufijve të materialit.

Për më tepër, ne tashmë kemi publikuar artikullin me një tregim mjaft të detajuar rreth parimeve dhe veçorive të punës me RBAC, prandaj do të kufizohem me një përmbledhje të shkurtër të të parave dhe shembujve.

Për menaxhimin e qasjes në Kubernetes përmes RBAC përdoren entitete të tjera API:

  • Rol dhe ClusterRole — rollet qĂ« shĂ«rbejnĂ« pĂ«r tĂ« pĂ«rshkruar tĂ« drejtat e qasjes:
  • Rol lejon pĂ«rshkrimin e tĂ« drejtave brenda njĂ« hapĂ«sire emri;
  • ClusterRole — brenda klasterit, pĂ«rfshirĂ« objektet specifikĂ« pĂ«r klasterin siç janĂ« nyjet, non-resources urls (pra, ato qĂ« nuk lidhen me burimet Kubernetes — pĂ«r shembull, /version, /logs, /api*);
  • RoleBinding dhe ClusterRoleBinding — shĂ«rben pĂ«r lidhjen Rol dhe ClusterRole me njĂ« pĂ«rdorues, njĂ« grup pĂ«rdoruesish ose ServiceAccount.

Entitetet Role dhe RoleBinding janë të kufizuara në hapësirën emrit, domethënë, ato duhet të jenë brenda një hapësire emri. Megjithatë, RoleBinding mund të referojë një ClusterRole, gjë që lejon krijimin e një grupi standard të lejesh dhe menaxhimin e qasjes me ndihmën e tyre.

Rollet përshkruajnë të drejtat përmes grupeve të rregullave që përmbajnë:

  • grupet API — shih dokumentacionin zyrtar pĂ«r apiGroups dhe daljet;
  • burimet (resources: pod, namespace, deployment etj.);
  • veprime (verbs: set, update etj.).
  • emrat e burimeve (resourceNames) — pĂ«r rastin kur duhet tĂ« jepni qasje nĂ« njĂ« burim tĂ« caktuar, jo nĂ« tĂ« gjitha burimet e kĂ«tij tipi.

NjĂ« analizĂ« mĂ« tĂ« detajuar tĂ« autorizimit nĂ« Kubernetes mund tĂ« gjendet nĂ« faqen dokumenti zyrtar. NĂ« vend tĂ« kĂ«saj (ose mĂ« saktĂ«sisht — nĂ« shtesĂ« tĂ« saj) do tĂ« jap disa shembuj qĂ« ilustrojnĂ« funksionimin e saj.

Shembuj të entiteteve RBAC

E thjeshtë Rol, që lejon marrjen e listës dhe statusit të pod-ve dhe ndjekjen e tyre në hapësirën emërtuese hapësira-target:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: hapësira-target
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Shembuj ClusterRole, që lejon marrjen e listës dhe statusit të pod-ve dhe ndjekjen e tyre në të gjithë klasterin:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # seksioni "namespace" nuk është aty, pasi ClusterRole përfshin të gjithë klasterin
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Shembuj RoleBinding, që i lejon përdoruesit mynewuser të "lexojë" pod-të në hapësirën emërtuese hapësira-ime:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: hapësira-target
subjects:
- kind: User
  name: mynewuser # emri i përdoruesit është i ndjeshëm ndaj rastit!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # kĂ«tu duhet tĂ« jetĂ« “Role” ose “ClusterRole”
  name: pod-reader # emri i Role që gjendet në të njëjtën hapësirë,
                   # ose emri i ClusterRole që duam
                   # të autorizojmë për përdoruesin
  apiGroup: rbac.authorization.k8s.io

Auditimi i ngjarjeve

Arqitektura e Kubernetes-it mund të paraqitet në mënyrë schematike si më poshtë:

ABC e sigurisë në Kubernetes: autentikimi, autorizimi, auditimi

Komponenti kryesor i Kubernetes, i pĂ«rgjegjshĂ«m pĂ«r pĂ«rpunimin e kĂ«rkesave, Ă«shtĂ« api-server. TĂ« gjitha operacionet mbi klasterin kalojnĂ« pĂ«rmes tij. MĂ« shumĂ« rreth kĂ«tyre mekanizmave tĂ« brendshĂ«m mund tĂ« lexoni nĂ« artikullin "ÇfarĂ« ndodh nĂ« Kubernetes kur ekzekutohet kubectl run?».

Auditi i sistemit është një karakteristikë interesante në Kubernetes, e cila me default është e çaktivizuar. Ajo lejon regjistrimin e të gjitha kërkesave në API-në e Kubernetes. Siç mund të mendoni, përmes këtij API kryhen të gjitha veprimet e lidhura me kontrollin dhe ndryshimin e gjendjes së klasterit. Një përshkrim i mirë i mundësive të saj mund të gjendet (si zakonisht) në dokumenti zyrtar K8s. Më poshtë do përpiqem ta shpjegoj temën në një gjuhë më të thjeshtë.

Pra, për të aktivizuar auditin, na nevojitet t'i kalojmë kontenierit në api-server tre parametra të detyrueshëm, për të cilat është folur më poshtë:

  • --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
  • --audit-log-path=/var/log/kube-audit/audit.log
  • --audit-log-format=json

Përveç këtyre tre parametrave të nevojshëm, ekzistojnë shumë cilësime shtesë që lidhen me auditin: nga rotacioni i logeve deri te përshkrimet e webhook. Një shembull i parametrave të rotacionit të logeve:

  • --audit-log-maxbackup=10
  • --audit-log-maxsize=100
  • --audit-log-maxage=7

Por nuk do të ndalemi më gjatë mbi to - të gjitha detajet mund të gjenden në dokumentacioni për kube-apiserver.

Siç u përmend më parë, të gjitha parametrat vendosen në manifestin e konfiguracionit të api-server (me të drejtë /etc/kubernetes/manifests/kube-apiserver.yaml), në seksionin command. Le të kthehemi te 3 parametrat e detyrueshme dhe t'i shqyrtojmë ata:

  1. audit-policy-file — rruga deri te skedari YAML me pĂ«rshkrimin e politikĂ«s (policy) sĂ« auditimit. Ne do tĂ« kthehemi nĂ« pĂ«rmbajtjen e tij, derisa tĂ« theksojmĂ« se skedari duhet tĂ« jetĂ« i aksesueshĂ«m pĂ«r procesin api-server. Prandaj, Ă«shtĂ« e nevojshme ta vendosim atĂ« brenda kontejnerit, pĂ«r tĂ« cilin mund tĂ« shtoni kodin e mĂ«poshtĂ«m nĂ« seksionet pĂ«rkatĂ«se tĂ« konfigurimit:
      volumeMounts:
    - mountPath: /etc/kubernetes/policies
      name: policies
      readOnly: true
  volumes:
  - hostPath:
      path: /etc/kubernetes/policies
      type: DirectoryOrCreate
    name: policies
  2. audit-log-path — rruga deri te skedari i logut. Rruga gjithashtu duhet tĂ« jetĂ« e aksesueshme pĂ«r procesin e api-server, prandaj nĂ« mĂ«nyrĂ« tĂ« ngjashme pĂ«rshkruajmĂ« montimin e saj:
      volumeMounts:
    - mountPath: /var/log/kube-audit
      name: logs
      readOnly: false
  volumes:
  - hostPath:
      path: /var/log/kube-audit
      type: DirectoryOrCreate
    name: logs
  3. audit-log-format — formati i logut tĂ« auditimit. PĂ«r default, kjo Ă«shtĂ« json, por Ă«shtĂ« e disponueshme edhe forma e tekstit tĂ« vjetruar (legacy).

Politika e auditimit

Tani për skedarin e përmendur me përshkrimin e politikës së logimit. Koncepti i parë të politikës së auditimit është level, niveli i logimit. Ato janë si më poshtë:

  • AsnjĂ« — mos logimi;
  • Metadata — logimi i metadatenave tĂ« kĂ«rkesĂ«s: pĂ«rdoruesi, koha e kĂ«rkesĂ«s, burimi qĂ«llimor (pod, namespace etj.), lloji i veprimit (verb) etj.;
  • KĂ«rkesa — logimi i metadatenave dhe trupit tĂ« kĂ«rkesĂ«s;
  • KĂ«rkesaPĂ«rgjigja — logimi i metadatenave, trupit tĂ« kĂ«rkesĂ«s dhe trupit tĂ« pĂ«rgjigjes.

Dy nivelet e fundit (Kërkesa dhe KërkesaPërgjigja) nuk logojnë kërkesat që nuk janë drejtuar burimeve (këto përbëjnë kërkesa ndaj URL-esh që nuk janë burime).

Gjithashtu, të gjitha kërkesat kalojnë përmes disa fazash:

  • KĂ«rkesaEPranuar — faza kur kĂ«rkesa Ă«shtĂ« marrĂ« nga trajtuesi dhe ende nuk Ă«shtĂ« dĂ«rguar mĂ« tej nĂ« zinxhirin e trajtuesve;
  • PĂ«rgjigjaEFilluar — titujt e pĂ«rgjigjes janĂ« dĂ«rguar, por para dĂ«rgimit tĂ« trupit tĂ« pĂ«rgjigjes. Generohet pĂ«r kĂ«rkesa tĂ« gjata (p.sh., watch);
  • PĂ«rgjigjaPĂ«rfunduar — trupi i pĂ«rgjigjes Ă«shtĂ« dĂ«rguar, nuk do tĂ« dĂ«rgohet mĂ« shumĂ« informacion;
  • Panic — ngjarje qĂ« gjenerohen kur zbulohet njĂ« situatĂ« e jashtĂ«zakonshme.

Për të anashkaluar ndonjë fazë, mund të përdoret omitStages.

Në skedarin e politikës mund të përshkruajmë disa seksione me nivele të ndryshme logimi. Rregulli i parë i përshtatshëm do të aplikohet, që do të gjendet në përshkrimin e politikës.

Demon kubelet monitoron ndryshimin e manifestit me konfigurimin e api-server dhe, kur e vëren këtë, rinis kontejnerin me api-server. Por ka një detaj të rëndësishëm: ndryshimet në skedarin policy do të injorohen prej tij. Pas ndryshimeve në skedarin policy, do të jetë e nevojshme të rinisni manualisht api-serverin. Duke qenë se api-serveri ekzekutohet si pod static, komandën kubectl delete nuk do të shkaktojë rinisjen e tij. Duhet manualisht të bëni docker stop në kube-master-at, ku është ndryshuar politika e auditi:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Kur është aktivizuar auditi, është e rëndësishme të mbani mend se ngarkohet më shumë kube-apiserveri. Në veçanti, rritet konsumimi i memories për ruajtjen e konteksteve të kërkesave. Shkalla e regjistrimit fillon vetëm pas dërgimit të titullit të përgjigjes. Gjithashtu, ngarkesa varet nga konfigurimi i politikës së auditi.

Shembuj politikash

Le të shqyrtojmë strukturën e skedarëve të policy me shembuj.

Ja një skedar i thjeshtë policy, për të regjistruar gjithçka në nivelin Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Në policy mund të specifikoni një listë përdoruesish (Përdoruesit dhe Llogaritë e Shërbimit) dhe grupe përdoruesish. Për shembull, kështu do të injorojmë përdoruesit sistemikë, por do të regjistrojmë gjithçka tjetër në nivelin Kërkesa:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Ka gjithashtu ka mundësinë për të përshkruar destinacionet:

  • hapĂ«sirat e emrave (namespaces);
  • veprime (verbs: merr, update, fshi dhe tĂ« tjera);
  • burimet (resources, tĂ« quajtura: pod, configmaps etj.) dhe grupe burimesh (apiGroups).

Vini re! Burimet dhe grupet e burimeve (grupet API, dmth. apiGroups), si dhe versionet e tyre, të instaluara në klaster, mund të merren përmes komandave:

kubectl api-resources
kubectl api-versions

Politika e auditimit të mëposhtme është paraqitur si një demonstrim i praktikave më të mira në dokumentacionin e Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Mos logimi i fazës RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Mos logimi i ngjarjeve që konsiderohen të parëndësishme dhe jo të rrezikshme:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # kjo është grupi i api me emër të zbrazët, i cili i përket
                  # burimeve bazĂ« tĂ« Kubernetes, tĂ« njohura si “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Mos logimi i kërkesave për URLs vetëm për lexim:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Mos logimi i mesazheve qĂ« i pĂ«rkasin llojit tĂ« burimeve “ngjarje”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Burimet si Secret, ConfigMap dhe TokenReview mund të përmbajnë të dhëna sekrete,
  # prandaj logojmë vetëm metadatën e kërkesave lidhur me to
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Veprat si get, list dhe watch mund të jenë burim-konsumues; mos i logojmë ato
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Niveli i logimit nga default për burimet standarde të API
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Niveli i logimit nga default për të gjitha kërkesat e tjera
  - level: Metadata

Një shembull tjetër i mirë i audit policy është profili i përdorur në GCE.

Për të reaguar shpejt ndaj ngjarjeve të auditit, ka mundësi të përshkruani webhook. Ky çështje është trajtuar në dokumenti zyrtar, do ta lë jashtë këtij artikulli.

PĂ«rfundimet

Artikulli ofron njĂ« pĂ«rmbledhje tĂ« mekanizmave bazĂ« pĂ«r sigurinĂ« nĂ« klasteret Kubernetes, qĂ« lejojnĂ« krijimin e llogarive tĂ« personalizuara pĂ«r pĂ«rdoruesit, ndarjen e tĂ« drejtave tĂ« tyre, si dhe regjistrimin e veprimeve tĂ« tyre. Shpresoj se do t’ju ndihmojĂ« atyre qĂ« janĂ« ballafaquar me kĂ«to çështje nĂ« teori ose tashmĂ« nĂ« praktikĂ«. Po ashtu rekomandoj qĂ« tĂ« shqyrtoni listĂ«n e materialeve tĂ« tjera mbi sigurinĂ« nĂ« Kubernetes, e cila Ă«shtĂ« e paraqitur nĂ« 'P.S.', ndoshta midis tyre do tĂ« gjeni detajet e nevojshme pĂ«r problemet qĂ« ju interesojnĂ«.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster