ABC ya Usalama katika Kubernetes: Uthibitishaji, Uidhinishaji, Ukaguzi

Hivi karibuni au baadaye, katika uendeshaji wa mfumo wowote, suala la usalama linatokea: kuhakikisha uthibitishaji, mgawanyo wa haki, ukaguzi na kazi nyingine. Tayari imeundwa kwa ajili ya Kubernetes suluhisho nyingi, ambayo inakuwezesha kufikia kufuata viwango hata katika mazingira yanayohitaji sana ... Nyenzo sawa zinajitolea kwa vipengele vya msingi vya usalama vinavyotekelezwa ndani ya taratibu za kujengwa za K8s. Kwanza kabisa, itakuwa muhimu kwa wale ambao wanaanza kufahamiana na Kubernetes - kama sehemu ya kuanzia ya kusoma maswala yanayohusiana na usalama.

Uthibitishaji

Kuna aina mbili za watumiaji katika Kubernetes:

• Hesabu za Huduma - akaunti zinazosimamiwa na Kubernetes API;
• watumiaji — Watumiaji "wa kawaida" wanaosimamiwa na huduma za nje, zinazojitegemea.

Tofauti kuu kati ya aina hizi ni kwamba kwa Akaunti za Huduma kuna vitu maalum kwenye Kubernetes API (zinaitwa hivyo - ServiceAccounts), ambazo zimefungwa kwenye nafasi ya majina na seti ya data ya uidhinishaji iliyohifadhiwa kwenye nguzo katika vitu vya aina ya Siri. Watumiaji kama hao (Akaunti za Huduma) kimsingi wanakusudiwa kudhibiti haki za ufikiaji kwa API ya Kubernetes ya michakato inayoendeshwa katika nguzo ya Kubernetes.

Watumiaji wa Kawaida hawana maingizo katika Kubernetes API: lazima yadhibitiwe na mifumo ya nje. Zinakusudiwa watu au michakato inayoishi nje ya nguzo.

Kila ombi la API linahusishwa na Akaunti ya Huduma, Mtumiaji, au linachukuliwa kuwa lisilojulikana.

Data ya uthibitishaji wa mtumiaji inajumuisha:

• username - jina la mtumiaji (kesi nyeti!);
• UID - mfuatano wa utambulisho wa mtumiaji unaoweza kusomeka kwa mashine ambayo "ni thabiti zaidi na ya kipekee kuliko jina la mtumiaji";
• Vikundi - orodha ya vikundi ambavyo mtumiaji ni wa;
• ziada - nyanja za ziada ambazo zinaweza kutumiwa na utaratibu wa idhini.

Kubernetes inaweza kutumia idadi kubwa ya mbinu za uthibitishaji: Vyeti vya X509, Tokeni za Bearer, proksi ya uthibitishaji, Hati ya Msingi ya HTTP. Kwa kutumia taratibu hizi, unaweza kutekeleza idadi kubwa ya mipango ya uidhinishaji: kutoka kwa faili tuli na nywila hadi OpenID OAuth2.

Aidha, inawezekana kutumia mipango kadhaa ya idhini wakati huo huo. Kwa msingi, nguzo hutumia:

• ishara za akaunti ya huduma - kwa Akaunti za Huduma;
• X509 - kwa Watumiaji.

Swali kuhusu kusimamia Akaunti za Huduma ni zaidi ya upeo wa makala hii, lakini kwa wale ambao wanataka kujijulisha na suala hili kwa undani zaidi, napendekeza kuanza na kurasa rasmi za nyaraka. Tutaangalia kwa undani suala la jinsi vyeti vya X509 hufanya kazi.

Vyeti kwa watumiaji (X.509)

Njia ya classic ya kufanya kazi na cheti ni pamoja na:

