Kubernetesen Segurtasunaren ABC: autentifikazioa, baimena, auditoria

Goiz edo beranduago, edozein sistemaren funtzionamenduan, segurtasunaren gaia sortzen da: autentifikazioa, eskubideen bereizketa, auditoria eta bestelako zereginak bermatzea. Dagoeneko Kubernetesentzat sortua irtenbide asko, estandarrak betetzea ahalbidetzen duten ingurune oso zorrotzetan ere... Material bera eskaintzen da K8-en mekanismo integratuen barruan inplementatutako segurtasunaren oinarrizko alderdiei. Lehenik eta behin, baliagarria izango da Kubernetes-ekin ezagutzen hasi direnentzat, segurtasunarekin lotutako gaiak aztertzeko abiapuntu gisa.

autentifikazio

Kubernetesen bi erabiltzaile mota daude:

• Zerbitzu-kontuak — Kubernetes APIak kudeatutako kontuak;
• erabiltzaileak — kanpoko zerbitzu independenteek kudeatutako erabiltzaile “normalak”.

Mota horien arteko desberdintasun nagusia da Zerbitzu-kontuetarako Kubernetes APIan objektu bereziak daudela (hori deitzen zaie - ServiceAccounts), Secrets motako objektuetan klusterrean gordetako izen-espazio bati eta baimen-datu multzo bati lotuta daudenak. Erabiltzaile horiek (Zerbitzu-kontuak) Kubernetes klusterrean exekutatzen diren prozesuen Kubernetes APIrako sarbide-eskubideak kudeatzea dute helburu nagusiki.

Erabiltzaile arruntek ez dute sarrerarik Kubernetes APIan: kanpoko mekanismoen bidez kudeatu behar dira. Klusterretik kanpo bizi diren pertsonei edo prozesuei zuzenduta daude.

API eskaera bakoitza Zerbitzu-kontu batekin, Erabiltzaile batekin edo anonimotzat hartzen da.

Erabiltzaileen autentifikazio-datuek honako hauek dira:

• Erabiltzaile izena — erabiltzaile-izena (maiuskulak eta minuskulak bereizten dira!);
• UID - Makinaz irakur daitekeen erabiltzailearen identifikazio-katea, "erabiltzaile-izena baino koherenteagoa eta esklusiboagoa" dena;
• Taldeak — erabiltzailea zein taldetan dagoen;
• aparteko — baimen-mekanismoak erabil ditzakeen eremu osagarriak.

Kubernetes-ek autentifikazio-mekanismo ugari erabil ditzake: X509 ziurtagiriak, Bearer tokenak, proxy autentifikatzailea, HTTP Basic Auth. Mekanismo hauek erabiliz, baimen-eskema ugari ezar ditzakezu: pasahitzak dituen fitxategi estatiko batetik OpenID OAuth2raino.

Gainera, aldi berean hainbat baimen-eskema erabil daitezke. Lehenespenez, klusterrak:

• service account tokens - Zerbitzu-kontuetarako;
• X509 - Erabiltzaileentzat.

Zerbitzu-kontuak kudeatzeari buruzko galdera artikulu honen esparrutik kanpo dago, baina gai hau xehetasun gehiagorekin ezagutu nahi dutenentzat, gomendatzen dut honekin hastea. dokumentazio ofizialeko orrialdeak. X509 ziurtagiriek nola funtzionatzen duten aztertzen joango gara.

Erabiltzaileentzako ziurtagiriak (X.509)

Ziurtagiriekin lan egiteko modu klasikoak honako hauek dira:

• gakoen sorkuntza:

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

• ziurtagiri eskaera sortzea:

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

• ziurtagiri eskaera prozesatzea Kubernetes klusterreko CA gakoak erabiliz, erabiltzailearen ziurtagiria lortzea (ziurtagiri bat lortzeko, Kubernetes klusterreko CA gakorako sarbidea duen kontu bat erabili behar duzu, lehenespenez kokatuta dagoena). /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

• konfigurazio fitxategi bat sortzea:
  • klusterraren deskribapena (zehaztu kluster instalazio zehatz baterako CA ziurtagiriaren fitxategiaren helbidea eta kokapena):

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

  • edo nola ezgomendatutako aukera - ez duzu erro-ziurtagiria zehaztu behar (orduan kubectl-ek ez du klusterren api-zerbitzariaren zuzentasuna egiaztatuko):

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

  • erabiltzaile bat konfigurazio fitxategira gehitzea:

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

  • testuingurua gehitzea:

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

  • testuinguru-esleipen lehenetsia:

    kubectl config use-context mynewuser-context

