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

Sa madugay o sa madali, sa operasyon sa bisan unsa nga sistema, ang isyu sa seguridad mitungha: pagsiguro sa authentication, pagbulag sa mga katungod, auditing ug uban pang mga buluhaton. Nahimo na para sa Kubernetes daghang solusyon, nga nagtugot kanimo sa pagkab-ot sa pagsunod sa mga sumbanan bisan sa lisud kaayo nga mga palibot... Ang sama nga materyal gigahin sa mga batakang aspeto sa seguridad nga gipatuman sulod sa mga built-in nga mekanismo sa K8s. Una sa tanan, mapuslanon kini sa mga nagsugod sa pag-ila sa Kubernetes - isip usa ka punto sa pagsugod sa pagtuon sa mga isyu nga may kalabutan sa seguridad.

Pagpanghimatuud

Adunay duha ka matang sa mga tiggamit sa Kubernetes:

• Mga Account sa Serbisyo — mga account nga gidumala sa Kubernetes API;
• Users — "normal" nga mga tiggamit nga gidumala sa gawas, independente nga mga serbisyo.

Ang nag-unang kalainan tali niini nga mga matang mao nga alang sa Mga Account sa Serbisyo adunay espesyal nga mga butang sa Kubernetes API (gitawag sila nga - ServiceAccounts), nga gihigot sa usa ka namespace ug usa ka set sa data sa pagtugot nga gitipigan sa cluster sa mga butang sa tipo sa Secrets. Ang maong mga tiggamit (Service Accounts) kay gituyo sa pagdumala sa mga katungod sa pag-access sa Kubernetes API sa mga proseso nga nagdagan sa Kubernetes cluster.

Ang mga Ordinaryong Gumagamit walay mga entri sa Kubernetes API: sila kinahanglang madumala pinaagi sa mga eksternal nga mekanismo. Gituyo kini alang sa mga tawo o mga proseso nga nagpuyo sa gawas sa cluster.

Ang matag hangyo sa API nalangkit sa usa ka Account sa Serbisyo, usa ka Gumagamit, o giisip nga wala mailhi.

Ang datos sa pag-authenticate sa user naglakip sa:

• Username — username (sensitibo sa kaso!);
• UID - usa ka string sa pag-ila sa user nga mabasa sa makina nga "mas makanunayon ug talagsaon kaysa sa username";
• Groups — lista sa mga grupo diin ang tiggamit nahisakop;
• Extra — dugang nga mga natad nga mahimong magamit sa mekanismo sa pagtugot.

Makagamit ang mga Kubernetes og daghang mga mekanismo sa pag-authenticate: X509 nga mga sertipiko, mga token sa Bearer, proxy nga nagpamatuod, HTTP Basic Auth. Gamit kini nga mga mekanismo, mahimo nimong ipatuman ang daghang mga laraw sa pagtugot: gikan sa usa ka static nga file nga adunay mga password hangtod sa OpenID OAuth2.

Dugang pa, posible nga gamiton ang daghang mga laraw sa pagtugot nga dungan. Sa kasagaran, ang cluster naggamit:

• mga token sa account sa serbisyo - alang sa Mga Account sa Serbisyo;
• X509 - alang sa mga Gumagamit.

Ang pangutana bahin sa pagdumala sa ServiceAccounts lapas pa sa sakup sa kini nga artikulo, apan alang sa mga gusto nga pamilyar ang ilang kaugalingon sa kini nga isyu sa mas detalyado, girekomenda ko nga magsugod sa opisyal nga mga panid sa dokumentasyon. Atong tan-awon pag-ayo ang isyu kung giunsa ang pagtrabaho sa mga sertipiko sa X509.

Mga sertipiko alang sa mga tiggamit (X.509)

Ang klasiko nga paagi sa pagtrabaho sa mga sertipiko naglakip sa:

• yawe nga henerasyon:

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

• paghimo og hangyo sa sertipiko:

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

