Kubernetes коопсуздук ABC: аутентификация, авторизация, аудит

Эртеби-кечпи, кандайдыр бир системанын иштешинде коопсуздук маселеси келип чыгат: аутентификацияны камсыз кылуу, укуктарды бөлүү, аудит жана башка милдеттер. Kubernetes үчүн мурунтан эле түзүлгөн көптөгөн чечимдер, бул өтө талап кылынган шарттарда да стандарттарга ылайык келүүгө мүмкүндүк берет... Ошол эле материал K8s орнотулган механизмдеринин алкагында ишке ашырылган коопсуздуктун негизги аспектилерине арналган. Биринчиден, бул Kubernetes менен тааныша баштагандар үчүн пайдалуу болот - коопсуздукка байланыштуу маселелерди изилдөө үчүн баштапкы чекит катары.

тастыктоо

Kubernetesте колдонуучулардын эки түрү бар:

• Кызмат эсептери — Kubernetes API тарабынан башкарылуучу эсептер;
• Users — «кадимки» колдонуучулар тышкы, көз карандысыз кызматтар тарабынан башкарылат.

Бул типтердин негизги айырмасы - Кызмат эсептери үчүн Kubernetes API'де атайын объекттер бар (алар мындай деп аталат - ServiceAccounts), алар аттар мейкиндигине жана Жашыруун түрдөгү объекттерде кластерде сакталган авторизация маалыматтарынын топтомуна байланган. Мындай колдонуучулар (Кызмат каттоо эсептери) биринчи кезекте Kubernetes кластеринде иштеген процесстердин Kubernetes API'сине кирүү укуктарын башкарууга арналган.

Жөнөкөй колдонуучуларда Kubernetes API'де жазуулар жок: алар тышкы механизмдер менен башкарылууга тийиш. Алар кластерден тышкары жашаган адамдарга же процесстерге арналган.

Ар бир 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 ачкычтарын колдонуу менен сертификат суроо-талабын иштеп чыгуу, колдонуучунун сертификатын алуу (сертификат алуу үчүн сиз демейки боюнча төмөнкү жерде жайгашкан 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 документтеринде сертификаттар менен иштөө боюнча;
• Bitnamiден жакшы макала, анда сертификаттар маселеси практикалык көз караштан козголот.
• жалпы документтер Kubernetes ичинде аутентификация боюнча.

укук берүү

Демейки ыйгарым укуктуу эсеп кластерде иштөөгө укуктарга ээ эмес. Уруксаттарды берүү үчүн, Kubernetes авторизациялоо механизмин ишке ашырат.

1.6 версиясына чейин Kubernetes аттуу авторизация түрүн колдонгон 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 аркылуу Kubernetes'те кирүү мүмкүнчүлүгүн көзөмөлдөө үчүн төмөнкү API объекттери колдонулат:

• 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) - бул түрдөгү бардык ресурстарга эмес, белгилүү бир ресурска кирүү мүмкүнчүлүгүн камсыз кылуу керек болгон учурда.

Kubernetes авторизациясынын кеңири талдоосун баракчадан тапса болот расмий документтер. Анын ордуна (же тагыраак айтканда, буга кошумча), мен анын ишин чагылдырган мисалдарды келтирем.

RBAC объекттеринин мисалдары

жөнөкөй Role, бул сизге подкасттардын тизмесин жана статусун алууга жана аларды аттар мейкиндигинде көзөмөлдөөгө мүмкүндүк берет 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 аттар мейкиндигинде "окуу" бөлүмдөрү 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 архитектурасын төмөнкүчө чагылдырууга болот:

Сурамдарды иштетүү үчүн жооптуу негизги 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.

Саясат файлында биз ар кандай каттоо деңгээли бар бир нече бөлүмдөрдү сүрөттөй алабыз. Саясаттын сүрөттөмөсүндө табылган биринчи дал келген эреже колдонулат.

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"те берилген Kubernetesтеги коопсуздук темасы боюнча башка материалдардын тизмесин окууну сунуштайм - балким, алардын арасында сиз үчүн тиешелүү болгон көйгөйлөр боюнча керектүү маалыматтарды таба аласыз.

PS

Биздин блогдон дагы окуңуз:

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

Source: www.habr.com