L-ABC tas-Sigurtà f'Kubernetes: Awtentikazzjoni, Awtorizzazzjoni, Verifika

Illum jew għada, fit-tħaddim ta 'kwalunkwe sistema, tqum il-kwistjoni tas-sigurtà: l-iżgurar ta' awtentikazzjoni, separazzjoni tad-drittijiet, verifika u kompiti oħra. Diġà maħluqa għal Kubernetes ħafna soluzzjonijiet, li jippermettulek tikseb konformità mal-istandards anke f'ambjenti eżiġenti ħafna... L-istess materjal huwa ddedikat għall-aspetti bażiċi tas-sigurtà implimentati fi ħdan il-mekkaniżmi integrati tal-K8s. L-ewwelnett, se jkun utli għal dawk li qed jibdew jiffamiljarizzaw ruħhom ma 'Kubernetes - bħala punt tat-tluq għall-istudju ta' kwistjonijiet relatati mas-sigurtà.

Awtentikazzjoni

Hemm żewġ tipi ta’ utenti f’Kubernetes:

• Kontijiet tas-Servizz — kontijiet ġestiti mill-API Kubernetes;
• Utenti — utenti “normali” ġestiti minn servizzi esterni indipendenti.

Id-differenza ewlenija bejn dawn it-tipi hija li għall-Kontijiet tas-Servizz hemm oġġetti speċjali fl-API Kubernetes (jismu hekk - ServiceAccounts), li huma marbuta ma’ namespace u sett ta’ dejta ta’ awtorizzazzjoni maħżuna fir-raggruppament f’oġġetti tat-tip Sigrieti. Utenti bħal dawn (Kontijiet tas-Servizz) huma primarjament maħsuba biex jimmaniġġjaw id-drittijiet ta' aċċess għall-API Kubernetes tal-proċessi li jaħdmu fil-cluster Kubernetes.

Utenti Ordinarji m'għandhomx entrati fl-API Kubernetes: iridu jiġu ġestiti minn mekkaniżmi esterni. Huma maħsuba għal nies jew proċessi li jgħixu barra mill-cluster.

Kull talba API hija assoċjata jew ma' Kont ta' Servizz, Utent, jew titqies bħala anonima.

Id-dejta tal-awtentikazzjoni tal-utent tinkludi:

• Username — isem tal-utent (sensittiv għall-każi!);
• UID - sekwenza ta' identifikazzjoni tal-utent li tinqara mill-magni li hija "aktar konsistenti u unika mill-isem tal-utent";
• gruppi — lista ta' gruppi li l-utent jappartjeni għalihom;
• extra — oqsma addizzjonali li jistgħu jintużaw mill-mekkaniżmu ta' awtorizzazzjoni.

Kubernetes jista 'juża numru kbir ta' mekkaniżmi ta 'awtentikazzjoni: ċertifikati X509, tokens Bearer, prokura ta' awtentikazzjoni, HTTP Basic Auth. Billi tuża dawn il-mekkaniżmi, tista 'timplimenta numru kbir ta' skemi ta 'awtorizzazzjoni: minn fajl statiku b'passwords għal OpenID OAuth2.

Barra minn hekk, huwa possibbli li jintużaw diversi skemi ta' awtorizzazzjoni simultanjament. B'mod awtomatiku, il-cluster juża:

• tokens tal-kontijiet tas-servizz - għall-Kontijiet tas-Servizz;
• X509 - għall-Utenti.

Il-mistoqsija dwar il-ġestjoni ta' ServiceAccounts hija lil hinn mill-ambitu ta' dan l-artikolu, iżda għal dawk li jixtiequ jiffamiljarizzaw ruħhom ma' din il-kwistjoni f'aktar dettall, nirrakkomanda li tibda b' paġni tad-dokumentazzjoni uffiċjali. Se nagħtu ħarsa aktar mill-qrib lejn il-kwistjoni ta 'kif jaħdmu ċ-ċertifikati X509.

Ċertifikati għall-utenti (X.509)

Il-mod klassiku ta' kif taħdem maċ-ċertifikati jinvolvi:

• ġenerazzjoni taċ-ċavetta:

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

• tiġġenera talba għal ċertifikat:

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

