Ang ABC ng Seguridad sa Kubernetes: Authentication, Authorization, Auditing

Maaga o huli, sa pagpapatakbo ng anumang sistema, ang isyu ng seguridad ay lumitaw: pagtiyak ng pagpapatunay, paghihiwalay ng mga karapatan, pag-audit at iba pang mga gawain. Nagawa na para sa Kubernetes maraming solusyon, na nagbibigay-daan sa iyong makamit ang pagsunod sa mga pamantayan kahit na sa napakahirap na kapaligiran... Ang parehong materyal ay nakatuon sa mga pangunahing aspeto ng seguridad na ipinatupad sa loob ng mga built-in na mekanismo ng K8s. Una sa lahat, magiging kapaki-pakinabang ito sa mga nagsisimulang makilala ang Kubernetes - bilang panimulang punto para sa pag-aaral ng mga isyu na nauugnay sa seguridad.

Pagpapatunay

Mayroong dalawang uri ng mga user sa Kubernetes:

• Mga Account ng Serbisyo — mga account na pinamamahalaan ng Kubernetes API;
• Users — “normal” na mga user na pinamamahalaan ng mga panlabas, independiyenteng serbisyo.

Ang pangunahing pagkakaiba sa pagitan ng mga uri na ito ay para sa Mga Account ng Serbisyo mayroong mga espesyal na bagay sa Kubernetes API (tinatawag silang - ServiceAccounts), na nakatali sa isang namespace at isang set ng data ng pahintulot na naka-imbak sa cluster sa mga bagay na may uri ng Secrets. Ang mga naturang user (Service Accounts) ay pangunahing nilayon na pamahalaan ang mga karapatan sa pag-access sa Kubernetes API ng mga prosesong tumatakbo sa Kubernetes cluster.

Ang mga Ordinaryong User ay walang mga entry sa Kubernetes API: dapat silang pamahalaan ng mga panlabas na mekanismo. Ang mga ito ay inilaan para sa mga tao o mga prosesong naninirahan sa labas ng cluster.

Ang bawat kahilingan sa API ay nauugnay sa alinman sa isang Service Account, isang User, o itinuturing na anonymous.

Kasama sa data ng pagpapatunay ng user ang:

• username — username (case sensitive!);
• UID - isang string ng pagkakakilanlan ng user na nababasa ng makina na "mas pare-pareho at natatangi kaysa sa username";
• Grupo — listahan ng mga pangkat kung saan kabilang ang gumagamit;
• dagdag — karagdagang mga field na maaaring gamitin ng mekanismo ng awtorisasyon.

Maaaring gumamit ang mga Kubernetes ng malaking bilang ng mga mekanismo ng pagpapatotoo: mga X509 na certificate, Mga token ng maydala, proxy na nagpapatotoo, HTTP Basic Auth. Gamit ang mga mekanismong ito, maaari kang magpatupad ng malaking bilang ng mga scheme ng pahintulot: mula sa isang static na file na may mga password hanggang sa OpenID OAuth2.

Bukod dito, posibleng gumamit ng ilang mga scheme ng pahintulot nang sabay-sabay. Bilang default, ginagamit ng cluster ang:

• mga token ng account ng serbisyo - para sa Mga Account ng Serbisyo;
• X509 - para sa mga User.

Ang tanong tungkol sa pamamahala ng Mga ServiceAccount ay lampas sa saklaw ng artikulong ito, ngunit para sa mga gustong maging pamilyar sa isyung ito nang mas detalyado, inirerekomenda kong magsimula sa opisyal na mga pahina ng dokumentasyon. Susuriin namin ang isyu kung paano gumagana ang mga sertipiko ng X509.

Mga sertipiko para sa mga user (X.509)

Ang klasikong paraan ng pagtatrabaho sa mga sertipiko ay kinabibilangan ng:

• pangunahing henerasyon:

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

• pagbuo ng kahilingan sa sertipiko:

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

