ProHoster > Blog > Administrim > ABC e sigurisë në Kubernetes: autentifikimi, autorizimi, auditimi

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

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

Në një moment ose tjetër, në funksionimin e çdo sistemi lind pyetja e sigurisë: sigurimi i autentifikimit, ndarja e të drejtave, auditimi dhe detyra të tjera. Për Kubernetes tashmë janë krijuar shumë zgjidhje, të cilat lejojnë arritjen e përputhjes me standardet edhe në mjedise mjaft kërkuese... Ky material i dedikohet aspekteve bazë të sigurisë, të realizuara në kuadër të mekanizmave të integruar të K8s. Në radhë të parë, ai do të jetë i dobishëm për ata që fillojnë të njohin Kubernetes, si një pikë fillestare për studimin e pyetjeve që lidhen me sigurinë.

Autentikimi

Në Kubernetes ka dy lloje përdoruesish:

  • LlogaritĂ« e ShĂ«rbimit — llogari tĂ« menaxhuara nga API i Kubernetes;
  • dhe e fshij pĂ«rdoruesin — pĂ«rdorues "normalĂ«", tĂ« menaxhuar nga shĂ«rbime tĂ« jashtme dhe tĂ« pavarura.

Dallimi kryesor midis këtyre llojeve është se për Llogaritë e Shërbimit ekzistojnë objekte të veçanta në API e Kubernetes (ato quhen edhe) LlogaritëEShërbimit), të cilat janë të lidhura me hapësirën e emrave dhe një grup të dhënash të autorizimit, 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ë API e Kubernetes për procese që funksionojnë në klasterin Kubernetes.

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

Çdo kĂ«rkesĂ« nĂ« API lidhet ose me LlogarinĂ« e ShĂ«rbimit, ose me PĂ«rdoruesin, ose konsiderohet anonime.

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

  • Username — emrin e pĂ«rdoruesit (varet nga rastit!);
  • UID — njĂ« string i lexueshĂ«m nga makina pĂ«r identifikimin e pĂ«rdoruesit, i cili "Ă«shtĂ« mĂ« konsistent dhe unik se emri i pĂ«rdoruesit";
  • Grupet — lista e grupeve ku i pĂ«rket pĂ«rdoruesi;
  • ShtesĂ« — fusha tĂ« tjera qĂ« mund tĂ« pĂ«rdoren nga mekanizmi i autorizimit.

Kubernetes mund të përdorë një numër të madh mekanizmash autentikimi: certifikatat X509, Bearer-tokens, proxy autentikues, HTTP Basic Auth. Me këto mekanizma mund të realizohen një sërë skemash autorizimi: nga një skedar statik me fjalëkalime deri në OpenID OAuth2.

Për më tepër, lejohet përdorimi i disa skemave autorizimi njëkohësisht. Nga ana tjetër, në klaster përdoren si të parakohshmet:

  • tokenet e llogarive tĂ« shĂ«rbimit — pĂ«r LlogaritĂ« e ShĂ«rbimit;
  • X509 — pĂ«r PĂ«rdoruesit.

Pyetja për menaxhimin e ServiceAccounts kalon përtej kësaj artikulli, dhe për ata që duan të njihen më thellë me këtë çështje, rekomandoj të filloni nga faqja e dokumentacionit zyrtar. Ne do të shqyrtojmë më thellë çështjen e funksionimit të certifikatave X509.

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

Mënyra e zakonshme e punës me certifikatat parashikon:

  • gjenerimin e çelĂ«sit:
    mkdir -p ~/mynewuser/.certs/