• pagproseso sa hangyo sa sertipiko gamit ang Kubernetes cluster CA keys, pagkuha og user certificate (aron makakuha og certificate, kinahanglan nga mogamit ka og account nga adunay access sa Kubernetes cluster CA key, nga sa default anaa 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

• paghimo og configuration file:
  • paghulagway sa cluster (ipiho ang adres ug lokasyon sa CA certificate file alang sa usa ka piho nga pag-install sa cluster):

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

  • o unsaon diligirekomenda nga kapilian - dili nimo kinahanglan nga ipiho ang gamut nga sertipiko (unya ang kubectl dili magsusi sa pagkahusto sa api-server sa cluster):

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

  • pagdugang ug user sa configuration file:

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

  • pagdugang konteksto:

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

  • default nga assignment sa konteksto:

    kubectl config use-context mynewuser-context

Human sa mga manipulasyon sa ibabaw, sa file .kube/config usa ka config nga sama niini pagabuhaton:

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

Aron mas sayon ​​​​ang pagbalhin sa config tali sa mga account ug server, mapuslanon ang pag-edit sa mga bili sa mosunod nga mga yawe:

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

Aron mahimo kini, mahimo nimong i-encode ang mga file nga gitakda sa kanila gamit ang base64 ug irehistro kini sa config, idugang ang suffix sa ngalan sa mga yawe. -data, i.e. nga nakadawat certificate-authority-data ug uban pa.

Mga sertipiko nga adunay kubeadm

Uban sa pagpagawas Kubernet 1.15 Ang pagtrabaho sa mga sertipiko nahimong labi ka dali salamat sa alpha nga bersyon sa suporta niini sa kubeadm utility. Pananglitan, mao kini ang hitsura sa paghimo og configuration file nga adunay mga yawe sa user:

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

NB: Gikinahanglan advertise address makita sa api-server config, nga sa default nahimutang sa /etc/kubernetes/manifests/kube-apiserver.yaml.

Ang resulta nga config mahimong output sa stdout. Kinahanglan kini i-save sa ~/.kube/config user account o sa usa ka file nga gipiho sa usa ka environment variable KUBECONFIG.

Pagkalot ug Lalim

Alang niadtong gusto nga masabtan ang mga isyu nga gihulagway nga mas bug-os:

• bulag nga artikulo sa pagtrabaho kauban ang mga sertipiko sa opisyal nga dokumentasyon sa Kubernetes;
• maayong artikulo gikan sa Bitnami, diin ang isyu sa mga sertipiko natandog gikan sa praktikal nga panan-aw.
• kinatibuk-ang dokumentasyon sa authentication sa Kubernetes.

Awtorisasyon

Ang default nga awtorisado nga account walay katungod sa pag-operate sa cluster. Aron paghatag ug pagtugot, ang Kubernetes nagpatuman ug mekanismo sa pagtugot.

Sa wala pa ang bersyon 1.6, ang Kubernetes migamit ug tipo sa pagtugot nga gitawag ABAC (Pagkontrol sa pag-access base sa kinaiya). Ang mga detalye bahin niini makita sa opisyal nga dokumentasyon. Kini nga pamaagi sa pagkakaron giisip nga kabilin, apan mahimo gihapon nimo kining gamiton kauban sa ubang mga tipo sa pag-authenticate.

Ang karon (ug mas flexible) nga paagi sa pagbahin sa mga katungod sa pag-access sa usa ka cluster gitawag RBAC (Pagkontrol sa pag-access nga gibase sa papel). Gideklarar kini nga stable sukad sa bersyon Kubernet 1.8. Ang RBAC nagpatuman ug modelo sa katungod diin gidili ang tanan nga dili klaro nga gitugutan.
Aron mahimo ang RBAC, kinahanglan nimong sugdan ang Kubernetes api-server gamit ang parameter --authorization-mode=RBAC. Ang mga parameter gitakda sa manifest nga adunay configuration sa api-server, nga sa default nahimutang sa daplin sa dalan /etc/kubernetes/manifests/kube-apiserver.yaml, sa seksyon command. Bisan pa, ang RBAC gipalihok na pinaagi sa default, mao nga lagmit dili ka angay mabalaka bahin niini: mahimo nimo kini mapamatud-an pinaagi sa kantidad. authorization-mode (sa nahisgotan na kube-apiserver.yaml). Pinaagi sa dalan, taliwala sa mga kahulogan niini mahimong adunay ubang mga matang sa pagtugot (node, webhook, always allow), apan atong ibilin ang ilang konsiderasyon sa gawas sa kasangkaran sa materyal.

By the way, napublikar na namo usa ka artikulo uban sa usa ka patas nga detalyado nga paghulagway sa mga prinsipyo ug mga bahin sa pagtrabaho uban sa RBAC, mao nga sa dugang nga limitahan ang akong kaugalingon sa usa ka mubo nga listahan sa mga sukaranan ug mga panig-ingnan.

Ang mosunod nga mga entidad sa API gigamit aron makontrol ang pag-access sa Kubernetes pinaagi sa RBAC:

• Role и ClusterRole — mga tahas nga nagsilbi sa paghulagway sa mga katungod sa pag-access:
• Role nagtugot kanimo sa paghulagway sa mga katungod sulod sa usa ka namespace;
• ClusterRole - sulod sa cluster, lakip na sa cluster-specific nga mga butang sama sa mga node, non-resources urls (i.e. walay kalabotan sa Kubernetes resources - pananglitan, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - gigamit alang sa pagbugkos Role и ClusterRole sa usa ka user, user group o ServiceAccount.

Ang Role ug RoleBinding entity limitado sa namespace, i.e. kinahanglan nga naa sa parehas nga namespace. Bisan pa, ang usa ka RoleBinding mahimong maghisgot sa usa ka ClusterRole, nga nagtugot kanimo sa paghimo og usa ka set sa mga generic nga pagtugot ug pagkontrol sa pag-access gamit kini.

Ang mga tahas naghulagway sa mga katungod gamit ang mga hugpong sa mga lagda nga naglangkob:

• Mga grupo sa API - tan-awa opisyal nga dokumentasyon pinaagi sa apiGroups ug output kubectl api-resources;
• kahinguhaan (Mga kapanguhaan: pod, namespace, deployment ug uban pa.);
• Mga berbo (berbo: set, update ug uban pa.).
• mga ngalan sa kapanguhaan (resourceNames) - alang sa kaso kung kinahanglan nimo nga maghatag access sa usa ka piho nga kapanguhaan, ug dili sa tanan nga mga kapanguhaan sa kini nga tipo.

Ang mas detalyado nga pagtuki sa pagtugot sa Kubernetes makita sa panid opisyal nga dokumentasyon. Hinunoa (o hinoon, dugang pa niini), mohatag ko og mga pananglitan nga nag-ilustrar sa iyang trabaho.

Mga pananglitan sa mga entidad sa RBAC

Yano Role, nga nagtugot kanimo nga makakuha usa ka lista ug kahimtang sa mga pod ug bantayan kini 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"]

Pananglitan: ClusterRole, nga nagtugot kanimo nga makakuha usa ka lista ug kahimtang sa mga pod ug bantayan kini sa tibuuk nga cluster:

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

Pananglitan: RoleBinding, nga nagtugot sa tiggamit mynewuser "basaha" 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 sa panghitabo

Sa eskematiko, ang arkitektura sa Kubernetes mahimong irepresentar sa mosunod:

Ang yawe nga bahin sa Kubernetes nga responsable sa pagproseso sa mga hangyo mao ang api-server. Ang tanan nga mga operasyon sa cluster moagi niini. Mahimo nimong mabasa ang dugang bahin sa kini nga mga internal nga mekanismo sa artikulo nga "Unsa ang mahitabo sa Kubernetes kung imong gipadagan ang kubectl run?".

Ang pag-audit sa sistema usa ka makapaikag nga bahin sa Kubernetes, nga gi-disable pinaagi sa default. Gitugotan ka niini nga ma-log ang tanan nga mga tawag sa Kubernetes API. Sama sa imong gitag-an, ang tanan nga mga aksyon nga may kalabotan sa pag-monitor ug pagbag-o sa kahimtang sa cluster gihimo pinaagi sa kini nga API. Ang usa ka maayong paghulagway sa mga kapabilidad niini mahimong (sama sa naandan) makit-an sa opisyal nga dokumentasyon K8s. Sunod, sulayan nako nga ipresentar ang hilisgutan sa mas simple nga pinulongan.

Ug busa, aron mahimo ang pag-audit, kinahanglan natong ipasa ang tulo ka gikinahanglan nga mga parameter sa sudlanan sa api-server, nga gihulagway sa mas detalyado sa ubos:

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

Dugang pa niining tulo ka kinahanglanon nga mga parameter, adunay daghang dugang nga mga setting nga may kalabutan sa pag-audit: gikan sa rotation sa log ngadto sa mga paghulagway sa webhook. Pananglitan sa mga parameter sa rotation sa log:

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

Apan dili kami maghisgot bahin niini sa mas detalyado - makit-an nimo ang tanan nga mga detalye sa dokumentasyon sa kube-apiserver.

Sama sa nahisgotan na, ang tanan nga mga parameter gitakda sa manifest nga adunay api-server configuration (sa default /etc/kubernetes/manifests/kube-apiserver.yaml), sa seksyon command. Atong balikan ang 3 nga gikinahanglan nga mga parameter ug analisahon kini:

1. audit-policy-file — dalan sa YAML file nga naghulagway sa polisiya sa pag-audit. Mobalik kami sa mga sulud niini sa ulahi, apan sa pagkakaron akong matikdan nga ang file kinahanglan nga mabasa sa proseso sa api-server. Busa, gikinahanglan nga i-mount kini sa sulod sa sudlanan, diin mahimo nimong idugang ang mosunod nga code sa angay nga mga seksyon sa config:

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

2. audit-log-path — dalan sa log file. Ang agianan kinahanglan usab nga ma-access sa proseso sa api-server, mao nga among gihulagway ang pag-mount niini sa parehas nga paagi:

     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 sa log sa pag-audit. Ang default mao ang json, apan ang legacy text format anaa usab (legacy).

Patakaran sa Audit

Karon bahin sa gihisgutan nga file nga naghulagway sa palisiya sa pag-log. Ang una nga konsepto sa polisiya sa pag-audit mao ang level, lebel sa logging. Sila mao ang mosunod:

• None - ayaw pag-log;
• Metadata — metadata sa hangyo sa log: user, oras sa paghangyo, target nga kapanguhaan (pod, namespace, ug uban pa), tipo sa aksyon (berbo), ug uban pa;
• Request - log metadata ug hangyo nga lawas;
• RequestResponse - log metadata, hangyo nga lawas ug tubag nga lawas.

Ang katapusan nga duha ka lebel (Request и RequestResponse) ayaw pag-log sa mga hangyo nga wala maka-access sa mga kahinguhaan (mga access sa gitawag nga non-resources urls).

Usab ang tanan nga mga hangyo moagi pipila ka yugto:

• RequestReceived - ang yugto kung ang hangyo nadawat sa processor ug wala pa mapasa sa kadena sa mga processor;
• ResponseStarted — Ang mga ulohan sa tubag gipadala, apan sa wala pa ipadala ang lawas sa tubag. Gihimo alang sa dugay nang mga pangutana (pananglitan, watch);
• ResponseComplete — ang tubag nga lawas gipadala na, wala nay dugang impormasyon nga ipadala;
• Panic — Nahimo ang mga panghitabo kung adunay nakit-an nga dili normal nga kahimtang.

Aron laktawan ang bisan unsang mga lakang nga imong magamit omitStages.

Sa usa ka file sa palisiya, mahimo natong ihulagway ang daghang mga seksyon nga adunay lainlaing lebel sa pag-log. Ang una nga katugbang nga lagda nga makit-an sa paghulagway sa palisiya magamit.

Ang kubelet daemon nagmonitor sa mga pagbag-o sa manifest gamit ang configuration sa api-server ug, kung adunay mamatikdan, i-restart ang sudlanan gamit ang api-server. Apan adunay usa ka importante nga detalye: Ang mga pagbag-o sa file sa palisiya dili tagdon niini. Human sa paghimo og mga kausaban sa policy file, kinahanglan nimo nga i-restart ang api-server nga mano-mano. Tungod kay ang api-server gisugdan ingon static pod, team kubectl delete dili kini hinungdan sa pagsugod pag-usab. Kinahanglan nimo nga buhaton kini nga mano-mano docker stop sa kube-masters, diin ang polisiya sa pag-audit nausab:

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

Kung gi-enable ang pag-audit, importante nga hinumdoman kana motaas ang load sa kube-apiserver. Sa partikular, ang pagkonsumo sa memorya alang sa pagtipig sa konteksto sa hangyo nagdugang. Ang pag-log magsugod lamang human ipadala ang header sa tubag. Ang load nagdepende usab sa configuration sa polisiya sa audit.

Mga pananglitan sa mga palisiya

Atong tan-awon ang istruktura sa mga file sa palisiya gamit ang mga pananglitan.

Ania ang usa ka yano nga file policyaron ma-log ang tanan sa lebel Metadata:

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

Sa palisiya mahimo nimong itakda ang usa ka lista sa mga tiggamit (Users и ServiceAccounts) ug mga grupo sa tiggamit. Pananglitan, mao kini ang paagi nga dili nato ibalewala ang mga tiggamit sa sistema, apan i-log ang tanan sa lebel 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 usab nga ihulagway ang mga target:

• mga namespace (namespaces);
• Mga berbo (berbo: get, update, delete ug uban pa);
• kahinguhaan (Mga kapanguhaan, nga mao: pod, configmaps ug uban pa) ug mga grupo sa kapanguhaan (apiGroups).

Hatagi'g pagtagad! Mga kapanguhaan ug mga grupo sa kapanguhaan (mga grupo sa API, i.e. apiGroups), ingon man ang ilang mga bersyon nga gi-install sa cluster, mahimong makuha gamit ang mga mando:

kubectl api-resources
kubectl api-versions

Ang mosunud nga polisiya sa pag-audit gihatag ingon usa ka pagpakita sa labing kaayo nga mga gawi sa Dokumentasyon sa 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 laing maayong pananglitan sa polisiya sa pag-audit mao profile nga gigamit sa GCE.

Aron dali nga makatubag sa mga panghitabo sa pag-audit, posible ihulagway ang webhook. Kini nga isyu gitabonan sa opisyal nga dokumentasyon, Ibilin ko kini sa gawas sa kasangkaran niini nga artikulo.

Mga resulta

Naghatag ang artikulo og usa ka kinatibuk-ang ideya sa mga sukaranan nga mekanismo sa seguridad sa mga cluster sa Kubernetes, nga nagtugot kanimo sa paghimo og personalized nga mga account sa gumagamit, pagbulag sa ilang mga katungod, ug pagrekord sa ilang mga aksyon. Nanghinaut ko nga kini mapuslanon sa mga nag-atubang sa ingon nga mga isyu sa teorya o sa praktis. Girekomenda usab nako nga basahon nimo ang lista sa ubang mga materyal sa hilisgutan sa seguridad sa Kubernetes, nga gihatag sa "PS" - tingali sa taliwala nila makit-an nimo ang kinahanglan nga mga detalye sa mga problema nga may kalabotan kanimo.

PS

Basaha usab sa among blog:

• «33+ Kubernetes mga himan sa seguridad";
• «Usa ka Pasiuna sa Mga Patakaran sa Kubernetes Network para sa mga Propesyonal sa Seguridad";
• «Pagsabot sa RBAC sa Kubernetes";
• «9 Kubernetes Security Best Practices";
• «11 Mga Paagi aron (Dili) Ma-hack sa Kubernetes".

Source: www.habr.com