• kizazi muhimu:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• kutoa ombi la cheti:

  openssl req -new -key ~/.certs/mynewuser.key -out ~/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• kuchakata ombi la cheti kwa kutumia funguo za CA za nguzo ya Kubernetes, kupata cheti cha mtumiaji (ili kupata cheti, lazima utumie akaunti ambayo ina ufikiaji wa ufunguo wa CA wa nguzo ya Kubernetes, ambayo kwa chaguomsingi iko /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/.certs/mynewuser.crt -days 500

• kuunda faili ya usanidi:
  • maelezo ya nguzo (taja anwani na eneo la faili ya cheti cha CA kwa usakinishaji maalum wa nguzo):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • au vipi hakunachaguo lililopendekezwa - sio lazima ubainishe cheti cha mizizi (basi kubectl haitaangalia usahihi wa seva ya api ya nguzo):

    kubectl config set-cluster kubernetes  --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • kuongeza mtumiaji kwenye faili ya usanidi:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt  --client-key=.certs/mynewuser.key

  • kuongeza muktadha:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • mgawo wa muktadha chaguo-msingi:

    kubectl config use-context mynewuser-context

Baada ya kudanganywa hapo juu, kwenye faili .kube/config usanidi kama huu utaundwa:

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

Ili iwe rahisi kuhamisha usanidi kati ya akaunti na seva, ni muhimu kuhariri maadili ya funguo zifuatazo:

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

Ili kufanya hivyo, unaweza kusimba faili zilizoainishwa ndani yao kwa kutumia base64 na kuzisajili kwenye usanidi, na kuongeza kiambishi kwa jina la funguo. -data, i.e. baada ya kupokea certificate-authority-data nk

Vyeti vyenye kubeadm

Pamoja na kutolewa Kubernetes 1.15 kufanya kazi na vyeti imekuwa rahisi zaidi kutokana na toleo la alpha la usaidizi wake katika matumizi ya kubeadm. Kwa mfano, hivi ndivyo kutengeneza faili ya usanidi na funguo za mtumiaji sasa kunaweza kuonekana kama:

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

NB: Inahitajika tangaza anwani inaweza kupatikana kwenye usanidi wa seva ya api, ambayo kwa chaguo-msingi iko ndani /etc/kubernetes/manifests/kube-apiserver.yaml.

Usanidi unaosababishwa utatolewa kwa stdout. Inahitaji kuhifadhiwa ndani ~/.kube/config akaunti ya mtumiaji au faili iliyoainishwa katika utofauti wa mazingira KUBECONFIG.

Chimba Zaidi

Kwa wale ambao wanataka kuelewa masuala yaliyoelezwa kwa undani zaidi:

• makala tofauti juu ya kufanya kazi na vyeti katika nyaraka rasmi za Kubernetes;
• makala nzuri kutoka Bitnami, ambapo suala la vyeti linaguswa kutoka kwa mtazamo wa vitendo.
• nyaraka za jumla juu ya uthibitishaji katika Kubernetes.

Authorization

Akaunti chaguo-msingi iliyoidhinishwa haina haki za kufanya kazi kwenye kundi. Ili kutoa ruhusa, Kubernetes hutumia utaratibu wa uidhinishaji.

Kabla ya toleo la 1.6, Kubernetes alitumia aina ya idhini inayoitwa ABAC (Udhibiti wa ufikiaji unaotegemea sifa). Maelezo juu yake yanaweza kupatikana katika nyaraka rasmi. Mbinu hii kwa sasa inachukuliwa kuwa ya urithi, lakini bado unaweza kuitumia pamoja na aina zingine za uthibitishaji.

Njia ya sasa (na inayonyumbulika zaidi) ya kugawanya haki za ufikiaji kwa nguzo inaitwa RBAC (Udhibiti wa ufikiaji wa jukumu) Imetangazwa kuwa thabiti tangu toleo Kubernetes 1.8. RBAC inatekeleza modeli ya haki ambapo kila kitu ambacho hakiruhusiwi waziwazi ni marufuku.
Ili kuwezesha RBAC, unahitaji kuanza Kubernetes api-server na kigezo --authorization-mode=RBAC. Vigezo vimewekwa kwenye faili ya maelezo na usanidi wa seva ya api, ambayo kwa chaguo-msingi iko kando ya njia. /etc/kubernetes/manifests/kube-apiserver.yaml, katika sehemu command. Walakini, RBAC tayari imewezeshwa kwa chaguo-msingi, kwa hivyo kuna uwezekano mkubwa kwamba usiwe na wasiwasi nayo: unaweza kuthibitisha hili kwa thamani. authorization-mode (katika yaliyotajwa tayari kube-apiserver.yaml) Kwa njia, kati ya maana zake kunaweza kuwa na aina zingine za idhini (node, webhook, always allow), lakini tutaacha kuzingatia kwao nje ya upeo wa nyenzo.

Kwa njia, tayari tumechapisha nakala na maelezo ya kina ya kanuni na huduma za kufanya kazi na RBAC, kwa hivyo zaidi nitajiwekea orodha fupi ya misingi na mifano.

Huluki zifuatazo za API zinatumika kudhibiti ufikiaji katika Kubernetes kupitia RBAC:

• Role и ClusterRole - majukumu ambayo yanatumika kuelezea haki za ufikiaji:
• Role hukuruhusu kuelezea haki ndani ya nafasi ya majina;
• ClusterRole - ndani ya nguzo, ikijumuisha vitu mahususi kwa nguzo kama vile nodi, url zisizo za rasilimali (yaani, zisizohusiana na rasilimali za Kubernetes - kwa mfano, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - kutumika kwa kufunga Role и ClusterRole kwa mtumiaji, kikundi cha watumiaji au Akaunti ya Huduma.

Vyombo vya Jukumu na Ufungaji Wajibu vimedhibitiwa na nafasi ya majina, i.e. lazima iwe ndani ya nafasi sawa ya majina. Walakini, RoleBinding inaweza kurejelea ClusterRole, ambayo hukuruhusu kuunda seti ya ruhusa za jumla na kudhibiti ufikiaji ukitumia.

Wajibu huelezea haki kwa kutumia seti za sheria zilizo na:

• Vikundi vya API - tazama nyaraka rasmi na apiGroups na pato kubectl api-resources;
• rasilimali (rasilimali: pod, namespace, deployment Nakadhalika.);
• Vitenzi (vitenzi: set, update Nakadhalika.).
• majina ya rasilimali (resourceNames) - kwa kesi wakati unahitaji kutoa upatikanaji wa rasilimali maalum, na si kwa rasilimali zote za aina hii.

Uchambuzi wa kina zaidi wa idhini katika Kubernetes unaweza kupatikana kwenye ukurasa nyaraka rasmi. Badala yake (au tuseme, kwa kuongeza hii), nitatoa mifano inayoonyesha kazi yake.

Mifano ya vyombo vya RBAC

Rahisi Role, ambayo inakuwezesha kupata orodha na hali ya maganda na kufuatilia katika nafasi ya majina 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"]

Mfano ClusterRole, ambayo hukuruhusu kupata orodha na hali ya maganda na kuyafuatilia katika nguzo nzima:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # секции "namespace" нет, так как ClusterRole задействует весь кластер
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Mfano RoleBinding, ambayo inaruhusu mtumiaji mynewuser "soma" maganda katika nafasi ya majina my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # имя пользователя зависимо от регистра!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # здесь должно быть “Role” или “ClusterRole”
  name: pod-reader # имя Role, что находится в том же namespace,
                   # или имя ClusterRole, использование которой
                   # хотим разрешить пользователю
  apiGroup: rbac.authorization.k8s.io

Ukaguzi wa tukio

Kwa utaratibu, usanifu wa Kubernetes unaweza kuwakilishwa kama ifuatavyo:

Sehemu muhimu ya Kubernetes inayohusika na usindikaji wa maombi ni api-server. Shughuli zote kwenye nguzo hupitia humo. Unaweza kusoma zaidi juu ya mifumo hii ya ndani katika kifungu "Nini kinatokea katika Kubernetes unapoendesha kubectl run?'.

Ukaguzi wa mfumo ni kipengele cha kuvutia katika Kubernetes, ambacho kimezimwa kwa chaguo-msingi. Inakuruhusu kuweka simu zote kwenye API ya Kubernetes. Kama unavyoweza kukisia, vitendo vyote vinavyohusiana na ufuatiliaji na kubadilisha hali ya nguzo hufanywa kupitia API hii. Maelezo mazuri ya uwezo wake yanaweza (kama kawaida) kupatikana ndani nyaraka rasmi K8s. Ifuatayo, nitajaribu kuwasilisha mada kwa lugha rahisi zaidi.

Hivyo, ili kuwezesha ukaguzi, tunahitaji kupitisha vigezo vitatu vinavyohitajika kwenye kontena kwenye seva ya api, ambayo imeelezwa kwa undani zaidi hapa chini:

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

Mbali na vigezo hivi vitatu muhimu, kuna mipangilio mingi ya ziada inayohusiana na ukaguzi: kutoka kwa mzunguko wa logi hadi maelezo ya webhook. Mfano wa vigezo vya mzunguko wa logi:

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

Lakini hatutakaa juu yao kwa undani zaidi - unaweza kupata maelezo yote ndani kube-apiserver nyaraka.

Kama ilivyotajwa tayari, vigezo vyote vimewekwa kwenye faili ya maelezo na usanidi wa seva ya api (kwa chaguo-msingi /etc/kubernetes/manifests/kube-apiserver.yaml), katika sehemu command. Wacha turudi kwa vigezo 3 vinavyohitajika na tuvichambue:

1. audit-policy-file - njia ya faili ya YAML inayoelezea sera ya ukaguzi. Tutarudi kwa yaliyomo baadaye, lakini kwa sasa nitagundua kuwa faili lazima isomwe na mchakato wa seva ya api. Kwa hivyo, inahitajika kuiweka ndani ya chombo, ambacho unaweza kuongeza nambari ifuatayo kwa sehemu zinazofaa za usanidi:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path - njia ya faili ya logi. Njia lazima pia ifikiwe kwa mchakato wa seva ya api, kwa hivyo tunaelezea uwekaji wake kwa njia ile ile:

     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 - muundo wa kumbukumbu ya ukaguzi. Chaguo msingi ni json, lakini umbizo la maandishi ya urithi pia linapatikana (legacy).

Sera ya Ukaguzi

Sasa kuhusu faili iliyotajwa inayoelezea sera ya ukataji miti. Dhana ya kwanza ya sera ya ukaguzi ni level, kiwango cha ukataji miti. Wao ni kama ifuatavyo:

• None - usiingie;
• Metadata - metadata ya ombi la logi: mtumiaji, wakati wa ombi, rasilimali inayolengwa (ganda, nafasi ya majina, n.k.), aina ya kitendo (kitenzi), n.k.;
• Request - logi metadata na mwili wa ombi;
• RequestResponse - logi metadata, mwili wa ombi na mwili wa majibu.

Viwango viwili vya mwisho (Request и RequestResponse) usiweke maombi ambayo hayakuweza kufikia rasilimali (ufikiaji wa URL zinazoitwa zisizo za rasilimali).

Pia, maombi yote hupitia hatua kadhaa:

• RequestReceived - hatua wakati ombi linapokelewa na processor na bado haijapitishwa zaidi kwenye mlolongo wa wasindikaji;
• ResponseStarted - vichwa vya majibu vinatumwa, lakini kabla ya mwili wa majibu kutumwa. Imetolewa kwa maswali ya muda mrefu (kwa mfano, watch);
• ResponseComplete - Mwili wa majibu umetumwa, hakuna habari zaidi itatumwa;
• Panic - matukio huzalishwa wakati hali isiyo ya kawaida inagunduliwa.

Ili kuruka hatua zozote unazoweza kutumia omitStages.

Katika faili ya sera, tunaweza kuelezea sehemu kadhaa zilizo na viwango tofauti vya ukataji miti. Sheria ya kwanza ya kulinganisha inayopatikana katika maelezo ya sera itatumika.

Kichunguzi cha kubelet daemon kinabadilika katika faili ya maelezo na usanidi wa seva ya api na, ikiwa yoyote itatambuliwa, huwasha upya kontena kwa seva ya api. Lakini kuna maelezo muhimu: mabadiliko katika faili ya sera yatapuuzwa nayo. Baada ya kufanya mabadiliko kwenye faili ya sera, utahitaji kuanzisha upya seva ya api wewe mwenyewe. Kwa kuwa seva ya api imeanzishwa kama ganda tuli, timu kubectl delete haitasababisha ianze tena. Itabidi uifanye kwa mikono docker stop kuhusu kube-masters, ambapo sera ya ukaguzi imebadilishwa:

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

Wakati wa kuwezesha ukaguzi, ni muhimu kukumbuka hilo mzigo kwenye kube-apiserver huongezeka. Hasa, utumiaji wa kumbukumbu kwa kuhifadhi muktadha wa ombi huongezeka. Kuweka kumbukumbu huanza tu baada ya kichwa cha majibu kutumwa. Mzigo pia unategemea usanidi wa sera ya ukaguzi.

Mifano ya sera

Hebu tuangalie muundo wa faili za sera kwa kutumia mifano.

Hapa kuna faili rahisi policykuweka kila kitu kwa kiwango Metadata:

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

Katika sera unaweza kubainisha orodha ya watumiaji (Users и ServiceAccounts) na vikundi vya watumiaji. Kwa mfano, hivi ndivyo tutakavyopuuza watumiaji wa mfumo, lakini weka kila kitu kingine kwenye kiwango 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

Inawezekana pia kuelezea malengo:

• nafasi za majina (namespaces);
• Vitenzi (vitenzi: get, update, delete na wengine);
• rasilimali (rasilimali, yaani: pod, configmaps nk) na vikundi vya rasilimali (apiGroups).

Makini! Rasilimali na vikundi vya rasilimali (vikundi vya API, i.e. apiGroups), pamoja na matoleo yao yaliyowekwa kwenye nguzo, yanaweza kupatikana kwa kutumia amri:

kubectl api-resources
kubectl api-versions

Sera ifuatayo ya ukaguzi imetolewa kama onyesho la mbinu bora katika Nyaraka za Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Не логировать стадию RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Не логировать события, считающиеся малозначительными и не опасными:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # это api group с пустым именем, к которому относятся
                  # базовые ресурсы Kubernetes, называемые “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"]
  # Не логировать обращения к read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Не логировать сообщения, относящиеся к типу ресурсов “события”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Ресурсы типа Secret, ConfigMap и TokenReview могут содержать  секретные данные,
  # поэтому логируем только метаданные связанных с ними запросов
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Действия типа get, list и watch могут быть ресурсоёмкими; не логируем их
  - 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"
  # Уровень логирования по умолчанию для стандартных ресурсов 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"
  # Уровень логирования по умолчанию для всех остальных запросов
  - level: Metadata

Mfano mwingine mzuri wa sera ya ukaguzi ni wasifu unaotumika katika GCE.

Ili kujibu haraka matukio ya ukaguzi, inawezekana kuelezea webhook. Suala hili linashughulikiwa ndani nyaraka rasmi, nitaiacha nje ya upeo wa makala haya.

Matokeo ya

Makala hutoa muhtasari wa mbinu za kimsingi za usalama katika makundi ya Kubernetes, ambayo hukuruhusu kuunda akaunti za mtumiaji zilizobinafsishwa, kutenganisha haki zao, na kurekodi vitendo vyao. Natumai itakuwa muhimu kwa wale ambao wanakabiliwa na maswala kama haya kwa nadharia au kwa vitendo. Ninapendekeza pia usome orodha ya vifaa vingine juu ya mada ya usalama huko Kubernetes, ambayo imetolewa katika "PS" - labda kati yao utapata maelezo muhimu juu ya shida ambazo zinafaa kwako.

PS

Soma pia kwenye blogi yetu:

• «33+ Kubernetes zana za usalama";
• «Utangulizi wa Sera za Mtandao wa Kubernetes kwa Wataalamu wa Usalama";
• «Kuelewa RBAC huko Kubernetes";
• «Mbinu 9 Bora za Usalama wa Kubernetes";
• «Njia 11 za (Si) Kuwa Mwathirika wa Udukuzi wa Kubernetes'.

Chanzo: mapenzi.com