Кубернетес дэх аюулгүй байдлын ABC: Баталгаажуулалт, зөвшөөрөл, аудит

Эрт орой хэзээ нэгэн цагт аливаа системийн үйл ажиллагаанд аюулгүй байдлын асуудал гарч ирдэг: баталгаажуулалт, эрхийг тусгаарлах, аудит хийх болон бусад ажлуудыг хийх. Kubernetes-д зориулж аль хэдийн үүсгэсэн олон шийдэл, энэ нь танд маш их эрэлт хэрэгцээтэй орчинд ч стандартыг дагаж мөрдөх боломжийг олгодог ... Ижил материал нь K8-ийн суурилуулсан механизмд хэрэгжсэн аюулгүй байдлын үндсэн асуудлуудад зориулагдсан болно. Юуны өмнө энэ нь Кубернетестэй танилцаж эхэлж буй хүмүүст ашигтай байх болно - аюулгүй байдалтай холбоотой асуудлыг судлах эхлэлийн цэг.

Гэрчлэлт

Kubernetes-д хоёр төрлийн хэрэглэгчид байдаг:

• Үйлчилгээний дансууд — Kubernetes API-ээр удирддаг дансууд;
• хэрэглэгчид - "хэвийн" хэрэглэгчид гадны бие даасан үйлчилгээгээр удирддаг.

Эдгээр төрлүүдийн гол ялгаа нь Үйлчилгээний дансны хувьд Kubernetes API-д тусгай объектууд байдаг (тэдгээрийг ингэж нэрлэдэг - ServiceAccounts), нууц төрлийн объектуудын кластерт хадгалагдсан нэрийн орон зай болон зөвшөөрлийн мэдээллийн багцтай холбогдсон байна. Ийм хэрэглэгчид (Үйлчилгээний бүртгэлүүд) нь үндсэндээ Kubernetes кластерт ажиллаж байгаа процессуудын Kubernetes API-д хандах эрхийг удирдах зорилготой юм.

Энгийн хэрэглэгчдэд Kubernetes API-д оруулга байхгүй: тэдгээрийг гадны механизмаар удирдах ёстой. Эдгээр нь кластераас гадуур амьдардаг хүмүүс эсвэл процессуудад зориулагдсан.

API хүсэлт бүр нь Үйлчилгээний бүртгэл, Хэрэглэгчтэй холбоотой эсвэл нэргүй гэж тооцогддог.

Хэрэглэгчийн баталгаажуулалтын өгөгдөлд дараахь зүйлс орно.

• Хэрэглэгчийн нэр — хэрэглэгчийн нэр (үсгийн том үсгийн мэдрэмжтэй!);
• UID - "хэрэглэгчийн нэрээс илүү тууштай, өвөрмөц" машинд уншигдахуйц хэрэглэгчийн таних тэмдэгт мөр;
• Бүлэг — хэрэглэгчийн харьяалагддаг бүлгүүдийн жагсаалт;
• Нэмэлт - зөвшөөрлийн механизмаар ашиглаж болох нэмэлт талбарууд.

Kubernetes олон тооны баталгаажуулалтын механизмыг ашиглаж болно: X509 гэрчилгээ, Bearer жетон, баталгаажуулах прокси, HTTP үндсэн баталгаажуулалт. Эдгээр механизмуудыг ашигласнаар та олон тооны зөвшөөрлийн схемийг хэрэгжүүлж болно: нууц үг бүхий статик файлаас OpenID OAuth2 хүртэл.

Үүнээс гадна хэд хэдэн зөвшөөрлийн схемийг нэгэн зэрэг ашиглах боломжтой. Өгөгдмөлөөр, кластер дараахыг ашигладаг:

• үйлчилгээний дансны токенууд - Үйлчилгээний дансанд;
• X509 - Хэрэглэгчдэд зориулсан.

Үйлчилгээний дансыг удирдах тухай асуулт нь энэ нийтлэлийн хамрах хүрээнээс гадуур боловч энэ асуудалтай илүү дэлгэрэнгүй танилцахыг хүсч буй хүмүүст би дараахаас эхлэхийг зөвлөж байна. албан ёсны баримт бичгийн хуудас. X509 гэрчилгээ хэрхэн ажилладаг тухай асуудлыг бид нарийвчлан авч үзэх болно.

Хэрэглэгчдэд зориулсан гэрчилгээ (X.509)

Сертификаттай ажиллах сонгодог арга нь дараахь зүйлийг агуулна.

