ABC Амният дар Кубернетес: Аутентификатсия, Авторизатсия, Аудит

Дер ё зуд, дар кори ҳама гуна система, масъалаи амният ба миён меояд: таъмини аутентификатсия, ҷудокунии ҳуқуқҳо, аудит ва дигар вазифаҳо. Аллакай барои Kubernetes офарида шудааст ҳалли бисёр, ки ба шумо имкон медиҳад, ки ҳатто дар муҳитҳои хеле серталаб риояи стандартҳоро ба даст оред... Худи ҳамон мавод ба ҷанбаҳои асосии амният бахшида шудааст, ки дар механизмҳои дарунсохташудаи K8s амалӣ карда мешаванд. Пеш аз ҳама, он барои онҳое, ки бо Кубернетес шинос шуданро оғоз мекунанд, муфид хоҳад буд - ҳамчун нуқтаи ибтидоӣ барои омӯзиши масъалаҳои марбут ба амният.

Сертификатсия

Дар Kubernetes ду намуди корбарон мавҷуданд:

• Ҳисобҳои хидматрасонӣ — ҳисобҳое, ки аз ҷониби API Kubernetes идора карда мешаванд;
• истифодабарандагон — корбарони "муқаррарӣ" аз ҷониби хидматҳои беруна ва мустақил идора карда мешаванд.

Фарқи асосии байни ин намудҳо дар он аст, ки барои ҳисобҳои хидматӣ дар API Kubernetes объектҳои махсус мавҷуданд (онҳоро чунин меноманд - ServiceAccounts), ки ба фазои ном ва маҷмӯи маълумоти иҷозатдодашуда, ки дар кластер дар объектҳои навъи Сиррҳо нигоҳ дошта мешаванд, алоқаманданд. Чунин корбарон (Ҳисобҳои хидматӣ) пеш аз ҳама барои идора кардани ҳуқуқҳои дастрасӣ ба API-и Kubernetes равандҳои дар кластери Kubernetes коркунанда пешбинӣ шудаанд.

Корбарони оддӣ дар API Kubernetes вуруд надоранд: онҳо бояд тавассути механизмҳои беруна идора карда шаванд. Онҳо барои одамон ё равандҳое пешбинӣ шудаанд, ки берун аз кластер зиндагӣ мекунанд.

Ҳар як дархости API бо ҳисоби хидматрасонӣ, корбар алоқаманд аст ё беном ҳисобида мешавад.

Маълумоти аутентификатсияи корбар дар бар мегирад:

• Логин — номи корбар (ҳассос ба ҳарф!);
• UID - сатри мушаххаси корбар, ки аз ҷониби мошин хондашаванда "нисбат ба номи корбар мувофиқтар ва беназиртар аст";
• Гурӯҳҳои — номгӯи гурӯҳҳое, ки корбар ба онҳо тааллуқ дорад;
• иловагӣ — майдонҳои иловагӣ, ки онҳоро механизми иҷозатдиҳӣ истифода бурдан мумкин аст.

Kubernetes метавонад шумораи зиёди механизмҳои аутентификатсияро истифода барад: сертификатҳои X509, аломатҳои баранда, прокси тасдиқкунанда, HTTP Basic Auth. Бо истифода аз ин механизмҳо, шумо метавонед шумораи зиёди схемаҳои авторизатсияро амалӣ кунед: аз файли статикӣ бо паролҳо то OpenID OAuth2.

Илова бар ин, дар як вақт якчанд схемаҳои иҷозатро истифода бурдан мумкин аст. Бо нобаёнӣ, кластер истифода мебарад:

• аломатҳои ҳисоби хидматӣ - барои ҳисобҳои хидматӣ;
• X509 - барои корбарон.