Goiko manipulazioen ondoren, fitxategian .kube/config honelako konfigurazio bat sortuko da:

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

Kontu eta zerbitzarien artean konfigurazioa transferitzea errazteko, komenigarria da gako hauen balioak editatzea:

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

Horretarako, base64 erabiliz zehaztutako fitxategiak kode ditzakezu eta konfigurazioan erregistratu, gakoen izenari atzizkia gehituz. -data, hau da. jasota certificate-authority-data eta abar.

Kubeadm-ekin ziurtagiriak

Askapenarekin Kubernetes 1.15 Ziurtagiriekin lan egitea askoz errazagoa bihurtu da bere euskarriaren alfa bertsioari esker kubeadm erabilgarritasuna. Adibidez, hauxe izan daiteke orain erabiltzailearen gakoekin konfigurazio fitxategi bat sortzea:

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

NB: Beharrezkoa iragarki helbidea api-zerbitzariaren konfigurazioan aurki daiteke, lehenespenez bertan kokatuta dagoena /etc/kubernetes/manifests/kube-apiserver.yaml.

Lortutako konfigurazioa stdout-era aterako da. Bertan gorde behar da ~/.kube/config erabiltzaile-kontura edo ingurune-aldagai batean zehaztutako fitxategi batera KUBECONFIG.

Sakonago sakondu

Azaldutako gaiak sakonago ulertu nahi dituztenentzat:

• artikulu bereizi Kubernetesen dokumentazio ofizialean ziurtagiriekin lan egiteari buruz;
• Bitnami-ren artikulu ona, zeinetan ziurtagirien gaia ikuspegi praktikotik ukitzen den.
• dokumentazio orokorra Kubernetes-en autentifikazioari buruz.

baimen

Baimendutako kontu lehenetsiak ez du klusterrean jarduteko eskubiderik. Baimenak emateko, Kubernetes-ek baimen-mekanismo bat ezartzen du.

1.6 bertsioaren aurretik, Kubernetes izeneko baimen mota bat erabiltzen zuen ABAC (Atributuetan oinarritutako sarbide-kontrola). Honi buruzko xehetasunak atalean aurki daitezke dokumentazio ofiziala. Gaur egun, ikuspegi hau ondaretzat hartzen da, baina beste autentifikazio motekin batera erabil dezakezu oraindik.

Kluster baterako sarbide-eskubideak banatzeko egungo moduari (eta malguagoa) deitzen zaio RBAC (Roletan oinarritutako sarbide kontrola). Bertsiotik egonkor deklaratu da Kubernetes 1.8. RBACek eskubide-eredu bat ezartzen du, non berariaz baimenduta ez dagoen guztia debekatuta dagoen.
RBAC gaitzeko, Kubernetes api-zerbitzaria parametroarekin hasi behar duzu --authorization-mode=RBAC. Parametroak api-zerbitzariaren konfigurazioarekin ezartzen dira manifestuan, zeina lehenespenez bidearen baitan kokatzen dena /etc/kubernetes/manifests/kube-apiserver.yaml, atalean command. Hala ere, RBAC lehenespenez gaituta dago, beraz, ziurrenik ez zarela horretaz kezkatu behar: balioaren arabera egiaztatu dezakezu. authorization-mode (lehen aipaturikoan kube-apiserver.yaml). Bide batez, bere esanahien artean beste baimen mota batzuk egon daitezke (node, webhook, always allow), baina haien gogoeta materialaren esparrutik kanpo utziko dugu.

Bide batez, dagoeneko argitaratu dugu artikulu bat RBAC-ekin lan egiteko printzipio eta ezaugarrien deskribapen nahiko zehatzarekin, beraz, aurrerago, oinarrien eta adibideen zerrenda labur batera mugatuko naiz.

API entitate hauek Kubernetesen sarbidea kontrolatzeko erabiltzen dira RBAC bidez:

• Role и ClusterRole — Sarbide-eskubideak deskribatzeko balio duten rolak:
• Role izen-espazio baten barruan eskubideak deskribatzeko aukera ematen du;
• ClusterRole - Kluster barruan, kluster-eko objektu espezifikoak barne, hala nola nodoak, baliabideak ez diren URLak (hau da, Kubernetes baliabideekin erlazionatuta ez daudenak - adibidez, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - Lotzeko erabiltzen da Role и ClusterRole erabiltzaile, erabiltzaile talde edo zerbitzu-kontu bati.

Role eta RoleBinding entitateak izen-espazioak mugatuta daude, hau da. izen-espazio berean egon behar du. Hala ere, RoleBinding batek ClusterRole erreferentzia egin dezake, eta horri esker, baimen generiko multzo bat sortzeko eta haiek erabiliz sarbidea kontrola dezakezu.

Rolek eskubideak deskribatzen dituzte honako hauek dituzten arau multzoak erabiliz:

• API taldeak - ikus dokumentazio ofiziala apiGroups eta irteeraren bidez kubectl api-resources;
• baliabideak (baliabideak: pod, namespace, deployment eta abar.);
• Aditzak (aditz: set, update eta antzekoak).
• baliabideen izenak (resourceNames) - baliabide zehatz baterako sarbidea eman behar duzun kasurako, eta ez mota honetako baliabide guztietarako.

Kubernetes-en baimenaren azterketa zehatzagoa orrialdean aurki daiteke dokumentazio ofiziala. Horren ordez (edo hobeto esanda, honetaz gain), bere lana ilustratzen duten adibideak jarriko ditut.

RBAC entitateen adibideak

erraz Role, leken zerrenda eta egoera lortzeko eta izen-eremuan kontrolatzeko aukera ematen duena 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"]

Adibidea ClusterRole, leken zerrenda eta egoera lortzeko eta kluster osoan zehar kontrolatzeko aukera ematen duena:

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

Adibidea RoleBinding, erabiltzaileari aukera ematen diona mynewuser "irakurri" lekak izen-eremuan 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

Gertaeren auditoria

Eskematikoki, Kubernetes arkitektura honela irudika daiteke:

Eskaerak prozesatzeko ardura Kubernetes osagai nagusia da api-zerbitzaria. Klusterreko eragiketa guztiak bertatik pasatzen dira. Barne mekanismo hauei buruz gehiago irakur dezakezu artikuluan "Zer gertatzen da Kubernetesen kubectl run exekutatzen duzunean?'.

Sistemaren auditoria Kubernetesen eginbide interesgarri bat da, lehenespenez desgaituta dagoena. Kubernetes APIan dei guztiak erregistratzeko aukera ematen du. Asma dezakezun bezala, klusterraren egoera kontrolatzearekin eta aldatzearekin lotutako ekintza guztiak API honen bidez egiten dira. Bere gaitasunen deskribapen on bat aurki daiteke (ohi bezala). dokumentazio ofiziala K8ak. Jarraian, gaia hizkuntza sinpleago batean aurkezten saiatuko naiz.

Horrela, auditoria gaitzeko, beharrezkoak diren hiru parametro pasatu behar ditugu api-zerbitzarian edukiontzira, behean zehatzago deskribatzen direnak:

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

Beharrezkoak diren hiru parametro horiez gain, ikuskaritzari lotutako ezarpen gehigarri asko daude: erregistroen biraketatik webhook deskribapenetara. Erregistroen biraketa-parametroen adibidea:

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

Baina ez gara zehatzago azalduko - xehetasun guztiak bertan aurki ditzakezu kube-apiserver dokumentazioa.

Esan bezala, parametro guztiak api-zerbitzariaren konfigurazioarekin ezartzen dira manifestuan (lehenespenez /etc/kubernetes/manifests/kube-apiserver.yaml), atalean command. Itzuli behar diren 3 parametroetara eta azter ditzagun:

1. audit-policy-file — auditoretza-politika deskribatzen duen YAML fitxategirako bidea. Beranduago itzuliko gara bere edukietara, baina oraingoz ohartuko naiz fitxategia api-zerbitzariaren prozesuak irakurri behar duela. Hori dela eta, beharrezkoa da edukiontziaren barruan muntatzea, eta horretarako honako kodea gehi dezakezu konfigurazioaren atal egokietan:

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

2. audit-log-path — erregistro-fitxategirako bidea. Bideak api-zerbitzariaren prozesurako ere eskuragarri egon behar du, beraz, bere muntaketa modu berean deskribatzen dugu:

     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 - auditoretza-erregistroaren formatua. Lehenetsia da json, baina testu-formatua ere eskuragarri dago (legacy).

Ikuskaritza-politika

Orain erregistro-politika deskribatzen duen aipatutako fitxategiari buruz. Ikuskaritza politikaren lehen kontzeptua da level, erregistro-maila. Honako hauek dira:

• None - ez erregistratu;
• Metadata — erregistro-eskaeraren metadatuak: erabiltzailea, eskaera-denbora, xede-baliabidea (pod, izen-espazioa, etab.), ekintza mota (aditza), etab.;
• Request — erregistro metadatuak eta eskaeraren gorputza;
• RequestResponse — Erregistro metadatuak, eskaeraren gorputza eta erantzunaren gorputza.

Azken bi mailak (Request и RequestResponse) ez ditu erregistratu baliabideetara sartu ez diren eskaerak (baliabide ez diren url deritzonetarako sarbideak).

Gainera, eskaera guztiak pasatzen dira hainbat etapa:

• RequestReceived — prozesadoreak eskaera jasotzen duen eta oraindik prozesadore-katean zehar gehiago transmititu ez den etapa;
• ResponseStarted — erantzunen goiburuak bidaltzen dira, baina erantzunaren gorputza bidali baino lehen. Iraupen luzeko kontsultetarako sortua (adibidez, watch);
• ResponseComplete — erantzun-organoa bidali da, ez da informazio gehiago bidaliko;
• Panic — egoera anormal bat detektatzen denean gertaerak sortzen dira.

Erabili ditzakezun urratsak saltatzeko omitStages.

Politika-fitxategi batean, hainbat atal deskriba ditzakegu erregistro-maila ezberdinekin. Gidalerroen deskribapenean aurkitutako lehen bat-etortze-araua aplikatuko da.

Kubelet deabruak api-zerbitzariaren konfigurazioarekin manifestuan izandako aldaketak kontrolatzen ditu eta, halakorik hautematen bada, edukiontzia api-zerbitzariarekin berrabiarazten du. Baina bada xehetasun garrantzitsu bat: politika-fitxategian egindako aldaketak ez ditu aintzat hartuko. Politika-fitxategian aldaketak egin ondoren, api-zerbitzaria eskuz berrabiarazi beharko duzu. api zerbitzari gisa abiarazi denez pod estatikoa, taldea kubectl delete ez du berrabiaraziko. Eskuz egin beharko duzu docker stop kube-masters-en, auditoretza-politika aldatu den:

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

Ikuskaritza gaitzean, garrantzitsua da hori gogoratzea kube-apiserver-en karga handitzen da. Bereziki, eskaeraren testuingurua gordetzeko memoria-kontsumoa handitzen da. Erantzunaren goiburua bidali ondoren bakarrik hasten da erregistroa. Karga ikuskaritza politikaren konfigurazioaren araberakoa da ere.

Politiken adibideak

Ikus dezagun politika-fitxategien egitura adibideak erabiliz.

Hona hemen fitxategi sinple bat policymailan dena erregistratzeko Metadata:

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

Politikan erabiltzaileen zerrenda bat zehaztu dezakezu (Users и ServiceAccounts) eta erabiltzaile taldeak. Esaterako, horrela sistemaren erabiltzaileei ez ikusi egingo diegu, baina mailan erregistratuko dugu gainerako guztia 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

Helburuak deskribatu ere egin daitezke:

• izen-guneak (namespaces);
• Aditzak (aditz: get, update, delete eta besteak);
• baliabideak (baliabideakBezala, honako hauek dira: pod, configmaps eta abar) eta baliabide taldeak (apiGroups).

Arreta! Baliabideak eta baliabide taldeak (API taldeak, hau da, apiGroups), baita klusterrean instalatutako bertsioak ere, komando hauek erabiliz lor daitezke:

kubectl api-resources
kubectl api-versions

Honako auditoretza-politika hau praktika onen erakusgarri gisa eskaintzen da Alibaba Cloud dokumentazioa:

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

Ikuskaritza politikaren beste adibide on bat da GCEn erabiltzen den profila.

Ikuskaritzako gertaerei azkar erantzutea, posible da deskribatu webhook. Gai hau jasota dago dokumentazio ofiziala, artikulu honen esparrutik kanpo utziko dut.

Emaitzak

Artikuluak Kubernetes klusterren oinarrizko segurtasun-mekanismoen ikuspegi orokorra eskaintzen du, erabiltzaile-kontu pertsonalizatuak sortzeko, eskubideak bereizteko eta ekintzak erregistratzeko aukera ematen dizutenak. Teorian edo praktikan horrelako gaiei aurre egiten dietenentzat baliagarria izatea espero dut. Era berean, Kubernetes-en segurtasun gaiari buruzko beste materialen zerrenda irakurtzea gomendatzen dizut, hau da, "PS"-n ematen dena - agian horien artean zuretzako garrantzitsuak diren arazoei buruzko beharrezko xehetasunak aurkituko dituzu.

PS

Irakurri ere gure blogean:

• «33+ Kubernetes segurtasun-tresna»;
• «Kubernetes sareko politiken sarrera Segurtasun profesionalentzako»;
• «RBAC ulertzea Kubernetes-en»;
• «Kubernetes segurtasunerako 9 praktika onak»;
• «11 modu (Ez) Kubernetes Hack baten biktima bihurtzeko'.

Iturria: www.habr.com