Kubernetesdagi xavfsizlik ABC: autentifikatsiya, avtorizatsiya, audit

Ertami-kechmi, har qanday tizimning ishlashida xavfsizlik masalasi paydo bo'ladi: autentifikatsiyani ta'minlash, huquqlarni ajratish, audit va boshqa vazifalar. Kubernetes uchun allaqachon yaratilgan ko'p echimlar, bu juda talabchan sharoitlarda ham standartlarga muvofiqlikka erishish imkonini beradi... Xuddi shu material K8-larning o'rnatilgan mexanizmlari doirasida amalga oshirilgan xavfsizlikning asosiy jihatlariga bag'ishlangan. Avvalo, bu Kubernetes bilan tanishishni boshlaganlar uchun foydali bo'ladi - xavfsizlik bilan bog'liq muammolarni o'rganish uchun boshlang'ich nuqta sifatida.

Autentifikatsiya

Kubernetesda ikki turdagi foydalanuvchilar mavjud:

• Xizmat hisoblari — Kubernetes API tomonidan boshqariladigan hisoblar;
• foydalanuvchilar — tashqi, mustaqil xizmatlar tomonidan boshqariladigan "oddiy" foydalanuvchilar.

Ushbu turlarning asosiy farqi shundaki, xizmat hisoblari uchun Kubernetes API-da maxsus ob'ektlar mavjud (ular shunday deyiladi - ServiceAccounts), ular Sirlar tipidagi ob'ektlarda klasterda saqlanadigan nomlar maydoni va avtorizatsiya ma'lumotlari to'plamiga bog'langan. Bunday foydalanuvchilar (Xizmat hisoblari) birinchi navbatda Kubernetes klasterida ishlaydigan jarayonlarning Kubernetes API-ga kirish huquqlarini boshqarish uchun mo'ljallangan.

Oddiy foydalanuvchilarda Kubernetes API-da yozuvlar yo'q: ular tashqi mexanizmlar tomonidan boshqarilishi kerak. Ular klasterdan tashqarida yashovchi odamlar yoki jarayonlar uchun mo'ljallangan.

Har bir API soʻrovi xizmat hisobi, foydalanuvchi bilan bogʻlanadi yoki anonim hisoblanadi.

Foydalanuvchi autentifikatsiya ma'lumotlari quyidagilarni o'z ichiga oladi:

• Foydalanuvchi nomi — foydalanuvchi nomi (katta harflar farqlanadi!);
• UID - "foydalanuvchi nomidan ko'ra ko'proq izchil va noyob" bo'lgan, mashina tomonidan o'qiladigan foydalanuvchi identifikatsiya qatori;
• Guruhlar — foydalanuvchi tegishli bo'lgan guruhlar ro'yxati;
• qo'shimcha — avtorizatsiya mexanizmi tomonidan ishlatilishi mumkin bo'lgan qo'shimcha maydonlar.

Kubernetes ko'p sonli autentifikatsiya mexanizmlaridan foydalanishi mumkin: X509 sertifikatlari, Bearer tokenlari, autentifikatsiya qiluvchi proksi, HTTP Basic Auth. Ushbu mexanizmlardan foydalanib, siz ko'plab avtorizatsiya sxemalarini amalga oshirishingiz mumkin: parollar bilan statik fayldan OpenID OAuth2gacha.

Bundan tashqari, bir vaqtning o'zida bir nechta avtorizatsiya sxemalaridan foydalanish mumkin. Odatiy bo'lib, klaster quyidagilarni ishlatadi:

• xizmat hisobi tokenlari - Xizmat hisoblari uchun;
• X509 - foydalanuvchilar uchun.

ServiceAccounts-ni boshqarish haqidagi savol ushbu maqola doirasidan tashqarida, ammo bu masala bilan batafsilroq tanishmoqchi bo'lganlar uchun mendan boshlashni maslahat beraman. rasmiy hujjatlar sahifalari. X509 sertifikatlari qanday ishlashi masalasini batafsil ko'rib chiqamiz.

Foydalanuvchilar uchun sertifikatlar (X.509)