Савол дар бораи идоракунии ServiceAccounts аз доираи ин мақола берун аст, аммо барои онҳое, ки мехоҳанд бо ин масъала муфассалтар шинос шаванд, ман тавсия медиҳам, ки аз саҳифаҳои ҳуҷҷатҳои расмӣ. Мо масъалаи чӣ гуна кор кардани сертификатҳои 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, гирифтани шаҳодатномаи корбар (барои гирифтани шаҳодатнома, шумо бояд ҳисоберо истифода баред, ки ба калиди кластери CA 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;
• мақолаи хуб аз Bitnami, ки дар он ба масъалаи шаходатномахо аз нуктаи назари амалй дахл карда мешавад.
• ҳуҷҷатҳои умумӣ оид ба аутентификатсия дар Кубернетес.

Иҷозатнома

Ҳисоби ваколатдори пешфарз барои кор кардан дар кластер ҳуқуқ надорад. Барои додани иҷозатҳо, Kubernetes механизми авторизатсияро амалӣ мекунад.

Қабл аз версияи 1.6, Kubernetes як навъи авторизатсияро истифода бурд ABAC (Назорати дастрасӣ ба атрибутӣ). Тафсилотро дар ин бора пайдо кардан мумкин аст ҳуҷҷатҳои расмӣ. Ин равиш ҳоло меросӣ ҳисобида мешавад, аммо шумо метавонед онро дар баробари дигар намудҳои аутентификатсия истифода баред.

Роҳи ҷорӣ (ва чандиртар) тақсимоти ҳуқуқҳои дастрасӣ ба кластер номида мешавад РБАК (Назорати дастрасӣ ба нақш). Аз версияи он устувор эълон шудааст Кубернетҳо 1.8. RBAC модели ҳуқуқро амалӣ мекунад, ки дар он ҳама чизе, ки ба таври возеҳ иҷозат дода нашудааст, манъ аст.
Барои фаъол кардани RBAC, шумо бояд api-сервери Kubernetes-ро бо параметр оғоз кунед --authorization-mode=RBAC. Параметрҳо дар манифест бо конфигуратсияи api-сервер муқаррар карда мешаванд, ки ба таври нобаёнӣ дар қад-қади роҳ ҷойгир аст. /etc/kubernetes/manifests/kube-apiserver.yaml, дар бахш command. Бо вуҷуди ин, RBAC аллакай бо нобаёнӣ фаъол аст, бинобар ин, эҳтимол шумо набояд дар ин бора хавотир нашавед: шумо метавонед инро аз рӯи арзиш тафтиш кунед authorization-mode (дар номаи аллакай зикршуда kube-apiserver.yaml). Зимнан, дар байни маъноҳои он метавонад намудҳои дигари иҷозат (node, webhook, always allow), аммо баррасии онҳоро берун аз доираи мавод мегузорем.

Зимнан, мо аллакай нашр кардем мақола бо тавсифи хеле муфассали принсипҳо ва хусусиятҳои кор бо RBAC, аз ин рӯ ман минбаъд бо як рӯйхати мухтасари асосҳо ва мисолҳо маҳдуд мешавам.

Объектҳои зерини API барои назорати дастрасӣ ба Kubernetes тавассути RBAC истифода мешаванд:

• Role и ClusterRole — нақшҳое, ки барои тавсифи ҳуқуқҳои дастрасӣ хизмат мекунанд:
• Role ба шумо имкон медиҳад, ки ҳуқуқҳоро дар фазои ном тасвир кунед;
• ClusterRole - дар дохили кластер, аз ҷумла ба объектҳои хоси кластер ба монанди гиреҳҳо, URL-ҳои ғайриманқул (яъне ба захираҳои Kubernetes алоқаманд нестанд - масалан, /version, /logs, /api*);
• RoleBinding и ClusterRoleBinding - барои бастабандӣ истифода мешавад Role и ClusterRole ба корбар, гурӯҳи корбар ё ServiceAccount.

Объектҳои Role ва RoleBinding бо фазои ном маҳдуданд, яъне. бояд дар як фазои ном бошад. Аммо, RoleBinding метавонад ба ClusterRole истинод кунад, ки ба шумо имкон медиҳад маҷмӯи иҷозатҳои умумӣ эҷод кунед ва дастрасиро бо истифода аз онҳо назорат кунед.

Нақшҳо ҳуқуқҳоро бо истифода аз маҷмӯи қоидаҳо тавсиф мекунанд, ки дар бар мегиранд:

• Гурӯҳҳои API - нигаред ҳуҷҷатҳои расмӣ аз ҷониби apiGroups ва баромад kubectl api-resources;
• захираҳо (Захираҳо: pod, namespace, deployment ва ғайра.);
• Феълҳо (феълҳо: set, update ғайра).
• номҳои манбаъ (resourceNames) - барои ҳолатҳое, ки ба шумо лозим аст, ки дастрасӣ ба як манбаи мушаххасро таъмин кунед, на ба ҳама захираҳои ин намуд.

Таҳлили муфассали иҷозатро дар Кубернетес дар саҳифа пайдо кардан мумкин аст ҳуҷҷатҳои расмӣ. Ба ҷои ин (ё дурусттараш, илова бар ин), ман мисолҳое меорам, ки кори ӯро нишон медиҳанд.

Намунаҳои субъектҳои 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, ки ба шумо имкон медиҳад, ки рӯйхат ва ҳолати pods гиред ва онҳоро дар тамоми кластер назорат кунед:

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

Мисол RoleBinding, ки ба корбар имкон медиҳад mynewuser "хондан" дар фазои номҳо 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 аст, ки бо нобаёнӣ ғайрифаъол аст. Он ба шумо имкон медиҳад, ки ҳама зангҳоро ба API Kubernetes сабт кунед. Тавре ки шумо гумон мекунед, ҳама амалҳои марбут ба назорат ва тағир додани ҳолати кластер тавассути ин 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.

Дар файли сиёсат мо метавонем якчанд бахшҳоро бо сатҳҳои гуногуни сабткунӣ тавсиф кунем. Аввалин қоидаи мувофиқе, ки дар тавсифи сиёсат пайдо шудааст, татбиқ карда мешавад.

Демони kubelet тағиротро дар манифест бо конфигуратсияи api-сервер назорат мекунад ва агар ошкор шавад, контейнерро бо api-сервер аз нав оғоз мекунад. Аммо як ҷузъиёти муҳим вуҷуд дорад: тағирот дар файли сиёсат аз ҷониби он нодида гирифта мешавад. Пас аз ворид кардани тағирот ба файли сиёсат, шумо бояд api-серверро дастӣ аз нав оғоз кунед. Азбаски api-сервер ҳамчун оғоз мешавад қуттии статикӣ, команда kubectl delete боиси аз нав оғоз шудани он нахоҳад шуд. Шумо бояд онро дастӣ иҷро кунед docker stop дар kube-мастер, ки дар он сиёсати аудит тағир дода шудааст:

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

Ҳангоми фаъол кардани аудит, дар хотир доштан муҳим аст, ки бори кубе-аписервер меафзояд. Махсусан, истеъмоли хотира барои нигоҳ доштани контексти дархост меафзояд. Сабти сабт танҳо пас аз фиристодани сарлавҳаи ҷавоб оғоз мешавад. Сарборӣ инчунин аз конфигуратсияи сиёсати аудит вобаста аст.

Намунаҳои сиёсатҳо

Биёед сохтори файлҳои сиёсатро бо истифода аз мисолҳо дида бароем.

Дар ин ҷо як файли оддӣ аст 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 истифодашуда.

Барои зуд вокуниш ба рӯйдодҳои аудиторӣ имконпазир аст вебхукро тавсиф кунед. Ин масъала дар ҳуҷҷатҳои расмӣ, Ман онро берун аз доираи ин мақола мегузорам.

Натиҷаҳо

Дар мақола шарҳи механизмҳои асосии амният дар кластерҳои Kubernetes оварда шудааст, ки ба шумо имкон медиҳанд ҳисобҳои корбарони фардӣ эҷод кунед, ҳуқуқҳои онҳоро ҷудо кунед ва амалҳои онҳоро сабт кунед. Умедворам, ки ин барои онҳое, ки дар назария ва ё амалия бо чунин масъалаҳо рӯ ба рӯ мешаванд, муфид хоҳад буд. Ман инчунин тавсия медиҳам, ки рӯйхати дигар маводҳоро дар мавзӯи амният дар Кубернетес, ки дар "PS" оварда шудааст, хонед - шояд дар байни онҳо шумо тафсилоти заруриро дар бораи мушкилоте, ки ба шумо дахл доранд, пайдо кунед.

PS

Инчунин дар блоги мо хонед:

• «33+ Воситаҳои амнияти Kubernetes»;
• «Муқаддима ба сиёсатҳои шабакаи Kubernetes барои мутахассисони амният»;
• «Фаҳмидани RBAC дар Кубернетес»;
• «9 Таҷрибаи беҳтарин барои амнияти Kubernetes»;
• «11 Роҳҳои (не) шудан қурбонии хаки Kubernetes".

Манбаъ: will.com