• pagpoproseso ng kahilingan sa certificate gamit ang Kubernetes cluster CA key, pagkuha ng user certificate (upang makakuha ng certificate, dapat kang gumamit ng account na may access sa Kubernetes cluster CA key, na bilang default ay matatagpuan sa /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

• paggawa ng configuration file:
  • paglalarawan ng cluster (tukuyin ang address at lokasyon ng CA certificate file para sa isang partikular na pag-install ng cluster):

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

  • o paano hindiinirerekomendang opsyon - hindi mo kailangang tukuyin ang root certificate (pagkatapos ay hindi susuriin ng kubectl ang kawastuhan ng api-server ng cluster):

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

  • pagdaragdag ng user sa configuration file:

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

  • pagdaragdag ng konteksto:

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

  • default na pagtatalaga ng konteksto:

    kubectl config use-context mynewuser-context

Pagkatapos ng mga manipulasyon sa itaas, sa file .kube/config isang config tulad nito ay malilikha:

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

Upang gawing mas madali ang paglipat ng config sa pagitan ng mga account at server, kapaki-pakinabang na i-edit ang mga halaga ng mga sumusunod na key:

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

Upang gawin ito, maaari mong i-encode ang mga file na tinukoy sa kanila gamit ang base64 at irehistro ang mga ito sa config, pagdaragdag ng suffix sa pangalan ng mga key. -data, ibig sabihin. pagkatanggap certificate-authority-data at iba pa

Mga sertipiko na may kubeadm

Sa paglabas Kubernetes 1.15 ang pagtatrabaho sa mga sertipiko ay naging mas madali salamat sa alpha na bersyon ng suporta nito sa kubeadm utility. Halimbawa, ito ang maaaring hitsura ngayon ng pagbuo ng configuration file na may mga key ng user:

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

NB: Kailangan advertise address ay matatagpuan sa api-server config, na bilang default ay matatagpuan sa /etc/kubernetes/manifests/kube-apiserver.yaml.

Ang resultang config ay magiging output sa stdout. Kailangan itong i-save sa ~/.kube/config user account o sa isang file na tinukoy sa isang environment variable KUBECONFIG.

Maghukay ng Palalim

Para sa mga gustong maunawaan ang mga isyung inilarawan nang mas lubusan:

• hiwalay na artikulo sa pagtatrabaho sa mga sertipiko sa opisyal na dokumentasyon ng Kubernetes;
• magandang artikulo mula sa Bitnami, kung saan ang isyu ng mga sertipiko ay tinatalakay mula sa praktikal na pananaw.
• pangkalahatang dokumentasyon sa pagpapatunay sa Kubernetes.

Awtorisasyon

Ang default na awtorisadong account ay walang mga karapatan na gumana sa cluster. Para magbigay ng mga pahintulot, nagpapatupad ang Kubernetes ng mekanismo ng awtorisasyon.

Bago ang bersyon 1.6, gumamit ang Kubernetes ng uri ng awtorisasyon na tinatawag ABAC (Attribute-based na access control). Ang mga detalye tungkol dito ay matatagpuan sa opisyal na dokumentasyon. Ang diskarte na ito ay kasalukuyang itinuturing na legacy, ngunit maaari mo pa rin itong gamitin kasama ng iba pang mga uri ng pagpapatotoo.

Ang kasalukuyang (at mas nababaluktot) na paraan ng paghahati ng mga karapatan sa pag-access sa isang cluster ay tinatawag RBAC (Kontrol sa pag-access na batay sa papel). Ito ay idineklara na stable mula noong bersyon Kubernetes 1.8. Ang RBAC ay nagpapatupad ng isang modelo ng mga karapatan kung saan ang lahat ng bagay na hindi tahasang pinahihintulutan ay ipinagbabawal.
Upang paganahin ang RBAC, kailangan mong simulan ang Kubernetes api-server gamit ang parameter --authorization-mode=RBAC. Ang mga parameter ay nakatakda sa manifest na may configuration ng api-server, na bilang default ay matatagpuan sa kahabaan ng path /etc/kubernetes/manifests/kube-apiserver.yaml, sa seksyon command. Gayunpaman, ang RBAC ay pinagana na bilang default, kaya malamang na hindi ka dapat mag-alala tungkol dito: maaari mong i-verify ito sa pamamagitan ng halaga authorization-mode (sa nabanggit na kube-apiserver.yaml). Sa pamamagitan ng paraan, kabilang sa mga kahulugan nito ay maaaring may iba pang mga uri ng awtorisasyon (node, webhook, always allow), ngunit iiwan namin ang kanilang pagsasaalang-alang sa labas ng saklaw ng materyal.

By the way, na-publish na namin isang artikulo na may medyo detalyadong paglalarawan ng mga prinsipyo at tampok ng pagtatrabaho sa RBAC, kaya lilimitahan ko pa ang aking sarili sa isang maikling listahan ng mga pangunahing kaalaman at halimbawa.

Ang mga sumusunod na entity ng API ay ginagamit upang kontrolin ang pag-access sa Kubernetes sa pamamagitan ng RBAC:

• Role и ClusterRole — mga tungkuling nagsisilbing paglalarawan ng mga karapatan sa pag-access:
• Role nagbibigay-daan sa iyong ilarawan ang mga karapatan sa loob ng isang namespace;
• ClusterRole - sa loob ng cluster, kabilang ang mga object na partikular sa cluster gaya ng mga node, mga url na hindi mapagkukunan (ibig sabihin, hindi nauugnay sa mga mapagkukunan ng Kubernetes - halimbawa, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - ginagamit para sa pagbubuklod Role и ClusterRole sa isang user, pangkat ng user o ServiceAccount.

Ang Role at RoleBinding entity ay limitado ng namespace, i.e. dapat nasa loob ng parehong namespace. Gayunpaman, ang isang RoleBinding ay maaaring sumangguni sa isang ClusterRole, na nagbibigay-daan sa iyong lumikha ng isang hanay ng mga generic na pahintulot at kontrolin ang pag-access gamit ang mga ito.

Inilalarawan ng mga tungkulin ang mga karapatan gamit ang mga hanay ng mga panuntunang naglalaman ng:

• Mga pangkat ng API - tingnan opisyal na dokumentasyon sa pamamagitan ng apiGroups at output kubectl api-resources;
• mapagkukunan (mga mapagkukunan: pod, namespace, deployment at iba pa.);
• Pandiwa (verbs: set, update atbp.)
• mga pangalan ng mapagkukunan (resourceNames) - para sa kaso kung kailan kailangan mong magbigay ng access sa isang partikular na mapagkukunan, at hindi sa lahat ng mga mapagkukunan ng ganitong uri.

Ang isang mas detalyadong pagsusuri ng awtorisasyon sa Kubernetes ay matatagpuan sa pahina opisyal na dokumentasyon. Sa halip (o sa halip, bilang karagdagan dito), magbibigay ako ng mga halimbawa na naglalarawan sa kanyang trabaho.

Mga halimbawa ng RBAC entity

Simple Role, na nagbibigay-daan sa iyong makakuha ng listahan at katayuan ng mga pod at subaybayan ang mga ito sa namespace 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"]

Halimbawa ClusterRole, na nagbibigay-daan sa iyong makakuha ng listahan at status ng mga pod at subaybayan ang mga ito sa buong cluster:

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

Halimbawa RoleBinding, na nagpapahintulot sa gumagamit mynewuser "basahin" ang mga pod sa namespace 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

Pag-audit ng kaganapan

Sa eskematiko, ang arkitektura ng Kubernetes ay maaaring katawanin bilang mga sumusunod:

Ang pangunahing bahagi ng Kubernetes na responsable para sa pagproseso ng mga kahilingan ay api-server. Ang lahat ng mga operasyon sa cluster ay dumadaan dito. Maaari kang magbasa nang higit pa tungkol sa mga panloob na mekanismong ito sa artikulong "Ano ang mangyayari sa Kubernetes kapag nagpatakbo ka ng kubectl run?'.

Ang pag-audit ng system ay isang kawili-wiling feature sa Kubernetes, na hindi pinagana bilang default. Pinapayagan ka nitong i-log ang lahat ng mga tawag sa Kubernetes API. Tulad ng maaari mong hulaan, ang lahat ng mga aksyon na nauugnay sa pagsubaybay at pagbabago ng estado ng cluster ay ginagawa sa pamamagitan ng API na ito. Ang isang magandang paglalarawan ng mga kakayahan nito ay makikita (gaya ng dati) sa opisyal na dokumentasyon K8s. Susunod, susubukan kong ipakita ang paksa sa mas simpleng wika.

Kaya, upang paganahin ang pag-audit, kailangan naming ipasa ang tatlong kinakailangang parameter sa lalagyan sa api-server, na inilalarawan nang mas detalyado sa ibaba:

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

Bilang karagdagan sa tatlong kinakailangang parameter na ito, maraming karagdagang setting na nauugnay sa pag-audit: mula sa pag-ikot ng log hanggang sa mga paglalarawan ng webhook. Halimbawa ng mga parameter ng pag-ikot ng log:

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

Ngunit hindi namin tatalakayin ang mga ito nang mas detalyado - mahahanap mo ang lahat ng mga detalye sa dokumentasyon ng kube-apiserver.

Tulad ng nabanggit na, ang lahat ng mga parameter ay nakatakda sa manifest na may pagsasaayos ng api-server (bilang default /etc/kubernetes/manifests/kube-apiserver.yaml), sa seksyon command. Bumalik tayo sa 3 kinakailangang parameter at suriin ang mga ito:

1. audit-policy-file — path sa YAML file na naglalarawan sa patakaran sa pag-audit. Babalik tayo sa mga nilalaman nito mamaya, ngunit sa ngayon ay mapapansin ko na ang file ay dapat na mabasa ng proseso ng api-server. Samakatuwid, kinakailangang i-mount ito sa loob ng lalagyan, kung saan maaari mong idagdag ang sumusunod na code sa naaangkop na mga seksyon ng config:

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

2. audit-log-path — landas sa log file. Ang landas ay dapat ding ma-access sa proseso ng api-server, kaya inilalarawan namin ang pag-mount nito sa parehong paraan:

     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 — format ng audit log. Ang default ay json, ngunit ang legacy na format ng teksto ay magagamit din (legacy).

Patakaran sa Pag-audit

Ngayon tungkol sa nabanggit na file na naglalarawan sa patakaran sa pag-log. Ang unang konsepto ng patakaran sa pag-audit ay level, antas ng pag-log. Ang mga ito ay ang mga sumusunod:

• None - huwag mag-log;
• Metadata — metadata ng kahilingan sa log: user, oras ng kahilingan, target na mapagkukunan (pod, namespace, atbp.), uri ng pagkilos (pandiwa), atbp.;
• Request — mag-log metadata at katawan ng kahilingan;
• RequestResponse — log metadata, request body at response body.

Ang huling dalawang antas (Request и RequestResponse) huwag mag-log ng mga kahilingan na hindi nag-access ng mga mapagkukunan (mga pag-access sa tinatawag na mga hindi mapagkukunang url).

Lahat din ng kahilingan ay dumadaan ilang yugto:

• RequestReceived — ang yugto kung kailan natanggap ng processor ang kahilingan at hindi pa naipapadala sa kahabaan ng chain ng mga processor;
• ResponseStarted — ang mga header ng tugon ay ipinadala, ngunit bago ipadala ang katawan ng tugon. Binuo para sa mga query na matagal nang tumatakbo (halimbawa, watch);
• ResponseComplete — naipadala na ang response body, wala nang ipapadalang impormasyon;
• Panic — Nabubuo ang mga kaganapan kapag may nakitang abnormal na sitwasyon.

Upang laktawan ang anumang mga hakbang na magagamit mo omitStages.

Sa isang file ng patakaran, maaari naming ilarawan ang ilang mga seksyon na may iba't ibang antas ng pag-log. Ilalapat ang unang tumutugmang panuntunan na makikita sa paglalarawan ng patakaran.

Sinusubaybayan ng kubelet daemon ang mga pagbabago sa manifest gamit ang configuration ng api-server at, kung may matukoy man, i-restart ang container gamit ang api-server. Ngunit mayroong isang mahalagang detalye: hindi nito papansinin ang mga pagbabago sa file ng patakaran. Pagkatapos gumawa ng mga pagbabago sa file ng patakaran, kakailanganin mong i-restart nang manu-mano ang api-server. Dahil sinimulan ang api-server bilang static na pod, pangkat kubectl delete hindi ito magiging sanhi upang mag-restart. Kailangan mong gawin ito nang manu-mano docker stop sa kube-masters, kung saan binago ang patakaran sa pag-audit:

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

Kapag pinapagana ang pag-audit, mahalagang tandaan iyon tumataas ang load sa kube-apiserver. Sa partikular, ang pagkonsumo ng memorya para sa pag-imbak ng konteksto ng kahilingan ay tumataas. Magsisimula lamang ang pag-log pagkatapos maipadala ang header ng tugon. Ang pagkarga ay depende rin sa pagsasaayos ng patakaran sa pag-audit.

Mga halimbawa ng mga patakaran

Tingnan natin ang istruktura ng mga file ng patakaran gamit ang mga halimbawa.

Narito ang isang simpleng file policyupang mai-log ang lahat sa antas Metadata:

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

Sa patakaran maaari kang tumukoy ng listahan ng mga user (Users и ServiceAccounts) at mga pangkat ng gumagamit. Halimbawa, ito ay kung paano namin babalewalain ang mga gumagamit ng system, ngunit i-log ang lahat ng iba pa sa antas 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

Posible ring ilarawan ang mga target:

• mga namespace (namespaces);
• Pandiwa (verbs: get, update, delete at iba pa);
• mapagkukunan (mga mapagkukunan, lalo: pod, configmaps atbp.) at mga pangkat ng mapagkukunan (apiGroups).

Magbayad pansin! Mga resource at resource group (API group, i.e. apiGroups), pati na rin ang kanilang mga bersyon na naka-install sa cluster, ay maaaring makuha gamit ang mga command:

kubectl api-resources
kubectl api-versions

Ang sumusunod na patakaran sa pag-audit ay ibinigay bilang isang pagpapakita ng pinakamahuhusay na kagawian sa Dokumentasyon ng 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

Ang isa pang magandang halimbawa ng patakaran sa pag-audit ay profile na ginamit sa GCE.

Upang mabilis na tumugon sa mga kaganapan sa pag-audit, posible ilarawan ang webhook. Ang isyung ito ay sakop sa opisyal na dokumentasyon, iiwan ko ito sa labas ng saklaw ng artikulong ito.

Mga resulta ng

Nagbibigay ang artikulo ng pangkalahatang-ideya ng mga pangunahing mekanismo ng seguridad sa mga kumpol ng Kubernetes, na nagbibigay-daan sa iyong gumawa ng mga personalized na user account, paghiwalayin ang kanilang mga karapatan, at itala ang kanilang mga aksyon. Umaasa ako na ito ay magiging kapaki-pakinabang sa mga nahaharap sa mga ganitong isyu sa teorya o sa pagsasanay. Inirerekomenda ko rin na basahin mo ang listahan ng iba pang mga materyales sa paksa ng seguridad sa Kubernetes, na ibinigay sa "PS" - marahil kasama ng mga ito ay makikita mo ang mga kinakailangang detalye sa mga problema na nauugnay sa iyo.

PS

Basahin din sa aming blog:

• «33+ tool sa seguridad ng Kubernetes";
• «Isang Panimula sa Mga Patakaran sa Network ng Kubernetes para sa Mga Propesyonal sa Seguridad";
• «Pag-unawa sa RBAC sa Kubernetes";
• «9 Pinakamahuhusay na Kasanayan para sa Kubernetes Security";
• «11 Paraan para (Hindi) Maging Biktima ng Kubernetes Hack'.

Pinagmulan: www.habr.com