Sertifikatlar bilan ishlashning klassik usuli quyidagilarni o'z ichiga oladi:

• asosiy avlod:

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

• sertifikat so'rovini yaratish:

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

• Kubernetes klasterining CA kalitlari yordamida sertifikat so'rovini qayta ishlash, foydalanuvchi sertifikatini olish (sertifikatni olish uchun siz sukut bo'yicha Kubernetes klasterining CA kalitiga kirish huquqiga ega hisob qaydnomasidan foydalanishingiz kerak. /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

• konfiguratsiya faylini yaratish:
  • klaster tavsifi (ma'lum bir klaster o'rnatilishi uchun CA sertifikat faylining manzili va joylashuvini ko'rsating):

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

  • yoki qanday qilib yo'qtavsiya etilgan variant - siz ildiz sertifikatini ko'rsatishingiz shart emas (keyin kubectl klaster api-serverining to'g'riligini tekshirmaydi):

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

  • konfiguratsiya fayliga foydalanuvchi qo'shish:

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

  • kontekst qo'shish:

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

  • standart kontekst tayinlash:

    kubectl config use-context mynewuser-context

Yuqoridagi manipulyatsiyalardan so'ng, faylda .kube/config shunga o'xshash konfiguratsiya yaratiladi:

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

Hisoblar va serverlar o'rtasida konfiguratsiyani o'tkazishni osonlashtirish uchun quyidagi kalitlarning qiymatlarini tahrirlash foydali bo'ladi:

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

Buni amalga oshirish uchun siz ularda ko'rsatilgan fayllarni base64-dan foydalanib kodlashingiz va ularni konfiguratsiyada ro'yxatdan o'tkazishingiz va tugmalar nomiga qo'shimcha qo'shishingiz mumkin. -data, ya'ni. olgan certificate-authority-data va h.k.

Kubeadm bilan sertifikatlar

Chiqarish bilan Kubernetes 1.15 da qo'llab-quvvatlashning alfa versiyasi tufayli sertifikatlar bilan ishlash ancha osonlashdi kubeadm yordam dasturi. Masalan, foydalanuvchi kalitlari bilan konfiguratsiya faylini yaratish endi shunday ko'rinishi mumkin:

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

NB: Majburiy reklama manzili sukut bo'yicha joylashgan api-server konfiguratsiyasida topish mumkin /etc/kubernetes/manifests/kube-apiserver.yaml.

Olingan konfiguratsiya stdout-ga chiqariladi. Uni saqlash kerak ~/.kube/config foydalanuvchi hisobiga yoki muhit o'zgaruvchisida ko'rsatilgan faylga KUBECONFIG.

Chuqurroq qazing

Batafsil tavsiflangan masalalarni tushunishni istaganlar uchun:

• alohida maqola rasmiy Kubernetes hujjatlarida sertifikatlar bilan ishlash bo'yicha;
• Bitnami-dan yaxshi maqola, unda sertifikatlar masalasi amaliy nuqtai nazardan ko'rib chiqiladi.
• umumiy hujjatlar Kubernetesda autentifikatsiya haqida.

Avtorizatsiya

Standart avtorizatsiya qilingan hisob klasterda ishlash huquqiga ega emas. Ruxsat berish uchun Kubernetes avtorizatsiya mexanizmini amalga oshiradi.

1.6 versiyasidan oldin Kubernetes avtorizatsiya turidan foydalangan ABAC (Atributga asoslangan kirishni boshqarish). Bu haqda batafsil ma'lumotni sahifada topishingiz mumkin rasmiy hujjatlar. Ushbu yondashuv hozirda eskirgan deb hisoblanadi, ammo siz uni boshqa autentifikatsiya turlari bilan bir qatorda ishlatishingiz mumkin.

Klasterga kirish huquqlarini bo'lishning joriy (va yanada moslashuvchan) usuli deyiladi RBAC (Rolga asoslangan kirishni boshqarish). Versiyadan beri barqaror deb e'lon qilingan Kubernetes 1.8. RBAC huquqlar modelini amalga oshiradi, unda aniq ruxsat etilmagan barcha narsalar taqiqlanadi.
RBACni yoqish uchun, parametr bilan Kubernetes api-serverini ishga tushirishingiz kerak --authorization-mode=RBAC. Parametrlar api-server konfiguratsiyasi bilan manifestda o'rnatiladi, ular sukut bo'yicha yo'l bo'ylab joylashgan. /etc/kubernetes/manifests/kube-apiserver.yaml, bo'limda command. Biroq, RBAC sukut bo'yicha allaqachon yoqilgan, shuning uchun siz bu haqda tashvishlanmasligingiz kerak: buni qiymat bilan tekshirishingiz mumkin authorization-mode (yuqorida aytib o'tilgan kube-apiserver.yaml). Aytgancha, uning ma'nolari orasida avtorizatsiyaning boshqa turlari ham bo'lishi mumkin (node, webhook, always allow), lekin biz ularni ko'rib chiqishni material doirasidan tashqarida qoldiramiz.

Aytgancha, biz allaqachon nashr qilganmiz maqola RBAC bilan ishlash tamoyillari va xususiyatlarining etarlicha batafsil tavsifi bilan, shuning uchun men o'zimni asoslar va misollarning qisqacha ro'yxati bilan cheklayman.

Quyidagi API ob'ektlari RBAC orqali Kubernetes-ga kirishni boshqarish uchun ishlatiladi:

• Role и ClusterRole - kirish huquqlarini tavsiflash uchun xizmat qiluvchi rollar:
• Role nomlar maydonidagi huquqlarni tavsiflash imkonini beradi;
• ClusterRole - klaster ichida, shu jumladan klasterga xos ob'ektlar, masalan, tugunlar, manba bo'lmagan URL manzillari (ya'ni Kubernetes resurslariga aloqador bo'lmagan - masalan, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - bog'lash uchun ishlatiladi Role и ClusterRole foydalanuvchi, foydalanuvchilar guruhi yoki ServiceAccount uchun.

Role va RoleBinding ob'ektlari nomlar maydoni bilan cheklangan, ya'ni. bir xil nom maydoni ichida bo'lishi kerak. Biroq, RoleBinding ClusterRole-ga murojaat qilishi mumkin, bu sizga umumiy ruxsatlar to'plamini yaratish va ular yordamida kirishni boshqarish imkonini beradi.

Rollar quyidagi qoidalar to'plamidan foydalangan holda huquqlarni tavsiflaydi:

• API guruhlari - qarang rasmiy hujjatlar apiGroups va chiqish orqali kubectl api-resources;
• manbalar (Resurslar: pod, namespace, deployment va h.k.);
• Fe'llar (fe'llar: set, update va h.k.).
• manba nomlari (resourceNames) - ushbu turdagi barcha manbalarga emas, balki ma'lum bir manbaga kirishni ta'minlash kerak bo'lgan holatlar uchun.

Kubernetes-da avtorizatsiyaning batafsil tahlilini sahifada topish mumkin rasmiy hujjatlar. Buning o'rniga (aniqrog'i, bunga qo'shimcha ravishda) men uning ishini ko'rsatadigan misollar keltiraman.

RBAC ob'ektlariga misollar

Oddiy Role, bu sizga podkastlarning ro'yxati va holatini olish va ularni nomlar maydonida kuzatish imkonini beradi 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"]

misol ClusterRole, bu sizga podkastlar roʻyxati va holatini olish va ularni klaster boʻylab kuzatish imkonini beradi:

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

misol RoleBinding, bu foydalanuvchiga ruxsat beradi mynewuser nomlar maydonida "o'qing" pods 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

Voqealar auditi

Sxematik ravishda Kubernetes arxitekturasini quyidagicha ifodalash mumkin:

So'rovlarni qayta ishlash uchun mas'ul bo'lgan asosiy Kubernetes komponenti api-server. Klasterdagi barcha operatsiyalar u orqali o'tadi. Ushbu ichki mexanizmlar haqida ko'proq maqolada o'qishingiz mumkin "Kubernetesda kubectl ishga tushirilganda nima sodir bo'ladi?".

Tizim auditi Kubernetes-da sukut bo'yicha o'chirilgan qiziqarli xususiyatdir. Bu sizga barcha qo'ng'iroqlarni Kubernetes API-ga kiritish imkonini beradi. Siz taxmin qilganingizdek, klaster holatini kuzatish va o'zgartirish bilan bog'liq barcha harakatlar ushbu API orqali amalga oshiriladi. Uning imkoniyatlarining yaxshi tavsifini (odatdagidek) topish mumkin rasmiy hujjatlar K8s. Keyinchalik mavzuni soddaroq tilda taqdim etishga harakat qilaman.

Va shunday qilib, auditni faollashtirish uchun, biz uchta kerakli parametrni api-serverdagi konteynerga o'tkazishimiz kerak, ular quyida batafsil tavsiflanadi:

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

Ushbu uchta zarur parametrga qo'shimcha ravishda, audit bilan bog'liq ko'plab qo'shimcha sozlamalar mavjud: jurnalni aylantirishdan veb-huk tavsiflarigacha. Jurnalni aylantirish parametrlariga misol:

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

Ammo biz ular haqida batafsil to'xtalmaymiz - siz barcha tafsilotlarni topishingiz mumkin kube-apiserver hujjatlari.

Yuqorida aytib o'tilganidek, barcha parametrlar api-server konfiguratsiyasi bilan manifestda o'rnatiladi (sukut bo'yicha /etc/kubernetes/manifests/kube-apiserver.yaml), bo'limda command. Keling, 3 ta kerakli parametrga qaytaylik va ularni tahlil qilamiz:

1. audit-policy-file — audit siyosatini tavsiflovchi YAML fayliga yo'l. Biz uning mazmuniga keyinroq qaytamiz, ammo hozircha shuni ta'kidlaymanki, fayl api-server jarayoni tomonidan o'qilishi kerak. Shuning uchun uni konteyner ichiga o'rnatish kerak, buning uchun siz konfiguratsiyaning tegishli bo'limlariga quyidagi kodni qo'shishingiz mumkin:

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

2. audit-log-path — jurnal fayliga yo'l. Yo'l api-server jarayoni uchun ham ochiq bo'lishi kerak, shuning uchun biz uning o'rnatilishini xuddi shunday tasvirlaymiz:

     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 — audit jurnali formati. Asl qiymati json, lekin eski matn formati ham mavjud (legacy).

Audit siyosati

Endi ro'yxatga olish siyosatini tavsiflovchi yuqorida ko'rsatilgan fayl haqida. Audit siyosatining birinchi tushunchasi level, ro'yxatga olish darajasi. Ular quyidagichadir:

• None - jurnalga kirmang;
• Metadata — jurnal soʻrovi metamaʼlumotlari: foydalanuvchi, soʻrov vaqti, maqsadli resurs (pod, nomlar maydoni va boshqalar), harakat turi (feʼl) va boshqalar;
• Request — jurnalning metamaʼlumotlari va soʻrovning asosiy qismi;
• RequestResponse — jurnalning metamaʼlumotlari, soʻrov tanasi va javob organi.

Oxirgi ikki daraja (Request и RequestResponse) resurslarga kira olmagan so‘rovlarni qayd qilmang (resurslar bo‘lmagan URL manzillariga kirish).

Shuningdek, barcha so'rovlar qabul qilinadi bir necha bosqich:

• RequestReceived — so'rov protsessor tomonidan qabul qilingan va protsessorlar zanjiri bo'ylab hali uzatilmagan bosqich;
• ResponseStarted — javob sarlavhalari yuboriladi, lekin javob tanasi yuborilishidan oldin. Uzoq davom etgan so'rovlar uchun yaratilgan (masalan, watch);
• ResponseComplete — javob organi yuborilgan, boshqa maʼlumot yuborilmaydi;
• Panic — hodisalar g'ayritabiiy holat aniqlanganda hosil bo'ladi.

Foydalanishingiz mumkin bo'lgan har qanday qadamni o'tkazib yuborish uchun omitStages.

Siyosat faylida biz turli xil jurnal darajalariga ega bo'lgan bir nechta bo'limlarni tasvirlashimiz mumkin. Siyosat tavsifida topilgan birinchi mos keladigan qoida qo'llaniladi.

Kubelet demoni api-server konfiguratsiyasi bilan manifestdagi o'zgarishlarni kuzatib boradi va agar ular aniqlansa, konteynerni api-server bilan qayta ishga tushiradi. Ammo muhim tafsilot bor: siyosat faylidagi o'zgarishlar u tomonidan e'tiborga olinmaydi. Siyosat fayliga o'zgartirishlar kiritilgandan so'ng, api-serverni qo'lda qayta ishga tushirishingiz kerak bo'ladi. Api-server sifatida ishga tushirilganligi sababli statik pod, jamoa kubectl delete uni qayta ishga tushirishga olib kelmaydi. Buni qo'lda qilishingiz kerak bo'ladi docker stop audit siyosati o'zgartirilgan kube-masterlarda:

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

Auditni yoqishda buni yodda tutish kerak kube-apiserverdagi yuk ortadi. Xususan, so'rov kontekstini saqlash uchun xotira sarfi ortadi. Jurnalga yozish faqat javob sarlavhasi yuborilgandan keyin boshlanadi. Yuk, shuningdek, audit siyosati konfiguratsiyasiga bog'liq.

Siyosatlarga misollar

Keling, misollar yordamida siyosat fayllarining tuzilishini ko'rib chiqaylik.

Mana oddiy fayl policyhamma narsani darajada qayd qilish Metadata:

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

Siyosatda siz foydalanuvchilar ro'yxatini belgilashingiz mumkin (Users и ServiceAccounts) va foydalanuvchilar guruhlari. Misol uchun, biz tizim foydalanuvchilarini e'tiborsiz qoldiramiz, ammo qolgan hamma narsani o'z darajasida qayd qilamiz 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

Maqsadlarni tavsiflash ham mumkin:

• nom maydonlari (namespaces);
• Fe'llar (fe'llar: get, update, delete va boshqalar);
• manbalar (Resurslar, aynan: pod, configmaps va boshqalar) va manba guruhlari (apiGroups).

E'tibor bering! Resurslar va resurs guruhlari (API guruhlari, ya'ni apiGroups), shuningdek ularning klasterda o'rnatilgan versiyalari buyruqlar yordamida olinishi mumkin:

kubectl api-resources
kubectl api-versions

Quyidagi audit siyosati eng yaxshi tajribalarning namoyishi sifatida taqdim etiladi Alibaba Cloud hujjatlari:

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

Audit siyosatining yana bir yaxshi namunasidir GCEda ishlatiladigan profil.

Audit hodisalariga tezda javob berish mumkin vebhukni tasvirlab bering. Ushbu masala bo'limda yoritilgan rasmiy hujjatlar, Men buni ushbu maqola doirasidan tashqarida qoldiraman.

natijalar

Maqolada shaxsiylashtirilgan foydalanuvchi hisoblarini yaratish, ularning huquqlarini ajratish va harakatlarini yozib olish imkonini beruvchi Kubernetes klasterlaridagi asosiy xavfsizlik mexanizmlari haqida umumiy ma'lumot berilgan. Umid qilamanki, nazariy yoki amaliyotda bunday muammolarga duch kelganlar uchun foydali bo'ladi. Shuningdek, men sizga "PS" da berilgan Kubernetesdagi xavfsizlik mavzusiga oid boshqa materiallar ro'yxatini o'qishni tavsiya qilaman - ehtimol ular orasida siz uchun tegishli bo'lgan muammolar bo'yicha kerakli ma'lumotlarni topasiz.

PS

Shuningdek, bizning blogimizda o'qing:

• «33+ Kubernetes xavfsizlik vositalari";
• «Xavfsizlik mutaxassislari uchun Kubernetes tarmoq siyosatiga kirish";
• «Kubernetesda RBAC-ni tushunish";
• «9 Kubernetes xavfsizlikning eng yaxshi amaliyoti";
• «Kubernetes xakerining qurboni bo'lmaslikning 11 usuli".

Manba: www.habr.com