Yr ABC o Ddiogelwch yn Kubernetes: Dilysu, Awdurdodi, Archwilio

Yn hwyr neu'n hwyrach, wrth weithredu unrhyw system, mae mater diogelwch yn codi: darparu dilysiad, gwahanu hawliau, archwilio a thasgau eraill. Wedi'i greu eisoes ar gyfer Kubernetes llawer o atebion, sy'n eich galluogi i gyflawni cydymffurfiaeth safonau hyd yn oed mewn amgylcheddau anodd iawn ... Mae'r un deunydd wedi'i neilltuo i'r agweddau diogelwch sylfaenol a weithredir o fewn y mecanweithiau K8s adeiledig. Yn gyntaf oll, bydd yn ddefnyddiol i'r rhai sy'n dechrau dod yn gyfarwydd â Kubernetes - fel man cychwyn ar gyfer astudio materion sy'n ymwneud â diogelwch.

Dilysu

Mae dau fath o ddefnyddiwr yn Kubernetes:

• Cyfrifon Gwasanaeth - cyfrifon a reolir gan API Kubernetes;
• defnyddwyr - defnyddwyr "normal" a reolir gan wasanaethau allanol, annibynnol.

Y prif wahaniaeth rhwng y mathau hyn yw bod gwrthrychau arbennig ar gyfer Cyfrifon Gwasanaeth yn API Kubernetes (fe'u gelwir fel hyn - ServiceAccounts) sy'n rhwym i ofod enw a set o ddata awdurdodi sy'n cael ei storio yn y clwstwr mewn gwrthrychau o fath Cyfrinachau. Bwriad defnyddwyr o'r fath (Cyfrifon Gwasanaeth) yn bennaf yw rheoli hawliau mynediad i API Kubernetes o brosesau sy'n rhedeg mewn clwstwr Kubernetes.

Ar y llaw arall, nid oes gan Ddefnyddwyr Cyffredin gofnodion yn API Kubernetes: rhaid iddynt gael eu rheoli gan fecanweithiau allanol. Maent wedi'u bwriadu ar gyfer pobl neu brosesau sy'n byw y tu allan i'r clwstwr.

Mae pob cais API yn gysylltiedig naill ai â Chyfrif Gwasanaeth neu Ddefnyddiwr, neu fe'i hystyrir yn ddienw.

Mae data dilysu defnyddwyr yn cynnwys:

• enw defnyddiwr — enw defnyddiwr (llythrennau bach!);
• UID - llinyn adnabod defnyddiwr y gall peiriant ei ddarllen ac sy'n "fwy cyson ac unigryw nag enw defnyddiwr";
• grwpiau — rhestr o grwpiau y mae'r defnyddiwr yn perthyn iddynt;
• ychwanegol - meysydd ychwanegol y gellir eu defnyddio gan y mecanwaith awdurdodi.

Gall Kubernetes ddefnyddio nifer fawr o fecanweithiau dilysu: tystysgrifau X509, Tocynnau Cludwyr, dirprwy dilysu, HTTP Basic Auth. Gan ddefnyddio'r mecanweithiau hyn, gallwch chi weithredu nifer fawr o gynlluniau awdurdodi: o ffeil cyfrinair statig i OpenID OAuth2.

At hynny, gellir defnyddio cynlluniau awdurdodi lluosog ar yr un pryd. Yn ddiofyn, mae'r clwstwr yn defnyddio:

• tocynnau cyfrif gwasanaeth - ar gyfer Cyfrifon Gwasanaeth;
• X509 - ar gyfer Defnyddwyr.

Mae'r cwestiwn o reoli Cyfrifon Gwasanaeth y tu hwnt i gwmpas yr erthygl hon, ac i'r rhai sy'n dymuno dysgu mwy am y mater hwn, rwy'n argymell dechrau gyda tudalennau dogfennaeth swyddogol. Byddwn yn edrych yn agosach ar gyhoeddi tystysgrifau X509.

Tystysgrifau i Ddefnyddwyr (X.509)

Mae'r ffordd glasurol o weithio gyda thystysgrifau yn cynnwys:

• cenhedlaeth allweddol:

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

• cynhyrchu cais am dystysgrif:

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

• prosesu'r cais am dystysgrif gan ddefnyddio allweddi CA clwstwr Kubernetes, cael tystysgrif defnyddiwr (i gael tystysgrif, mae angen i chi ddefnyddio cyfrif sydd â mynediad at allwedd CA clwstwr Kubernetes, sydd wedi'i leoli yn ddiofyn yn /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

• creu ffeil ffurfweddu:
  • disgrifiad o'r clwstwr (nodwch gyfeiriad a lleoliad ffeil tystysgrif CA y gosodiad clwstwr penodol):

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

  • neu sut dimopsiwn a argymhellir - ni allwch nodi'r dystysgrif gwraidd (yna ni fydd kubectl yn gwirio cywirdeb yr api-server clwstwr):

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

  • ychwanegu defnyddiwr i'r ffeil ffurfweddu:

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

  • ychwanegu cyd-destun:

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

  • aseiniad cyd-destun diofyn:

    kubectl config use-context mynewuser-context

Ar ôl y manipulations uchod, yn y ffeil .kube/config bydd y ffurfwedd gweld yn cael ei greu:

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

Er mwyn hwyluso trosglwyddo'r ffurfwedd rhwng cyfrifon a gweinyddwyr, mae'n ddefnyddiol golygu gwerthoedd yr allweddi canlynol:

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

I wneud hyn, gallwch amgodio'r ffeiliau a nodir ynddynt gan ddefnyddio base64 a'u cofrestru yn y ffurfwedd, gan ychwanegu'r ôl-ddodiad i enw'r bysellau -data, h.y. a dderbyniwyd certificate-authority-data ac ati

Tystysgrifau gyda kubeadm

Gyda rhyddhau Ciwbernetau 1.15 mae gweithio gyda thystysgrifau wedi dod yn llawer haws diolch i'r fersiwn alffa o'i gefnogaeth yn cyfleustodau kubeadm. Er enghraifft, dyma sut olwg fyddai ar gynhyrchu ffeil ffurfweddu gydag allweddi defnyddiwr nawr:

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

NB: Angenrheidiol cyfeiriad hysbysebu gellir ei weld yn y ffurfwedd api-server, sydd wedi'i leoli yn ddiofyn yn /etc/kubernetes/manifests/kube-apiserver.yaml.

Bydd y cyfluniad canlyniadol yn cael ei argraffu i stdout. Rhaid ei gadw i mewn ~/.kube/config cyfrif defnyddiwr neu i ffeil a nodir mewn newidyn amgylchedd KUBECONFIG.

Cloddiwch yn ddyfnach

I'r rhai sydd am edrych yn agosach ar y materion a ddisgrifiwyd:

• erthygl ar wahân ar weithio gyda thystysgrifau yn nogfennaeth swyddogol Kubernetes;
• erthygl dda gan Bitnami, lle y cyffyrddir â chyhoeddi tystysgrifau o safbwynt ymarferol.
• dogfennaeth gyffredinol ar gyfer dilysu yn Kubernetes.

Awdurdodi

Nid oes gan gyfrif awdurdodedig, yn ddiofyn, hawliau i weithredu ar y clwstwr. Er mwyn rhoi caniatâd, mae Kubernetes yn gweithredu mecanwaith awdurdodi.

Cyn fersiwn 1.6, defnyddiodd Kubernetes fath awdurdodiad o'r enw ABAC (Rheoli mynediad ar sail priodoledd). Ceir manylion amdano yn dogfennaeth swyddogol. Mae'r dull hwn yn cael ei ystyried yn etifeddiaeth ar hyn o bryd, ond gallwch barhau i'w ddefnyddio ar yr un pryd â mathau eraill o awdurdodiad.

Gelwir y ffordd wirioneddol (a mwy hyblyg) o wahanu hawliau mynediad i glwstwr RBAC (Rheoli mynediad yn seiliedig ar rôl). Mae wedi'i ddatgan yn sefydlog ers fersiwn Ciwbernetau 1.8. Mae RBAC yn gweithredu model hawliau sy'n gwrthod popeth na chaniateir yn benodol.
Er mwyn galluogi RBAC, mae angen i chi gychwyn Kubernetes api-server gyda'r paramedr --authorization-mode=RBAC. Mae'r paramedrau wedi'u gosod yn y maniffest gyda'r ffurfweddiad api-server, sydd yn ddiofyn wedi'i leoli ar hyd y llwybr /etc/kubernetes/manifests/kube-apiserver.yaml, yn adran command. Fodd bynnag, yn ddiofyn, mae RBAC eisoes wedi'i alluogi, felly mae'n debyg na ddylech chi boeni amdano: gallwch chi wirio hyn yn ôl y gwerth authorization-mode (yn y crybwyllwyd eisoes kube-apiserver.yaml). Gyda llaw, ymhlith ei werthoedd efallai y bydd mathau eraill o awdurdodiad (node, webhook, always allow), ond byddwn yn gadael eu hystyriaeth y tu hwnt i gwmpas y deunydd.

Gyda llaw, rydym eisoes wedi cyhoeddi erthygl gyda stori eithaf manwl am egwyddorion a nodweddion gweithio gyda RBAC, felly ymhellach byddaf yn cyfyngu fy hun i restr fer o'r pethau sylfaenol a'r enghreifftiau.

Defnyddir yr endidau API canlynol i reoli mynediad i Kubernetes trwy RBAC:

• Role и ClusterRole - rolau sy'n disgrifio hawliau mynediad:
• Role yn eich galluogi i ddisgrifio'r hawliau o fewn y gofod enw;
• ClusterRole - o fewn y clwstwr, gan gynnwys gwrthrychau clwstwr-benodol megis nodau, urls nad ydynt yn adnoddau (hynny yw, nad ydynt yn gysylltiedig ag adnoddau Kubernetes - er enghraifft, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - a ddefnyddir ar gyfer rhwymo Role и ClusterRole i ddefnyddiwr, grŵp defnyddwyr, neu ServiceAccount.

Mae'r endidau Rōl a Rhwymo Rōl wedi'u rhwymo i ofod enwau, h.y. rhaid iddo fod o fewn yr un gofod enw. Fodd bynnag, gall RolBinding gyfeirio at ClusterRole, sy'n eich galluogi i greu set o ganiatadau generig a rheoli mynediad gyda nhw.

Mae rolau’n disgrifio hawliau gan ddefnyddio setiau o reolau sy’n cynnwys:

• Grwpiau API - gweler dogfennaeth swyddogol gan grwpiau api ac allbwn kubectl api-resources;
• adnoddau (adnoddau: pod, namespace, deployment ac yn y blaen.);
• Berfau (berfau: set, update ac yn y blaen.).
• enwau adnoddau (resourceNames) - ar gyfer yr achos pan fydd angen i chi ddarparu mynediad at adnodd penodol, ac nid at yr holl adnoddau o'r math hwn.

Mae dadansoddiad manylach o awdurdodiad yn Kubernetes i'w weld ar y dudalen dogfennaeth swyddogol. Yn hytrach (neu yn hytrach, yn ychwanegol at hyn), rhoddaf enghreifftiau sy'n darlunio ei waith.

Enghreifftiau o Endidau RBAC

Syml Role, sy'n eich galluogi i gael rhestr a statws codennau a chadw golwg arnynt yn y gofod enwau 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"]

Enghraifft ClusterRole, sy'n eich galluogi i gael rhestr a statws codennau a'u monitro ledled y clwstwr:

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

Enghraifft RoleBinding, sy'n caniatáu i'r defnyddiwr mynewuser codennau "darllen" mewn gofod enwau 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

Archwiliad Digwyddiad

Yn sgematig, gellir cynrychioli pensaernïaeth Kubernetes fel a ganlyn:

Cydran allweddol Kubernetes sy'n gyfrifol am brosesu ceisiadau yw − api-weinydd. Mae pob llawdriniaeth ar y clwstwr yn mynd drwyddo. Gallwch ddarllen mwy am y mecanweithiau mewnol hyn yn yr erthygl "Beth sy'n digwydd yn Kubernetes pan fyddwch chi'n rhedeg rhediad kubectl?'.

Mae System Archwilio yn nodwedd ddiddorol yn Kubernetes sy'n anabl yn ddiofyn. Mae'n caniatáu ichi logio pob galwad i Kubernetes API. Fel y gallech ddyfalu, mae'r holl gamau gweithredu sy'n ymwneud â rheoli a newid cyflwr y clwstwr yn cael eu perfformio trwy'r API hwn. Ceir disgrifiad da o'i alluoedd (fel arfer) yn dogfennaeth swyddogol K8s. Nesaf, byddaf yn ceisio nodi'r pwnc mewn iaith symlach.

Felly, i alluogi archwilio, mae angen inni drosglwyddo tri pharamedr gofynnol i'r cynhwysydd yn api-server, a ddisgrifir yn fanylach isod:

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

Yn ogystal â'r tri pharamedr gofynnol hyn, mae yna lawer o leoliadau ychwanegol yn ymwneud ag archwilio: o gylchdroi boncyffion i ddisgrifiadau bachau gwe. Enghraifft o baramedrau cylchdroi log:

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

Ond ni fyddwn yn aros arnynt yn fwy manwl - gallwch ddod o hyd i'r holl fanylion yn dogfennaeth kube-apiserver.

Fel y soniwyd eisoes, mae'r holl baramedrau wedi'u gosod yn y maniffest gyda'r ffurfweddiad api-server (yn ddiofyn /etc/kubernetes/manifests/kube-apiserver.yaml), yn yr adran command. Gadewch i ni fynd yn ôl at y 3 pharamedr gofynnol a'u dadansoddi:

1. audit-policy-file - y llwybr i ffeil YAML gyda disgrifiad o bolisi (polisi) yr archwiliad. Byddwn yn dychwelyd at ei gynnwys, ond am y tro byddaf yn nodi bod yn rhaid i'r ffeil fod yn ddarllenadwy gan y broses api-server. Felly, mae angen i chi ei osod y tu mewn i'r cynhwysydd, y gallwch chi ychwanegu'r cod canlynol ar ei gyfer i'r adrannau priodol o'r ffurfwedd:

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

2. audit-log-path - llwybr i'r ffeil log. Rhaid i'r llwybr hefyd fod ar gael i'r broses api-server, felly rydym yn disgrifio ei osod yn yr un modd:

     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 — fformat log archwilio. Y rhagosodiad yw json, ond mae fformat y testun etifeddiaeth hefyd ar gael (legacy).

Polisi Archwilio

Nawr am y ffeil a grybwyllir gyda disgrifiad o'r polisi logio. Y cysyniad cyntaf o bolisi archwilio yw level, lefel logio. Maent fel a ganlyn:

• None - peidiwch â logio;
• Metadata — metadata cais log: defnyddiwr, amser cais, adnodd targed (pod, gofod enw, ac ati), math o weithred (berf), ac ati;
• Request - logio metadata a chorff ceisiadau;
• RequestResponse - logio metadata, corff ceisiadau a chorff ymateb.

Y ddwy lefel olafRequest и RequestResponse) peidio â chofnodi ceisiadau nad oeddent yn cyrchu adnoddau (cyfeiriadau at yr urls nad ydynt yn adnoddau fel y'u gelwir).

Hefyd, mae pob cais yn mynd drwodd sawl cam:

• RequestReceived - y cam pan fydd y sawl sy'n trin y cais yn dod i law ac nad yw eto wedi'i drosglwyddo ymhellach ar hyd y gadwyn o drinwyr;
• ResponseStarted - Anfonir y penawdau ymateb, ond cyn anfon y corff ymateb. Wedi'i gynhyrchu ar gyfer ymholiadau hirdymor (er enghraifft, watch);
• ResponseComplete - mae'r corff ymateb wedi'i anfon, ni fydd mwy o wybodaeth yn cael ei anfon;
• Panic — Cynhyrchir digwyddiadau pan ganfyddir sefyllfa annormal.

I hepgor unrhyw gamau, gallwch eu defnyddio omitStages.

Yn y ffeil polisi, gallwn ddisgrifio sawl adran gyda lefelau cofnodi gwahanol. Bydd y rheol baru gyntaf a geir yn nisgrifiad y polisi yn cael ei gweithredu.

Mae'r daemon kubelet yn gwrando am newid yn y maniffest gyda'r ffurfweddiad api-server ac, os o gwbl, yn ailgychwyn y cynhwysydd api-server. Ond mae yna fanylion pwysig: bydd newidiadau yn y ffeil polisi yn cael eu hanwybyddu. Ar ôl gwneud newidiadau i'r ffeil polisi, bydd angen i chi ailgychwyn yr api-server â llaw. Gan fod api-server yn cael ei gychwyn fel pod statig, tîm kubectl delete ni fydd yn ei ailgychwyn. Bydd yn rhaid ei wneud â llaw docker stop ar kube-masters lle mae’r polisi archwilio wedi’i newid:

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

Wrth alluogi archwilio, mae'n bwysig cofio hynny codiadau llwyth ar kube-apiserver. Yn benodol, mae'r defnydd o gof ar gyfer storio cyd-destun yr ymholiad yn cynyddu. Dim ond ar ôl i'r pennawd ymateb gael ei anfon y bydd y logio'n dechrau. Mae'r llwyth hefyd yn dibynnu ar gyfluniad y polisi archwilio.

Enghreifftiau polisi

Gadewch i ni ddadansoddi strwythur ffeiliau polisi gan ddefnyddio enghreifftiau.

Dyma ffeil syml policyi gofnodi popeth ar y lefel Metadata:

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

Mewn polisi, gallwch nodi rhestr o ddefnyddwyr (Users и ServiceAccounts) a grwpiau defnyddwyr. Er enghraifft, dyma sut y byddwn yn anwybyddu defnyddwyr system, ond yn cofnodi popeth arall ar y lefel 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

Mae hefyd yn bosibl disgrifio’r targed:

• bylchau enw (namespaces);
• Berfau (berfau: get, update, delete ac eraill);
• adnoddau (adnoddau, sef: pod, configmaps ac ati) a grwpiau adnoddau (apiGroups).

Talu sylw! Gellir cael adnoddau a grwpiau adnoddau (grwpiau API, h.y. apiGroups), yn ogystal â'u fersiynau sydd wedi'u gosod yn y clwstwr, gan ddefnyddio'r gorchmynion:

kubectl api-resources
kubectl api-versions

Darperir y polisi archwilio canlynol fel arddangosiad o'r arferion gorau mewn Dogfennaeth Cwmwl Alibaba:

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

Enghraifft dda arall o bolisi archwilio yw proffil a ddefnyddir yn TAG.

Ar gyfer ymateb prydlon i ddigwyddiadau archwilio, mae'n bosibl disgrifio bachyn gwe. Ymdrinnir â'r cwestiwn hwn yn dogfennaeth swyddogolByddaf yn ei adael y tu allan i gwmpas yr erthygl hon.

Canlyniadau

Mae'r erthygl hon yn rhoi trosolwg o'r mecanweithiau diogelwch sylfaenol yng nghlystyrau Kubernetes sy'n caniatáu creu cyfrifon defnyddwyr personol, gwahanu eu hawliau, a chofnodi eu gweithredoedd. Rwy'n gobeithio y bydd yn ddefnyddiol i'r rhai sy'n wynebu materion o'r fath mewn theori neu sydd eisoes yn ymarferol. Rwyf hefyd yn argymell eich bod yn ymgyfarwyddo â'r rhestr o ddeunyddiau eraill ar y pwnc diogelwch yn Kubernetes, a roddir yn "PS", efallai yn eu plith y byddwch yn dod o hyd i'r manylion angenrheidiol ar y problemau sy'n berthnasol i chi.

PS

Darllenwch hefyd ar ein blog:

• «33+ o offer diogelwch Kubernetes";
• «Cyflwyniad i Bolisïau Rhwydwaith Kubernetes ar gyfer Gweithwyr Proffesiynol Diogelwch";
• «Deall RBAC yn Kubernetes";
• «9 Arferion Gorau Diogelwch Kubernetes";
• «11 Ffordd o (Beidio) Cael Hacio yn Kubernetes'.

Ffynhonnell: hab.com