• түлхүүр үе:

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

• гэрчилгээний хүсэлт гаргах:

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

• Kubernetes кластерын CA түлхүүрүүдийг ашиглан гэрчилгээний хүсэлтийг боловсруулах, хэрэглэгчийн гэрчилгээ авах (сертификат авахын тулд та Kubernetes кластерын CA түлхүүрт хандах эрхтэй бүртгэлийг ашиглах ёстой. /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

• тохиргооны файл үүсгэх:
  • кластерын тайлбар (тодорхой кластер суулгахад зориулсан CA гэрчилгээний файлын хаяг, байршлыг зааж өгнө үү):

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

  • эсвэл яаж үгүйсанал болгож буй сонголт - та үндсэн гэрчилгээг зааж өгөх шаардлагагүй (дараа нь kubectl кластерын api серверийн зөв эсэхийг шалгахгүй):

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

  • тохиргооны файлд хэрэглэгч нэмэх:

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

  • контекст нэмэх:

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

  • өгөгдмөл контекст даалгавар:

    kubectl config use-context mynewuser-context

Дээрх залруулга хийсний дараа файлд .kube/config Ийм тохиргоо үүснэ:

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

Бүртгэлүүд болон серверүүдийн хооронд тохиргоог шилжүүлэхэд хялбар болгохын тулд дараах түлхүүрүүдийн утгыг засах нь зүйтэй.

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

Үүнийг хийхийн тулд та тэдгээрт заасан файлуудыг base64 ашиглан кодлож, тохиргоонд бүртгүүлж, товчлуурын нэрэнд дагавар нэмж болно. -data, өөрөөр хэлбэл хүлээн авсан certificate-authority-data болон үүнтэй төстэй зүйлс.

kubeadm-тай гэрчилгээ

Гаргасантай хамт Кубернет 1.15 дахь дэмжлэгийн альфа хувилбарын ачаар гэрчилгээтэй ажиллах нь илүү хялбар болсон kubeadm хэрэгсэл. Жишээлбэл, хэрэглэгчийн түлхүүрээр тохиргооны файл үүсгэх нь одоо иймэрхүү харагдаж болно:

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

NB: Шаардлагатай сурталчилгааны хаяг өгөгдмөл байдлаар байрлах api-серверийн тохиргооноос олж болно /etc/kubernetes/manifests/kube-apiserver.yaml.

Үүссэн тохиргоог stdout руу гаргах болно. Үүнийг хадгалах хэрэгтэй ~/.kube/config хэрэглэгчийн бүртгэл эсвэл орчны хувьсагчд заасан файл руу KUBECONFIG.

Гүн ухах

Илүү нарийвчлан тайлбарласан асуудлуудыг ойлгохыг хүсч буй хүмүүст:

• тусдаа зүйл Kubernetes-ийн албан ёсны баримт бичигт гэрчилгээтэй ажиллах;
• Битнамигийн сайн нийтлэл, үүнд гэрчилгээний асуудлыг практик талаас нь хөндсөн.
• ерөнхий баримт бичиг Kubernetes дахь нэвтрэлт танилт дээр.

Зөвшөөрөл

Анхдагч эрх бүхий данс нь кластер дээр ажиллах эрхгүй. Зөвшөөрөл олгохын тулд Кубернетес зөвшөөрлийн механизмыг хэрэгжүүлдэг.

1.6 хувилбараас өмнө Кубернетес зөвшөөрлийн төрлийг ашигладаг байсан ABAC (Атрибут дээр суурилсан хандалтын хяналт). Энэ талаархи дэлгэрэнгүй мэдээллийг эндээс авах боломжтой албан ёсны баримт бичиг. Энэ аргыг одоогоор хуучин гэж үзэж байгаа ч та үүнийг бусад баталгаажуулалтын төрлүүдийн хамт ашиглаж болно.

Кластерт хандах эрхийг хуваах одоогийн (болон илүү уян хатан) аргыг нэрлэдэг RBAC (Дүрд суурилсан хандалтын хяналт). Энэ хувилбараас хойш тогтвортой гэж зарласан Кубернет 1.8. RBAC нь тодорхой зөвшөөрөөгүй бүх зүйлийг хориглодог эрхийн загварыг хэрэгжүүлдэг.
RBAC-г идэвхжүүлэхийн тулд, та Kubernetes api-серверийг параметрээр эхлүүлэх хэрэгтэй --authorization-mode=RBAC. Параметрүүд нь анхдагчаар зам дагуу байрладаг api-серверийн тохиргоотой манифестэд тохируулагдсан болно. /etc/kubernetes/manifests/kube-apiserver.yaml, хэсэгт command. Гэсэн хэдий ч, RBAC нь анхдагчаар аль хэдийн идэвхжсэн тул та санаа зовох хэрэггүй: та үүнийг утгаараа баталгаажуулж болно. authorization-mode (аль хэдийн дурдсан хэсэгт kube-apiserver.yaml). Дашрамд хэлэхэд, түүний утгын дунд бусад төрлийн зөвшөөрөл байж болно (node, webhook, always allow), гэхдээ бид материалын хамрах хүрээнээс гадуур тэдний саналыг үлдээх болно.

Дашрамд хэлэхэд бид аль хэдийн нийтэлсэн нийтлэл RBAC-тай ажиллах зарчим, онцлогуудын талаар нэлээд нарийвчилсан тайлбартай тул цаашид би үндсэн ойлголт, жишээнүүдийн товч жагсаалтаар хязгаарлагдах болно.

RBAC-ээр дамжуулан Кубернетес дэх хандалтыг хянахын тулд дараах API нэгжүүдийг ашигладаг:

• Role и ClusterRole - хандалтын эрхийг тодорхойлоход үйлчилдэг үүрэг:
• Role нэрийн орон зайн доторх эрхийг дүрслэх боломжийг танд олгоно;
• ClusterRole - кластер дотор, үүнд зангилаа, нөөцийн бус url зэрэг кластерт хамаарах объектууд (жишээ нь, Kubernetes нөөцтэй холбоогүй - жишээлбэл, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - холбоход ашигладаг Role и ClusterRole хэрэглэгч, хэрэглэгчийн бүлэг эсвэл ServiceAccount руу.

Role and RoleBinding нэгжүүд нь нэрийн орон зайгаар хязгаарлагддаг, i.e. ижил нэрийн зайд байх ёстой. Гэсэн хэдий ч, RoleBinding нь ClusterRole-д лавлаж болох бөгөөд энэ нь танд ерөнхий зөвшөөрлийн багц үүсгэж, тэдгээрийг ашиглан хандалтыг хянах боломжийг олгодог.

Үүрэг нь дараахь зүйлийг агуулсан дүрмийн багцыг ашиглан эрхийг тодорхойлдог.

• API бүлгүүд - үзнэ үү албан ёсны баримт бичиг apiGroups болон гаралтаар kubectl api-resources;
• нөөц (Нөөц: pod, namespace, deployment гэх мэт.);
• Үйл үг (үйл үг: set, update гэх мэт.).
• нөөцийн нэрс (resourceNames) - энэ төрлийн бүх нөөцөд биш, харин тодорхой нөөцөд хандах шаардлагатай тохиолдолд.

Kubernetes дахь зөвшөөрлийн илүү нарийвчилсан дүн шинжилгээг хуудаснаас олж болно албан ёсны баримт бичиг. Үүний оронд (эсвэл үүнээс гадна) би түүний ажлыг харуулсан жишээнүүдийг өгөх болно.

RBAC байгууллагуудын жишээ

Энгийн Role, энэ нь pods-ийн жагсаалт, статусыг авч, нэрийн талбарт хянах боломжийг олгодог 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"]

Жишээ нь: ClusterRole, энэ нь танд хонхорцогуудын жагсаалт, статусыг авч кластер даяар хянах боломжийг олгодог:

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

Жишээ нь: RoleBinding, энэ нь хэрэглэгчийг зөвшөөрдөг mynewuser нэрийн талбар дахь "унших" 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

Үйл явдлын аудит

Схемийн хувьд Кубернетес архитектурыг дараах байдлаар илэрхийлж болно.

Хүсэлтийг боловсруулах үүрэгтэй Kubernetes-ийн гол бүрэлдэхүүн хэсэг нь api сервер. Кластер дээрх бүх үйлдлүүд түүгээр дамждаг. Та эдгээр дотоод механизмын талаар дэлгэрэнгүйг нийтлэлээс уншиж болно.Та kubectl ажиллуулах үед Kubernetes-д юу тохиолддог вэ?".

Системийн аудит нь Kubernetes-ийн сонирхолтой функц бөгөөд анхдагчаар идэвхгүй байдаг. Энэ нь танд бүх дуудлагыг Kubernetes API руу бүртгэх боломжийг олгоно. Таны таамаглаж байгаагаар кластерийн төлөвийг хянах, өөрчлөхтэй холбоотой бүх үйлдлүүд энэ API-ээр дамжин хийгддэг. Түүний чадварын талаар сайн тайлбарыг (ердийнх шиг) эндээс олж болно албан ёсны баримт бичиг K8s. Дараа нь би сэдвийг илүү энгийн хэлээр харуулахыг хичээх болно.

Тэгэхээр аудитыг идэвхжүүлэх, бид api-сервер дэх контейнерт шаардлагатай гурван параметрийг дамжуулах шаардлагатай бөгөөд эдгээрийг доор дэлгэрэнгүй тайлбарласан болно.

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

Эдгээр гурван шаардлагатай параметрээс гадна аудиттай холбоотой олон нэмэлт тохиргоонууд байдаг: лог эргүүлэхээс эхлээд вэб дэгээний тайлбар хүртэл. Бүртгэлийн эргэлтийн параметрүүдийн жишээ:

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

Гэхдээ бид тэдгээрийн талаар илүү дэлгэрэнгүй ярихгүй - та бүх мэдээллийг эндээс олж болно kube-apiserver баримт бичиг.

Өмнө дурьдсанчлан, бүх параметрүүдийг api-серверийн тохиргоотой манифестт тохируулсан болно (анхдагчаар) /etc/kubernetes/manifests/kube-apiserver.yaml), хэсэгт command. Шаардлагатай 3 параметр рүү буцаж очоод дүн шинжилгээ хийцгээе.

1. audit-policy-file — аудитын бодлогыг тодорхойлсон YAML файлын зам. Бид дараа нь түүний агуулга руу буцах болно, гэхдээ одоогоор би файлыг api-серверийн процессоор унших боломжтой гэдгийг тэмдэглэх болно. Тиймээс үүнийг контейнер дотор суулгах шаардлагатай бөгөөд үүний тулд та дараах кодыг тохиргооны тохирох хэсгүүдэд нэмж болно.

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

2. audit-log-path — бүртгэлийн файл руу орох зам. Зам нь мөн api-серверийн процесст хандах боломжтой байх ёстой, тиймээс бид түүний холболтыг ижил аргаар тайлбарлав:

     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 - аудитын бүртгэлийн формат. Анхдагч нь json, гэхдээ хуучин текст формат бас боломжтой (legacy).

Аудитын бодлого

Одоо бүртгэлийн бодлогыг тайлбарласан дурдсан файлын тухай. Аудитын бодлогын анхны ойлголт нь level, бүртгэлийн түвшин. Тэдгээр нь дараах байдалтай байна.

• None - бүртгэл хийхгүй байх;
• Metadata — бүртгэлийн хүсэлтийн мета өгөгдөл: хэрэглэгч, хүсэлтийн цаг, зорилтот нөөц (под, нэрийн орон зай гэх мэт), үйлдлийн төрөл (үйл үг) гэх мэт;
• Request — бүртгэлийн мета өгөгдөл болон хүсэлтийн үндсэн хэсэг;
• RequestResponse — бүртгэлийн мета өгөгдөл, хүсэлтийн хэсэг, хариу өгөх хэсэг.

Сүүлийн хоёр түвшин (Request и RequestResponse) нөөцөд хандаагүй хүсэлтийг бүү бүртгээрэй (нөөцийн бус url гэж нэрлэгддэг хандалт).

Мөн бүх хүсэлтүүд дамждаг хэд хэдэн үе шат:

• RequestReceived - хүсэлтийг процессор хүлээн авсан бөгөөд процессорын гинжин хэлхээний дагуу хараахан дамжуулагдаагүй үе шат;
• ResponseStarted - хариултын толгойг илгээсэн боловч хариу илгээхээс өмнө. Урт хугацааны асуулгад зориулж үүсгэсэн (жишээлбэл, watch);
• ResponseComplete - хариу илгээсэн байгууллага, өөр мэдээлэл илгээхгүй;
• Panic - хэвийн бус нөхцөл байдал илэрсэн үед үйл явдлууд үүсдэг.

Та ашиглаж болох аливаа алхамыг алгасах omitStages.

Бодлогын файлд бид янз бүрийн бүртгэлийн түвшний хэд хэдэн хэсгийг дүрсэлж болно. Бодлогын тайлбараас олдсон эхний тохирох дүрмийг хэрэгжүүлнэ.

Кубелет дэмон нь манифест дахь өөрчлөлтийг api-серверийн тохиргоогоор хянадаг бөгөөд хэрэв илэрсэн бол api-серверээр контейнерийг дахин эхлүүлнэ. Гэхдээ нэг чухал зүйл байна: бодлогын файлын өөрчлөлтийг үл тоомсорлох болно. Бодлогын файлд өөрчлөлт оруулсны дараа та api серверийг гараар дахин эхлүүлэх шаардлагатай болно. api-серверийг эхлүүлсэн тул статик подволк, баг kubectl delete дахин эхлүүлэхэд хүргэхгүй. Та үүнийг гараар хийх хэрэгтэй болно docker stop Аудитын бодлого өөрчлөгдсөн kube-мастерууд дээр:

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

Аудитыг идэвхжүүлэхдээ үүнийг санах нь чухал kube-apiserver дээрх ачаалал нэмэгддэг. Ялангуяа хүсэлтийн агуулгыг хадгалах санах ойн хэрэглээ нэмэгддэг. Зөвхөн хариултын толгойг илгээсний дараа л бүртгэл эхэлнэ. Ачаалал нь аудитын бодлогын тохиргооноос бас хамаарна.

Бодлогын жишээ

Бодлогын файлуудын бүтцийг жишээн дээр авч үзье.

Энд энгийн файл байна policyбүх зүйлийг түвшинд бүртгэх Metadata:

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

Бодлогод та хэрэглэгчдийн жагсаалтыг зааж өгч болно (Users и ServiceAccounts) болон хэрэглэгчийн бүлгүүд. Жишээлбэл, бид системийн хэрэглэгчдийг ингэж үл тоомсорлож, бусад бүх зүйлийг түвшинд бүртгэдэг 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

Мөн зорилтуудыг дараахь байдлаар тодорхойлж болно.

• нэрийн орон зай (namespaces);
• Үйл үг (үйл үг: get, update, delete мөн бусад);
• нөөц (Нөөц, тухайлбал: pod, configmaps гэх мэт) болон нөөцийн бүлгүүд (apiGroups).

Анхаар! Кластерт суулгасан нөөц ба нөөцийн бүлгүүд (API бүлгүүд, жишээ нь apiGroups), түүнчлэн тэдгээрийн хувилбаруудыг дараах тушаалуудыг ашиглан олж авч болно.

kubectl api-resources
kubectl api-versions

Дараах аудитын бодлогыг шилдэг туршлагын жишээ болгон үзүүлэв 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

Аудитын бодлогын өөр нэг сайн жишээ GCE-д ашигласан профайл.

Аудитын үйл явдалд хурдан хариу өгөх боломжтой вэб дэгээг тайлбарлах. Энэ асуудалд тусгагдсан болно албан ёсны баримт бичиг, Би үүнийг энэ нийтлэлийн хамрах хүрээнээс гадуур үлдээх болно.

Үр дүн

Энэхүү нийтлэл нь Кубернетес кластеруудын аюулгүй байдлын үндсэн механизмуудын тоймыг өгдөг бөгөөд энэ нь танд хувийн хэрэглэгчийн бүртгэл үүсгэх, тэдний эрхийг тусгаарлах, үйлдлийг нь бүртгэх боломжийг олгодог. Онолын хувьд ч, практикийн хувьд ч ийм асуудалтай тулгарсан хүмүүст хэрэг болно гэж найдаж байна. Би мөн "PS" дээр өгөгдсөн Кубернетес дэх аюулгүй байдлын сэдвээр бусад материалын жагсаалтыг уншихыг зөвлөж байна - магадгүй тэдний дундаас танд хамааралтай асуудлын талаар шаардлагатай дэлгэрэнгүй мэдээллийг олж мэдэх болно.

PS

Мөн манай блог дээрээс уншина уу:

• «33+ Kubernetes аюулгүй байдлын хэрэгсэл";
• «Аюулгүй байдлын мэргэжилтнүүдэд зориулсан Kubernetes сүлжээний бодлогын талаархи танилцуулга";
• «Кубернетес дэх RBAC-ийн тухай ойлголт";
• «Kubernetes аюулгүй байдлын шилдэг 9 туршлага";
• «Kubernetes-ийн хакердалтын хохирогч болох (биш) 11 арга".

Эх сурвалж: www.habr.com