• l-ipproċessar ta’ talba għal ċertifikat bl-użu taċ-ċwievet tas-CA tal-cluster Kubernetes, il-kisba ta’ ċertifikat tal-utent (biex tikseb ċertifikat, trid tuża kont li għandu aċċess għaċ-ċwievet CA tal-cluster Kubernetes, li b’mod awtomatiku jinsab f’ /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

• ħolqien ta' fajl ta' konfigurazzjoni:
  • deskrizzjoni tal-cluster (speċifika l-indirizz u l-post tal-fajl taċ-ċertifikat CA għal installazzjoni speċifika tal-cluster):

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

  • jew kif ebdagħażla rakkomandata - m'għandekx għalfejn tispeċifika ċ-ċertifikat tal-għeruq (imbagħad kubectl mhux se jiċċekkja l-korrettezza tal-api-server tal-cluster):

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

  • iżżid utent mal-fajl tal-konfigurazzjoni:

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

  • iżżid il-kuntest:

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

  • assenjazzjoni tal-kuntest default:

    kubectl config use-context mynewuser-context

Wara l-manipulazzjonijiet ta 'hawn fuq, fil-fajl .kube/config se tinħoloq konfigurazzjoni bħal din:

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

Biex tagħmilha aktar faċli li tittrasferixxi l-konfigurazzjoni bejn il-kontijiet u s-servers, huwa utli li teditja l-valuri taċ-ċwievet li ġejjin:

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

Biex tagħmel dan, tista' tikkodifika l-fajls speċifikati fihom billi tuża base64 u tirreġistrahom fil-konfigurazzjoni, billi żżid is-suffiss mal-isem taċ-ċwievet -data, i.e. wara li rċeviet certificate-authority-data eċċ

Ċertifikati b'kubeadm

Bir-rilaxx Kubernetes 1.15 il-ħidma maċ-ċertifikati saret ħafna aktar faċli grazzi għall-verżjoni alpha tal-appoġġ tagħha fi kubeadm utilità. Pereżempju, dan huwa dak li tiġġenera fajl ta' konfigurazzjoni b'ċwievet tal-utent issa tista' tidher bħal:

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

NB: Meħtieġ jirreklama l-indirizz jistgħu jinstabu fil-konfigurazzjoni api-server, li awtomatikament jinsab fi /etc/kubernetes/manifests/kube-apiserver.yaml.

Il-konfigurazzjoni li tirriżulta se toħroġ għal stdout. Jeħtieġ li jiġi ffrankat ~/.kube/config kont tal-utent jew għal fajl speċifikat f'varjabbli ambjentali KUBECONFIG.

Ħaffer aktar fil-fond

Għal dawk li jridu jifhmu l-kwistjonijiet deskritti aktar bir-reqqa:

• artikolu separat dwar ix-xogħol maċ-ċertifikati fid-dokumentazzjoni uffiċjali ta’ Kubernetes;
• artiklu tajjeb minn Bitnami, li fiha l-ħruġ taċ-ċertifikati jintmess minn perspettiva prattika.
• dokumentazzjoni ġenerali dwar l-awtentikazzjoni fil-Kubernetes.

Awtorizzazzjoni

Il-kont awtorizzat default m'għandux drittijiet biex jopera fuq il-cluster. Biex jagħti permessi, Kubernetes jimplimenta mekkaniżmu ta 'awtorizzazzjoni.

Qabel il-verżjoni 1.6, Kubernetes uża tip ta 'awtorizzazzjoni msejjaħ ABAC (Kontroll tal-aċċess ibbażat fuq l-attribut). Dettalji dwarha jistgħu jinstabu fi dokumentazzjoni uffiċjali. Dan l-approċċ bħalissa huwa meqjus bħala wirt, iżda xorta tista' tużah flimkien ma' tipi oħra ta' awtentikazzjoni.

Il-mod attwali (u aktar flessibbli) ta' kif jiġu diviżi d-drittijiet ta' aċċess għal cluster jissejjaħ RBAC (Kontroll tal-aċċess ibbażat fuq ir-rwol). Ġie ddikjarat stabbli mill-verżjoni Kubernetes 1.8. L-RBAC jimplimenta mudell ta’ drittijiet li fih dak kollu li mhuwiex permess b’mod espliċitu huwa pprojbit.
Biex tippermetti l-RBAC, għandek bżonn tibda Kubernetes api-server bil-parametru --authorization-mode=RBAC. Il-parametri huma stabbiliti fil-manifest bil-konfigurazzjoni api-server, li awtomatikament tinsab tul il-mogħdija /etc/kubernetes/manifests/kube-apiserver.yaml, fit-taqsima command. Madankollu, RBAC huwa diġà attivat b'mod awtomatiku, għalhekk x'aktarx m'għandekx tinkwieta dwarha: tista' tivverifika dan bil-valur authorization-mode (fl-imsemmi diġà kube-apiserver.yaml). Mill-mod, fost it-tifsiriet tiegħu jista 'jkun hemm tipi oħra ta' awtorizzazzjoni (node, webhook, always allow), iżda aħna se nħallu l-konsiderazzjoni tagħhom barra mill-ambitu tal-materjal.

Mill-mod, aħna diġà ppublikajna oġġett b'deskrizzjoni pjuttost dettaljata tal-prinċipji u l-karatteristiċi ta 'ħidma ma' RBAC, għalhekk aktar se nillimita ruħi għal lista qasira tal-baŜi u l-eżempji.

L-entitajiet tal-API li ġejjin jintużaw biex jikkontrollaw l-aċċess f'Kubernetes permezz tal-RBAC:

• Role и ClusterRole — rwoli li jservu biex jiddeskrivu d-drittijiet ta’ aċċess:
• Role jippermettilek tiddeskrivi drittijiet fi spazju tal-isem;
• ClusterRole - fi ħdan il-cluster, inkluż għal oġġetti speċifiċi għall-cluster bħal nodi, urls li mhumiex riżorsi (jiġifieri mhux relatati mar-riżorsi Kubernetes - pereżempju, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - użat għall-irbit Role и ClusterRole lil utent, grupp ta' utenti jew ServiceAccount.

L-entitajiet Role u RoleBinding huma limitati mill-ispazju tal-isem, i.e. irid ikun fl-istess spazju tal-isem. Madankollu, RoleBinding jista' jirreferi għal ClusterRole, li jippermettilek toħloq sett ta' permessi ġeneriċi u tikkontrolla l-aċċess billi tużahom.

Ir-rwoli jiddeskrivu d-drittijiet billi jużaw settijiet ta’ regoli li fihom:

• Gruppi API - ara dokumentazzjoni uffiċjali minn apiGroups u output kubectl api-resources;
• riżorsi (riżorsi: pod, namespace, deployment u l-bqija.);
• Verbi (verbi: set, update u affarijiet simili).
• ismijiet tar-riżorsi (resourceNames) - għall-każ meta għandek bżonn tipprovdi aċċess għal riżors speċifiku, u mhux għar-riżorsi kollha ta' dan it-tip.

Analiżi aktar dettaljata tal-awtorizzazzjoni f'Kubernetes tista' tinstab fuq il-paġna dokumentazzjoni uffiċjali. Minflok (jew aħjar, minbarra dan), se nagħti eżempji li juru x-xogħol tagħha.

Eżempji ta' entitajiet RBAC

Sempliċi Role, li jippermettilek tikseb lista u status tal-imżiewed u timmonitorjahom fl-ispazju tal-isem 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"]

Eżempju ClusterRole, li jippermettilek li tikseb lista u status tal-imżiewed u timmonitorjahom fil-cluster kollu:

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

Eżempju RoleBinding, li tippermetti lill-utent mynewuser "aqra" miżwed fl-ispazju tal-isem 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

Verifika tal-avveniment

Skematikament, l-arkitettura Kubernetes tista 'tiġi rappreżentata kif ġej:

Il-komponent ewlieni ta 'Kubernetes responsabbli għall-ipproċessar tat-talbiet huwa api-server. L-operazzjonijiet kollha fuq il-cluster jgħaddu minnha. Tista 'taqra aktar dwar dawn il-mekkaniżmi interni fl-artiklu "X'jiġri f'Kubernetes meta tmexxi kubectl run?".

Il-verifika tas-sistema hija karatteristika interessanti f'Kubernetes, li hija diżattivata awtomatikament. Jippermettilek tilloggja s-sejħiet kollha għall-API Kubernetes. Kif tista' taħsbu, l-azzjonijiet kollha relatati mal-monitoraġġ u t-tibdil tal-istat tal-cluster isiru permezz ta' din l-API. Deskrizzjoni tajba tal-kapaċitajiet tagħha tista’ (bħas-soltu) tinsab fi dokumentazzjoni uffiċjali K8s. Sussegwentement, se nipprova nippreżenta s-suġġett b'lingwaġġ aktar sempliċi.

Allura, biex tippermetti l-awditjar, irridu ngħaddu tliet parametri meħtieġa lill-kontenitur fl-api-server, li huma deskritti f'aktar dettall hawn taħt:

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

Minbarra dawn it-tliet parametri meħtieġa, hemm ħafna settings addizzjonali relatati mal-verifika: mir-rotazzjoni tal-log għal deskrizzjonijiet tal-webhook. Eżempju ta' parametri ta' rotazzjoni taz-zkuk:

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

Imma mhux se noqogħdu fuqhom f'aktar dettall - tista 'ssib id-dettalji kollha fiha dokumentazzjoni kube-apiserver.

Kif diġà ssemma, il-parametri kollha huma stabbiliti fil-manifest bil-konfigurazzjoni api-server (b'mod awtomatiku /etc/kubernetes/manifests/kube-apiserver.yaml), fit-taqsima command. Ejja nerġgħu lura għat-3 parametri meħtieġa u janalizzawhom:

1. audit-policy-file — mogħdija għall-fajl YAML li jiddeskrivi l-politika tal-awditjar. Nirritornaw għall-kontenut tiegħu aktar tard, iżda għalissa ser ninnota li l-fajl irid ikun jista 'jinqara mill-proċess api-server. Għalhekk, huwa meħtieġ li titwaħħal ġewwa l-kontenitur, li għalih tista 'żżid il-kodiċi li ġej mat-taqsimiet xierqa tal-konfigurazzjoni:

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

2. audit-log-path — mogħdija għall-fajl log. It-triq trid tkun aċċessibbli wkoll għall-proċess api-server, għalhekk aħna niddeskrivu l-immuntar tiegħu bl-istess mod:

     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 — il-format tar-reġistru tal-verifika. In-nuqqas huwa json, iżda l-format tat-test tal-legat huwa wkoll disponibbli (legacy).

Politika ta' Verifika

Issa dwar il-fajl imsemmi li jiddeskrivi l-politika tal-qtugħ. L-ewwel kunċett tal-politika tal-verifika huwa level, livell tal-qtugħ. Dawn huma kif ġej:

• None - tilloggjax;
• Metadata — metadata tar-rikjesta tal-log: utent, ħin tat-talba, riżorsa fil-mira (pod, namespace, eċċ.), tip ta’ azzjoni (verb), eċċ.;
• Request — metadata tal-log u korp tar-rikjesta;
• RequestResponse — log metadata, korp tar-rikjesta u korp tar-rispons.

L-aħħar żewġ livelli (Request и RequestResponse) ma tirreġistrax talbiet li ma kellhomx aċċess għar-riżorsi (aċċessi għall-hekk imsejħa non-resources urls).

Ukoll it-talbiet kollha jgħaddu diversi stadji:

• RequestReceived — l-istadju meta t-talba tiġi riċevuta mill-proċessur u għadha ma ġietx trażmessa aktar tul il-katina tal-proċessuri;
• ResponseStarted — jintbagħtu headers tar-rispons, iżda qabel jintbagħat il-korp tar-rispons. Ġenerat għal mistoqsijiet li ilhom għaddejjin (per eżempju, watch);
• ResponseComplete — il-korp tar-rispons intbagħat, mhux se tintbagħat aktar informazzjoni;
• Panic — l-avvenimenti jiġu ġġenerati meta tinstab sitwazzjoni anormali.

Biex taqbeż kwalunkwe passi li tista' tuża omitStages.

F'fajl ta' politika, nistgħu niddeskrivu bosta sezzjonijiet b'livelli ta' qtugħ differenti. Se tiġi applikata l-ewwel regola ta' tqabbil misjuba fid-deskrizzjoni tal-politika.

Id-daemon kubelet jimmonitorja l-bidliet fil-manifest bil-konfigurazzjoni tal-api-server u, jekk jinstabu, jerġa' jibda l-kontenitur bl-api-server. Iżda hemm dettall importanti: bidliet fil-fajl tal-politika se jiġu injorati minnha. Wara li tagħmel bidliet fil-fajl tal-politika, ser ikollok bżonn terġa 'tibda l-api-server manwalment. Peress li api-server jinbeda bħala pod statiku, tim kubectl delete mhux se jikkawża li jerġa 'jibda. Int ser ikollok tagħmel dan manwalment docker stop fuq kube-masters, fejn il-politika tal-awditjar ġiet mibdula:

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

Meta tippermetti l-awditjar, huwa importanti li tiftakar dan it-tagħbija fuq kube-apiserver tiżdied. B'mod partikolari, il-konsum tal-memorja għall-ħażna tal-kuntest tat-talba jiżdied. L-illoggjar jibda biss wara li tintbagħat l-header tar-rispons. It-tagħbija tiddependi wkoll fuq il-konfigurazzjoni tal-politika tal-verifika.

Eżempji ta' policies

Ejja nħarsu lejn l-istruttura tal-fajls tal-politika bl-użu ta' eżempji.

Hawnhekk huwa fajl sempliċi policybiex log kollox fil-livell Metadata:

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

Fil-politika tista' tispeċifika lista ta' utenti (Users и ServiceAccounts) u gruppi ta' utenti. Per eżempju, dan huwa kif se ninjoraw l-utenti tas-sistema, iżda log kull ħaġa oħra fil-livell 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

Huwa wkoll possibbli li jiġu deskritti l-miri:

• spazji tal-ismijiet (namespaces);
• Verbi (verbi: get, update, delete u oħrajn);
• riżorsi (riżorsi, jiġifieri: pod, configmaps eċċ.) u gruppi ta’ riżorsi (apiGroups).

Oqgħod attent! Ir-riżorsi u l-gruppi tar-riżorsi (gruppi API, jiġifieri apiGroups), kif ukoll il-verżjonijiet tagħhom installati fil-cluster, jistgħu jinkisbu bl-użu tal-kmandi:

kubectl api-resources
kubectl api-versions

Il-politika tal-awditjar li ġejja hija pprovduta bħala turija tal-aħjar prattiki fi Dokumentazzjoni 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

Eżempju tajjeb ieħor ta 'politika ta' verifika huwa profil użat fil-GCE.

Biex tirrispondi malajr għall-avvenimenti tal-awditjar, huwa possibbli iddeskrivi webhook. Din il-kwistjoni hija koperta fi dokumentazzjoni uffiċjali, inħalliha barra mill-ambitu ta 'dan l-artikolu.

Riżultati ta '

L-artikolu jipprovdi ħarsa ġenerali lejn il-mekkaniżmi bażiċi tas-sigurtà fil-clusters ta’ Kubernetes, li jippermettulek toħloq kontijiet tal-utent personalizzati, tissepara d-drittijiet tagħhom u tirreġistra l-azzjonijiet tagħhom. Nittama li jkun utli għal dawk li jiffaċċjaw kwistjonijiet bħal dawn fit-teorija jew fil-prattika. Nirrakkomanda wkoll li taqra l-lista ta 'materjali oħra dwar is-suġġett tas-sigurtà f'Kubernetes, li tingħata f'"PS" - forsi fosthom issib id-dettalji meħtieġa dwar il-problemi li huma rilevanti għalik.

PS

Aqra wkoll fuq il-blog tagħna:

• «33+ għodda tas-sigurtà Kubernetes»;
• «Introduzzjoni għall-Politiki tan-Netwerk ta' Kubernetes għall-Professjonisti tas-Sigurtà»;
• «Nifhmu RBAC f'Kubernetes»;
• «9 L-Aħjar Prattiki għas-Sigurtà ta' Kubernetes»;
• «11 Modi biex (Mhux) Issir Vittma ta' Kubernetes Hack".

Sors: www.habr.com