openssl genrsa -out ~/mynewuser.key 2048
  • gjenerimin e kĂ«rkesĂ«s pĂ«r certifikat:
    openssl req -new -key ~/mynewuser.key -out ~/mynewuser.csr -subj "/CN=mynewuser/O=company"
  • pĂ«rpunimin e kĂ«rkesĂ«s pĂ«r certifikat duke pĂ«rdorur çelĂ«sat e CA tĂ« klasterit Kubernetes, marrjen e certifikatĂ«s sĂ« pĂ«rdoruesit (pĂ«r tĂ« marrĂ« certifikatĂ«n duhet tĂ« pĂ«rdoret njĂ« llogari qĂ« ka akses nĂ« çelĂ«sin e qendrĂ«s sĂ« certifikimit tĂ« klasterit Kubernetes, i cili nĂ« mĂ«nyrĂ« tĂ« paracaktuar ndodhet nĂ« /etc/kubernetes/pki/ca.key):
    openssl x509 -req -in ~/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser.crt -days 500
  • krijimin e skedarit tĂ« konfigurimit:
    • pĂ«rshkrimi i klasterit (specifikoni adresĂ«n dhe vendndodhjen e skedarit tĂ« certifikatĂ«s CA pĂ«r instalimin specifik tĂ« klasterit):
      kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443
    • ose - si joopsioni i rekomanduar - nuk mund tĂ« specifikoni certifikatat rrĂ«njĂ«sore (atĂ«herĂ« kubectl nuk do tĂ« verifikojĂ« saktĂ«sinĂ« e api-serverit 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 parazgjedhje:
      kubectl config use-context mynewuser-context

Pas veprimeve 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 të lehtësuar kalimin e konfigurimit midis llogarive dhe serverëve, është e dobishme të redaktohen vlerat e çelësave të mëposhtëm:

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

PĂ«r kĂ«tĂ«, mund tĂ« kodoni skedarĂ«t e specifikuar me base64 dhe t'i shkruani nĂ« konfigurim, duke shtuar nĂ« emrat e çelĂ«save sufixin -data, dmth duke marrĂ« certificate-authority-data NĂ« mekanizmin e lidhjes sĂ« tabelave tĂ« jashtme Foreign Data Wrapper (postgres_fdw) Ă«shtĂ« realizuar mbĂ«shtetje pĂ«r autentikimin e bazuar nĂ« certifikata. Kur pĂ«rdoret autentikimi SCRAM, klientĂ«ve u lejohet tĂ« kĂ«rkojnĂ« ‘

Certifikatat me kubeadm

Me lëshimin Kubernetes 1.15 Puna me sertifikatat është bërë ndjeshëm më e lehtë falë versionit alfa të mbështetjes në utilitarin kubeadm. Për shembull, ja 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: Të kërkuara adresa e reklamimit mund të shikohet në konfigurimin e api-serverit, i cili ndodhet për default në /etc/kubernetes/manifests/kube-apiserver.yaml.

Konfigurationsi i rezultatit do të printohet në stdout. Ai duhet të ruhet në ~/.kube/config llogarinë e përdoruesit ose në skedarin që është treguar në variablin e ambientit KUBECONFIG.

Shkoni më në thellësi

Për ata që dëshirojnë të kuptojnë më mirë çështjet e përmendura:

Autorizimi

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

Derisa të versioni 1.6 në Kubernetes është përdorur një lloj autorizimi, i quajtur ABAC (Kontrolli i aksesit të bazuar në atributet). Detajet mbi të mund të gjenden në dokumentacionin zyrtar. Aktualisht, ky qasje konsiderohet e vjetruar (legacy), megjithatë ju ende mund ta përdorni atë në të njëjtën kohë me lloje të tjera autorizimi.

Qasja aktuale (dhe më e fleksibël) për ndarjen e të drejtave të aksesit në klaster quhet RBAC (Kontrolli i qasjes me rol). Ai u shpall i qëndrueshëm që nga versioni Kubernetes 1.8. RBAC zbatojnë një model të të drejtave, ku çdo gjë që nuk është lejuar është e ndaluar.
Për të aktivizuar RBAC, duhet të nisni Kubernetes api-server me parametrin --authorization-mode=RBAC. Parametrat vendosen në manifestin e konfigurimit të api-serverit, i cili për default ndodhet në /etc/kubernetes/manifests/kube-apiserver.yaml, në seksionin command. Megjithatë, RBAC për default është aktivizuar, prandaj ndoshta nuk është e nevojshme të shqetësoheni për këtë: mund ta verifikoni këtë në vlerën authorization-mode (në dokumentin e përmendur më parë kube-apiserver.yaml). Për ta thënë ndryshe, mes vlerave të tij mund të gjenden edhe lloje të tjera autorizimi (ndod, webhook, lejo gjithmonë), por trajtimi i tyre është jashtë përmbajtjes.

Të kujtoj, ne tashmë kemi publikuar artikull me një tregim mjaft të detajuar mbi parimet dhe karakteristikat e punës me RBAC, prandaj tani do të kufizohem në një listë të shkurtër të bazave dhe shembujve.

Për menaxhimin e aksesit në Kubernetes nëpërmjet RBAC përdoren këto entitete të API-së:

  • Rol dhe ClusterRole — role qĂ« shĂ«rbejnĂ« pĂ«r tĂ« pĂ«rshkruar tĂ« drejtat e aksesit:
  • Rol lejon tĂ« pĂ«rshkruajĂ« tĂ« drejtat brenda hapĂ«sirĂ«s sĂ« emrit;
  • ClusterRole — brenda grupit, pĂ«rfshirĂ« objektet specifike tĂ« grupit si nyjet, urls non-resources (pra, tĂ« pa lidhura me burimet Kubernetes — pĂ«r shembull, /version, /logs, /api*);
  • RoleBinding dhe ClusterRoleBinding — shĂ«rben pĂ«r lidhjen Rol dhe ClusterRole me pĂ«rdoruesin, grupin e pĂ«rdoruesve ose ServiceAccount.

Entitetet Role dhe RoleBinding janë të kufizuara nga hapësira e emrit, domethënë, ato duhet të jenë brenda një hapësire emri. Megjithatë, RoleBinding mund të referohet në ClusterRole, që lejon krijimin e një grupi të tipareve të autorizimit dhe menaxhimin e qasjes me ndihmën e tyre.

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

  • grupet API — shiko dokumentacionin zyrtar pĂ«r apiGroups dhe daljen kubectl api-resources;
  • burimet (resources: pod, namespace, deployment etj.);
  • veprimet (verbs: set, pĂ«rditĂ«sim etj.).
  • emrat e burimeve (resourceNames) — pĂ«r rastin kur duhet tĂ« jepni qasje nĂ« njĂ« burim tĂ« caktuar dhe jo nĂ« tĂ« gjitha burimet e kĂ«tij lloji.

NjĂ« analizĂ« mĂ« tĂ« thellĂ« tĂ« autorizimit nĂ« Kubernetes mund tĂ« gjendet nĂ« faqen dokumentacionin zyrtar. NĂ« vend tĂ« kĂ«tij (nĂ« tĂ« vĂ«rtetĂ« — si njĂ« shtesĂ«) do tĂ« jap shembuj qĂ« ilustrojnĂ« funksionimin e tij.

Shembuj të entiteteve RBAC

I thjeshtĂ« Rol, qĂ« lejon tĂ« merrni listĂ«n dhe statusin e pod’ëve dhe tĂ« ndiqni ata nĂ« hapĂ«sirĂ«n e emrit target-namespace:

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

Shembulli ClusterRole, qĂ« lejon marrjen e listĂ«s dhe statusit tĂ« pod’ëve dhe ndjekjen e atyre nĂ« tĂ« gjithĂ« grupin:

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

Shembulli RoleBinding, qĂ« lejon pĂ«rdoruesin mynewuser "tĂ« lexojĂ«" pod’ët nĂ« hapĂ«sirĂ«n e emrit my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # emri i përdoruesit është i ndjeshëm ndaj regjistrit!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # kĂ«tu duhet tĂ« jetĂ« “Role” ose “ClusterRole”
  name: pod-reader # emri i Role, që ndodhet në të njëjtin namespace,
                   # ose emri i ClusterRole, përdorimi i së cilës
                   # duam të lejojmë për përdoruesin
  apiGroup: rbac.authorization.k8s.io

Auditimi i ngjarjeve

Arkitektura e Kubernetes mund të paraqitet në mënyrë skematike si vijon:

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

Komponenti kyç i Kubernetes, pĂ«rgjegjĂ«s pĂ«r pĂ«rpunimin e kĂ«rkesave, — api-server. TĂ« gjitha operacionet mbi grupin kalojnĂ« pĂ«rmes tij. MĂ« shumĂ« rreth kĂ«tyre mekanizmave tĂ« brendshĂ«m mund tĂ« lexoni nĂ« artikullin "ÇfarĂ« ndodh nĂ« Kubernetes kur nisi kubectl run?».

Auditi i sistemit është një funksionalitet interesant në Kubernetes, i cili është i çaktivizuar si parazgjedhje. Ai lejon regjistrimin e të gjitha kërkesave për API-në e Kubernetes. Si lehtë mund të kuptohet, përmes këtij API po kryhen të gjitha veprimet që lidhen me kontrollin dhe ndryshimin e gjendjes së klasterit. Një përshkrim i mirë i mundësive të tij mund të gjendet (si zakonisht) në dokumentacionin zyrtar K8s. Më tej do të përpiqem ta shpjegoj temën në një gjuhë më të thjeshtë.

Pra, Për të aktivizuar auditin, na nevojitet të kalojmë tri parametra të detyrueshëm në container-in në api-server, për më shumë detaje mbi të cilët do të flasim 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ë domosdoshëm, ekzistojnë shumë cilësime të tjera në lidhje me auditimin: nga rotacioni i regjistrimeve deri te përshkrimet e webhook-ëve. Një shembull i parametrave të rotacionit të regjistrimeve:

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

Por nuk do tĂ« ngelemi mĂ« shumĂ« mbi ta — mund tĂ« gjeni tĂ« gjitha detajet nĂ« dokumentacionin pĂ«r kube-apiserver.

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

  1. audit-policy-file — rruga deri te skedari YAML me pĂ«rshkrimin e politikĂ«s sĂ« auditimit. PĂ«rmbajtjes sĂ« tij do t'i kthehemi, por pĂ«r momentin do tĂ« theksoj se skedari duhet tĂ« jetĂ« nĂ« dispozicion pĂ«r lexim nga procesi i api-server. Prandaj, Ă«shtĂ« e nevojshme ta montoni atĂ« brenda container-it, pĂ«r kĂ«tĂ« 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 regjistrimit. Rruga gjithashtu duhet tĂ« jetĂ« nĂ« dispozicion nga procesi i api-server, prandaj po ashtu e pĂ«rshkruajmĂ« montimin e tij:
      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 regjistrimit tĂ« auditimit. Si parazgjedhje, ky Ă«shtĂ« json., por Ă«shtĂ« i disponueshĂ«m edhe formati i vjetĂ«r tekstual (legacy).

Politika e auditimit

Tani për skedarin e përmendur me përshkrimin e politikës së regjistrimit. Koncepti i parë të cilin e quajmë audit policy është level, niveli i regjistrimit. Ato mund të jenë si më poshtë:

  • AsnjĂ« — mos regjistro;
  • Metadata — regjistro metadatat e kĂ«rkesĂ«s: pĂ«rdoruesi, koha e kĂ«rkesĂ«s, burimi i synuar (pod, namespace etj.), tipi i veprimit (verb) etj.;
  • Request — regjistro metadatat dhe trupin e kĂ«rkesĂ«s;
  • RequestResponse — regjistro metadatat, trupin e kĂ«rkesĂ«s dhe trupin e pĂ«rgjigjes.

Nivelet e fundit (Request dhe RequestResponse) nuk regjistrojnë kërkesa që nuk i qasen burimeve (që bëjnë referencë te URL-të e ashtuquajtura non-resources).

Gjithashtu, të gjithë kërkesat kalojnë përmes disa fazave:

  • RequestReceived — faza kur kĂ«rkesa Ă«shtĂ« pranuar nga procesori dhe ende nuk Ă«shtĂ« dĂ«rguar mĂ« tej nĂ« zinxhirin e procesorĂ«ve;
  • ResponseStarted — titujt e pĂ«rgjigjes janĂ« dĂ«rguar, por pĂ«rpara dĂ«rgimit tĂ« trupit tĂ« pĂ«rgjigjes. Gjenerohet pĂ«r kĂ«rkesa tĂ« gjata (p.sh., watch);
  • ResponseComplete — trupi i pĂ«rgjigjes Ă«shtĂ« dĂ«rguar, nuk do tĂ« dĂ«rgohen mĂ« informata;
  • Panic — ngjarjet gjenerohen kur zbulohet njĂ« situatĂ« e jashtĂ«zakonshme.

Për të kaluar ndonjë fazë, mund të përdorim omitStages.

Në skedarin e politikës mund të përshkruajmë disa seksione me nivele të ndryshme regjistrimi. Rregulli i parë i përshtatshëm, i gjetur në përshkrimin e politikës, do të zbatohet.

Demon kubelet ndjek ndryshimin e manifestit me konfigurimin e api-server dhe, kur e detecton, rindez kontejnerin me api-server. Por ka një detaj të rëndësishëm: ndryshimet në skedarin e politikës do të injorohen. Pas ndryshimeve në skedarin e politikës, kërkohet që të rindezësh manualisht api-serverin. Duke qenë se api-serveri është nisur si static pod, ekipi kubectl delete nuk do të çojë në rindezjen e tij. Do të duhet ta bësh manualisht docker stop në kube-master-at, ku është ndryshuar politika e auditi:

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

Kur aktivizohet auditi, është e rëndësishme të mbash mend se ngarkesa në kube-apiserver rritet. Në veçanti, rritet konsumimi i memories për ruajtjen e konteksteve të kërkesave. Regjistrimi në log fillon vetëm pas dërgimit të titujve të përgjigjes. Gjithashtu, ngarkesa varet nga konfigurimi i politikës së auditi.

Shembuj të politikave

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

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

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

Në politikë mund të specifikosh një listë përdoruesish (dhe e fshij përdoruesin dhe LlogaritëEShërbimit) dhe grupe përdoruesish. Për shembull, kështu ne do të injorojmë përdoruesit sistemikë, por do të regjistrojmë gjithçka tjetër në nivelin Request:

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 mundësinë për të përshkruar objektivat:

  • hapĂ«sirat emrash (namespaces);
  • veprimet (verbs: merr, pĂ«rditĂ«sim, fshij dhe tĂ« tjera);
  • burimet (resources, nĂ« veçanti: pod, configmaps etj.) dhe grupe resursesh (apiGroups).

Keni parasysh! Burimet dhe grupet e burimeve (grupet API, dmth. apiGroups), si dhe versionet e tyre të instaluara në klaster, mund të merren duke përdorur komandat:

kubectl api-resources
kubectl api-versions

Politika e auditimit në vazhdim jepet si një demonstruese e praktikave më të mira në dokumentacionin e Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Mos loguar fazën RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Mos loguar ngjarje që konsiderohen të parëndësishme dhe jo të rrezikshme:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # ky është grupi api me emër të zbrazët, i cili përfshin
                  # burimet themelore tĂ« Kubernetes, tĂ« quajtura “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 loguar qasjet në URL të lexueshme:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Mos loguar mesazhet 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 regjistrojmë vetëm metadatat e kërkesave të lidhura
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Veprimet si get, list dhe watch mund të jenë të ngarkuara me burime; mos i regjistro
  - 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 standard i regjistrimit për burimet e zakonshme 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 standard i regjistrimit për të gjitha kërkesat e tjera
  - level: Metadata

NjĂ« tjetĂ«r shembull i mirĂ« i politikĂ«s sĂ« auditimit — profili i pĂ«rdorur nĂ« GCE.

Për reagimin e shpejtë ndaj ngjarjeve të auditimit ekziston mundësia të përshkruash webhook. Ky çështje trajtohet në dokumentacionin zyrtar, do ta lë përtej këtij artikulli.

PĂ«rfundime

Artikulli ofron njĂ« pĂ«rmbledhje tĂ« mekanizmave tĂ« sigurisĂ« themelore nĂ« klasterĂ«t Kubernetes, tĂ« cilĂ«t lejojnĂ« krijimin e llogarive tĂ« personalizuara pĂ«r pĂ«rdoruesit, ndarjen e tĂ« drejtave tĂ« tyre dhe regjistrimin e veprimeve tĂ« tyre. Shpresoj se do t'u vie nĂ« ndihmĂ« atyre qĂ« pĂ«rballen me kĂ«to pyetje nĂ« teori ose tashmĂ« nĂ« praktikĂ«. Sugjeroj gjithashtu tĂ« shqyrtoni listĂ«n e materialeve tĂ« tjera mbi temĂ«n e sigurisĂ« nĂ« Kubernetes, qĂ« Ă«shtĂ« pĂ«rfshirĂ« nĂ« “P.S.” – ndoshta, ndĂ«r to do tĂ« gjeni detaje tĂ« nevojshme pĂ«r problemet tuaja aktuale.

P.S.

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

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