{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Vi lagar h\u00e5len i Kubernetes-klustret. Rapport och avskrift fr\u00e5n DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, l\u00f6sningsarkitekt p\u00e5 Southbridge och l\u00e4rare p\u00e5 Slyrm, h\u00f6ll en presentation p\u00e5 DevOpsConf 2019. Denna presentation \u00e4r en del av en av temi f\u00f6rdjupad kurs om Kubernetes \"Slyrm Mega\".<\/p>\n

<\/p>\n

Slyrm Grundl\u00e4ggande: en introduktion till Kubernetes<\/a><\/noindex> \u00e4 skriven i Moskva 18-20 november.
\nSlyrm Mega: vi gr\u00e4ver djupare under huven p\u00e5 Kubernetes<\/a><\/noindex> \u2014 Moskva, 22-24 november.
\nSlyrm Online: b\u00e5da kurserna om Kubernetes<\/a><\/noindex> finns alltid tillg\u00e4nglig.<\/p>\n

\n

\r\n \"Spela\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Under l\u00e4sningen finns transkriptionen av presentationen.<\/p>\n

<\/a><\/noindex><\/p>\n

God dag, kollegor och st\u00f6djande \u00e5h\u00f6rare. Idag kommer jag att prata om s\u00e4kerhet.<\/p>\n

<\/p>\n

Jag ser att det finns m\u00e5nga s\u00e4kerhetsproffs h\u00e4r idag. Jag ber om urs\u00e4kt i f\u00f6rv\u00e4g om jag anv\u00e4nder termer fr\u00e5n s\u00e4kerhetsv\u00e4rlden p\u00e5 ett s\u00e4tt som inte \u00e4r helt standard f\u00f6r er. <\/p>\n

<\/p>\n

F\u00f6r ungef\u00e4r ett halv\u00e5r sedan fick jag tillg\u00e5ng till ett offentligt Kubernetes-kluster. Offentligt betyder att det finns ett visst antal namnrymder d\u00e4r anv\u00e4ndare \u00e4r isolerade i sina egna namnrymder. Alla dessa anv\u00e4ndare tillh\u00f6r olika f\u00f6retag. Tanken var att detta kluster skulle anv\u00e4ndas som CDN. Det vill s\u00e4ga, ni f\u00e5r klustret, f\u00e5r en anv\u00e4ndare in i ert namnrum, och ni kommer f\u00f6r att distribuera era frontend. <\/p>\n

<\/p>\n

Mitt tidigare f\u00f6retag f\u00f6rs\u00f6kte s\u00e4lja en s\u00e5dan tj\u00e4nst. Jag blev ombedd att unders\u00f6ka klustret f\u00f6r att se om denna l\u00f6sning var l\u00e4mplig eller inte. <\/p>\n

<\/p>\n

Jag gick in i detta kluster. Jag fick begr\u00e4nsade r\u00e4ttigheter, begr\u00e4nsad namnrymd. D\u00e4r f\u00f6rstod killarna vad s\u00e4kerhet innebar. De hade l\u00e4st om Rollbaserad \u00e5tkomstkontroll (RBAC) i Kubernetes \u2014 och de hade konfigurerat det s\u00e5 att jag inte kunde k\u00f6ra pods separat fr\u00e5n deployeringar. Jag minns inte uppgiften som jag f\u00f6rs\u00f6kte l\u00f6sa genom att k\u00f6ra en pod utan en deployering, men jag ville verkligen bara k\u00f6ra en pod. Jag besl\u00f6t mig f\u00f6r att kolla vilka r\u00e4ttigheter jag hade i klustret, vad jag kunde och inte kunde g\u00f6ra, och vad de hade st\u00e4llt till med. Jag kommer ocks\u00e5 att ber\u00e4tta att deras RBAC var felkonfigurerat. <\/p>\n

<\/p>\n

Det h\u00e4nde sig att efter tv\u00e5 minuter hade jag blivit administrat\u00f6r f\u00f6r deras kluster, jag tittade i alla angr\u00e4nsande namnrymder och s\u00e5g aktiva produktionsfronter fr\u00e5n f\u00f6retag som redan k\u00f6pt tj\u00e4nsten och hade distribuerat sina system. Jag fick sv\u00e5rt att inte g\u00e5 in p\u00e5 n\u00e5gon av sidorna och placera n\u00e5got ol\u00e4mpligt ord p\u00e5 f\u00f6rstasidan. <\/p>\n

<\/p>\n

Jag kommer att ber\u00e4tta med exempel hur jag gjorde detta och hur man skyddar sig mot det. <\/p>\n

<\/p>\n

Men jag ska f\u00f6rst presentera mig. Jag heter Pavel Selivanov. Jag \u00e4r arkitekt p\u00e5 Southbridge. Jag har kunskaper inom Kubernetes, DevOps och diverse moderna grejer. Tillsammans med ingenj\u00f6rerna p\u00e5 Southbridge bygger vi detta, och jag ger r\u00e5dgivning. <\/p>\n

<\/p>\n

F\u00f6rutom v\u00e5r huvudverksamhet har vi nyligen lanserat projekt som kallas Sl\u00ebrmy. Vi f\u00f6rs\u00f6ker sprida v\u00e5r f\u00f6rm\u00e5ga att arbeta med Kubernetes och l\u00e4ra andra att ocks\u00e5 arbeta med K8s. <\/p>\n

<\/p>\n

Vad jag kommer att prata om idag. Temat f\u00f6r presentationen \u00e4r helt klart \u2014 s\u00e4kerheten i Kubernetes-kluster. Men jag vill genast s\u00e4ga att detta \u00e4mne \u00e4r mycket stort \u2014 och d\u00e4rf\u00f6r vill jag direkt klarg\u00f6ra vad jag definitivt inte kommer att diskutera. Jag kommer inte att prata om klich\u00e9er som redan har diskuterats hundratals g\u00e5nger p\u00e5 internet. S\u00e5dana saker som RBAC och certifikat. <\/p>\n

<\/p>\n

Jag kommer att ber\u00e4tta om de saker som mig och mina kollegor bekymrar inom s\u00e4kerheten i Kubernetes-kluster. Vi ser dessa problem hos b\u00e5de leverant\u00f6rer som tillhandah\u00e5ller Kubernetes-kluster och hos kunder som kommer till oss. Och till och med hos kunder som kommer till oss fr\u00e5n andra konsultadministrationsf\u00f6retag. Det vill s\u00e4ga, tragedins omfattning \u00e4r faktiskt mycket stor. <\/p>\n

<\/p>\n

Jag kommer idag att diskutera tre punkter: <\/p>\n

<\/p>\n

    \n
  1. Anv\u00e4ndarr\u00e4ttigheter vs pod-r\u00e4ttigheter. Anv\u00e4ndarr\u00e4ttigheter och pod-r\u00e4ttigheter \u00e4r inte samma sak. <\/li>\n
  2. Informationsinsamling om klustret. Jag kommer att visa vad som kan samlas in fr\u00e5n klustret, som kan beh\u00f6vas utan s\u00e4rskilda r\u00e4ttigheter i detta kluster. <\/li>\n
  3. DoS-attack mot klustret. Om vi inte kan samla in information kan vi \u00e4nd\u00e5 sl\u00e5 ut klustret. Jag kommer att ber\u00e4tta om DoS-attacker mot klusterhanteringskomponenterna. <\/li>\n<\/ol>\n

    <\/p>\n

    En annan allm\u00e4n sak som jag kommer att n\u00e4mna \u2014 vad jag testade detta p\u00e5, vad jag definitivt kan s\u00e4ga fungerar.<\/p>\n

    <\/p>\n

    Vi baserar oss p\u00e5 installationen av Kubernetes-klustret med Kubespray. Om n\u00e5gon inte vet, s\u00e5 \u00e4r detta i princip ett set av roller f\u00f6r Ansible. Vi anv\u00e4nder det konstant i v\u00e5rt arbete. Det \u00e4r bra eftersom det kan anv\u00e4ndas \u00f6verallt \u2014 b\u00e5de p\u00e5 fysiska serverar och i molnet. En installationsmetod passar i princip f\u00f6r allt. <\/p>\n

    <\/p>\n

    I detta kluster kommer jag att ha Kubernetes v1.14.5. Hela klustret av Kubernetes, som vi ska titta p\u00e5, \u00e4r uppdelat i namnomr\u00e5den, d\u00e4r varje namnomr\u00e5de tillh\u00f6r ett separat team och endast medlemmarna i det teamet har tillg\u00e5ng till sitt eget namnomr\u00e5de. De kan inte g\u00e5 in i andra namnomr\u00e5den. Men det finns ett administrat\u00f6rskonto som har r\u00e4ttigheter f\u00f6r hela klustret. <\/p>\n

    <\/p>\n

    \"Vi<\/p>\n

    <\/p>\n

    Jag lovade att det f\u00f6rsta vi ska g\u00f6ra \u00e4r att f\u00e5 administrativa r\u00e4ttigheter till klustret. Vi beh\u00f6ver en speciellt f\u00f6rberedd pod som kommer att bryta klustret Kubernetes. Det enda vi beh\u00f6ver g\u00f6ra \u00e4r att till\u00e4mpa den i klustret Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Denna pod kommer att landa p\u00e5 en av masternoderna i klustret Kubernetes. Klustret kommer glatt att returnera en fil som heter admin.conf. I denna fil lagras alla certifikat f\u00f6r administrat\u00f6ren, och dessutom \u00e4r API:et f\u00f6r klustret konfigurerat. S\u00e5 enkelt kan man f\u00e5 administrativ \u00e5tkomst, jag tror till 98% av Kubernetes-kluster. <\/p>\n
    <\/p>\n
    Jag upprepar, denna pod skapades av en utvecklare i ert kluster, som har tillg\u00e5ng att distribuera sina f\u00f6rslag i ett litet namnomr\u00e5de, d\u00e4r allt \u00e4r begr\u00e4nsat av RBAC. Han hade inga r\u00e4ttigheter. Men \u00e4nd\u00e5 kom certifikatet tillbaka. <\/p>\n
    <\/p>\n
    Nu, om den specialf\u00f6rberedda podden. L\u00e5t oss k\u00f6ra den p\u00e5 valfri bild. Som exempel tar vi debian:jessie. <\/p>\n
    <\/p>\n
    Vi har n\u00e5got s\u00e5dant h\u00e4r: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Vad \u00e4r tolerans? Masternoderna i Kubernetes-klustret \u00e4r vanligtvis markerade med n\u00e5got som kallas taint (\"smitta\" p\u00e5 engelska). Po\u00e4ngen med denna \"smitta\" \u00e4r att poddar inte f\u00e5r tilldelas till masternoder. Men ingen hindrar en pod fr\u00e5n att ange att den \u00e4r tolerant mot \"smittan\". Sektionen Toleration s\u00e4ger just att om det finns NoSchedule p\u00e5 en nod, s\u00e5 \u00e4r v\u00e5r pod tolerant mot denna smitta \u2014 och inga problem uppst\u00e5r. <\/p>\n
    <\/p>\n
    Vidare s\u00e4ger vi att v\u00e5r pod inte bara \u00e4r tolerant, utan ocks\u00e5 vill hamna speciellt p\u00e5 mastern. F\u00f6r p\u00e5 mastern finns det det mest attraktiva som vi beh\u00f6ver \u2014 alla certifikat. S\u00e5 vi specificerar nodeSelector \u2014 och vi har en standardetikett p\u00e5 mastern som g\u00f6r att vi kan v\u00e4lja just de noder i klustret som \u00e4r masters. <\/p>\n
    <\/p>\n
    Med dessa tv\u00e5 sektioner kommer podden garanterat att hamna p\u00e5 mastern. Och den kommer att f\u00e5 bo d\u00e4r. <\/p>\n
    <\/p>\n
    Men det \u00e4r inte tillr\u00e4ckligt att bara komma till mastern. Det kommer inte att ge oss n\u00e5got. S\u00e5 h\u00e4r f\u00f6ljer tv\u00e5 saker:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Vi anger att v\u00e5r podd, som vi k\u00f6r, kommer att leva i k\u00e4rnans namnutrymme, i n\u00e4tverksnamnutrymmet och i PID-namnutrymmet. S\u00e5 snart podden startar p\u00e5 mastern, kommer den att kunna se alla riktiga, levande gr\u00e4nssnitt p\u00e5 denna nod, lyssna p\u00e5 all trafik och se PID f\u00f6r alla processer.<\/p>\n
    <\/p>\n
    D\u00e4refter \u00e4r det enkelt. Ta etcd och l\u00e4s vad du vill. <\/p>\n
    <\/p>\n
    Det mest intressanta \u00e4r denna funktion i Kubernetes, som \u00e4r d\u00e4r som standard. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    Och po\u00e4ngen \u00e4r att vi kan i podden, som vi k\u00f6r, \u00e4ven utan r\u00e4ttigheter i denna kluster, s\u00e4ga att vi vill skapa ett volume av typen hostPath. Det betyder att vi tar v\u00e4gen fr\u00e5n v\u00e4rden vi kommer att docka \u2014 och tar det som ett volume. Vi kallar det sedan name: host. Hela denna hostPath monteras inuti podden. I detta exempel i katalogen \/host. <\/p>\n
    <\/p>\n
    Jag upprepar. Vi har sagt till podden att \u00e5ka till mastern, f\u00e5 hostNetwork och hostPID \u2014 och montera hela root p\u00e5 mastern inuti denna pod. <\/p>\n
    <\/p>\n
    Du f\u00f6rst\u00e5r att vi har bash ig\u00e5ng i Debian, och denna bash k\u00f6rs under root. S\u00e5 vi har just f\u00e5tt root p\u00e5 mastern, utan att ha n\u00e5gra r\u00e4ttigheter i Kubernetes-klustret.<\/p>\n
    <\/p>\n
    D\u00e4refter \u00e4r hela uppgiften att g\u00e5 in i podden i katalogen \/host \/etc\/kubernetes\/pki, om jag inte minns fel, ta alla mastercertifikat fr\u00e5n klustret och d\u00e4rmed bli administrat\u00f6r av klustret. <\/p>\n
    <\/p>\n
    Om man ser det s\u00e5 h\u00e4r, \u00e4r dessa en av de mest farliga r\u00e4ttigheterna i poddar \u2014 oavsett vilka r\u00e4ttigheter anv\u00e4ndaren har:
    \n\"Vi<\/p>\n
    <\/p>\n
    Om jag har r\u00e4tt att k\u00f6ra en podd i n\u00e5got namnutrymme i klustret, s\u00e5 har denna podd dessa r\u00e4ttigheter som standard. Jag kan k\u00f6ra privilegierade poddar, och det betyder i princip alla r\u00e4ttigheter, n\u00e4stan root p\u00e5 noden. <\/p>\n
    <\/p>\n
    Min favorit \u2014 Root-anv\u00e4ndare. Och Kubernetes har en s\u00e5dan alternativ Run As Non-Root. Detta \u00e4r en sorts skydd mot hackare. Vet du vad en \"moldavisk virus\" \u00e4r? Om du pl\u00f6tsligt \u00e4r en hackare och har kommit in i mitt Kubernetes-kluster, s\u00e5 ber vi, de stackars administrat\u00f6rerna: \"Ange sn\u00e4lla i dina poddar, med vilka du planerar att hacka mitt kluster, run as non-root. Annars kan det h\u00e4nda att du k\u00f6r en process i din podd som root, och det blir v\u00e4ldigt enkelt f\u00f6r dig att hacka mig. Skydda dig sj\u00e4lv, sn\u00e4lla.\" <\/p>\n
    <\/p>\n
    Host path volume \u2014 enligt min \u00e5sikt, det snabbaste s\u00e4ttet att f\u00e5 det \u00f6nskade resultatet fr\u00e5n Kubernetes-klustret. <\/p>\n
    <\/p>\n
    Men vad ska man g\u00f6ra med allt detta? <\/p>\n
    <\/p>\n
    Tankar som varje normal administrat\u00f6r som st\u00f6ter p\u00e5 Kubernetes b\u00f6r ha: \"Aha, jag sa ju att Kubernetes inte fungerar. Den har h\u00e5l. Och hela Kubernetes \u00e4r skr\u00e4p.\" I verkligheten finns det n\u00e5got som heter dokumentation, och om man tittar dit s\u00e5 finns det ett avsnitt. Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Detta \u00e4r ett yaml-objekt - vi kan skapa det i Kubernetes-klustret - som kontrollerar s\u00e4kerhetsaspekter specifikt i beskrivningen av poddar. Det inneb\u00e4r att den faktiskt kontrollerar r\u00e4ttigheter f\u00f6r anv\u00e4ndning av olika hostNetwork, hostPID, vissa typer av volymer som finns i poddar vid start. Med hj\u00e4lp av Pod Security Policy kan allt detta beskrivas. <\/p>\n
    <\/p>\n
    Det mest intressanta med Pod Security Policy \u00e4r att i Kubernetes-klustret \u00e4r alla PSP-installationer egentligen inte beskrivna p\u00e5 n\u00e5got s\u00e4tt, de \u00e4r helt enkelt avst\u00e4ngda som standard. Pod Security Policy aktiveras med hj\u00e4lp av en admission plugin.<\/p>\n
    <\/p>\n
    Okej, vi ska deploya Pod Security Policy i klustret och s\u00e4ga att vi har vissa tj\u00e4nstepoddar i ett namespace som bara administrat\u00f6rer har \u00e5tkomst till. L\u00e5t oss s\u00e4ga att i alla andra poddar har man begr\u00e4nsade r\u00e4ttigheter. Eftersom det troligen inte \u00e4r n\u00f6dv\u00e4ndigt f\u00f6r utvecklarna att k\u00f6ra privilegierade poddar i ert kluster. <\/p>\n
    <\/p>\n
    Och vi har tydligen allt i ordning. Och v\u00e5rt Kubernetes-kluster kan inte hackas p\u00e5 tv\u00e5 minuter. <\/p>\n
    <\/p>\n
    Det finns ett problem. Troligen om ni har ett Kubernetes-kluster, s\u00e5 har ni ocks\u00e5 \u00f6vervakning installerad. Jag v\u00e5gar till och med f\u00f6rutsp\u00e5 att om det finns \u00f6vervakning i ert kluster s\u00e5 kallas den Prometheus. <\/p>\n
    <\/p>\n
    Det jag nu ska ber\u00e4tta g\u00e4ller b\u00e5de Prometheus-operat\u00f6ren och Prometheus installerad i sin rena form. Fr\u00e5gan \u00e4r att om jag inte kan f\u00e5 en administrat\u00f6r s\u00e5 snabbt i klustret, betyder det att jag m\u00e5ste leta mer. Och jag kan leta med hj\u00e4lp av er \u00f6vervakning.<\/p>\n
    <\/p>\n
    F\u00f6rmodligen har alla l\u00e4st samma artiklar p\u00e5 Habr\u00e9, och \u00f6vervakningen finns i namespace monitoring. Helm-diagrammet heter ungef\u00e4r detsamma f\u00f6r alla. Jag antar att om ni g\u00f6r helm install stable\/prometheus, s\u00e5 f\u00e5r ni ungef\u00e4r samma namn. Och det \u00e4r till och med troligt att DNS-namnet i ert kluster inte beh\u00f6ver gissas. Eftersom det \u00e4r standard. <\/p>\n
    <\/p>\n
    \"Vi<\/p>\n
    <\/p>\n
    Sedan har vi ett visst dev-namespac, i vilket man kan starta en viss pod. Och d\u00e4rifr\u00e5n \u00e4r det mycket l\u00e4tt att g\u00f6ra s\u00e5 h\u00e4r: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics \u00e4r en av Prometheus-export\u00f6rerna som samlar in m\u00e4tdata fr\u00e5n Kubernetes API:et. Det finns en m\u00e4ngd information om vad som k\u00f6rs i din kluster, hur det ser ut och vilka problem du har med det. <\/p>\n
    <\/p>\n
    Som ett enkelt exempel: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\"kube-system\",pod=\"kube-apiserver-k8s-1\",container=\"kube-apiserver\",image= <\/p>\n
    <\/p>\n
    \"gcr.io\/google-containers\/kube-apiserver:v1.14.5\" <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\"docker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\",container_id=\"docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\"} 1 <\/p>\n
    <\/p>\n
    Genom att g\u00f6ra en enkel curl-f\u00f6rfr\u00e5gan fr\u00e5n en icke-privilegerad pod kan du f\u00e5 s\u00e5dan information. Om du inte vet vilken version av Kubernetes du k\u00f6r s\u00e5 kan den enkelt ber\u00e4tta det f\u00f6r dig. <\/p>\n
    <\/p>\n
    Och det mest intressanta \u00e4r att f\u00f6rutom att du kontaktar kube-state-metrics kan du lika g\u00e4rna n\u00e5 sj\u00e4lva Prometheus direkt. Du kan samla in m\u00e4tdata d\u00e4rifr\u00e5n. Du kan till och med bygga m\u00e4tdata d\u00e4rifr\u00e5n. Teoretiskt sett kan du konstruera en s\u00e5dan f\u00f6rfr\u00e5gan fr\u00e5n klustret till Prometheus som helt enkelt sl\u00e5r av det. Och din \u00f6vervakning kommer helt att sluta fungera. <\/p>\n
    <\/p>\n
    Och h\u00e4r uppst\u00e5r fr\u00e5gan, \u00f6vervakar n\u00e5gon extern \u00f6vervakning din \u00f6vervakning? Jag fick just m\u00f6jligheten att agera i Kubernetes-klustret helt utan konsekvenser f\u00f6r mig sj\u00e4lv. Du kommer inte ens att veta att jag \u00e4r d\u00e4r eftersom \u00f6vervakningen redan \u00e4r borttagen. <\/p>\n
    <\/p>\n
    Precis som med PSP finns k\u00e4nslan av att problemet \u00e4r att alla dessa trendiga teknologier \u2014 Kubernetes, Prometheus \u2014 helt enkelt inte fungerar och \u00e4r fyllda med h\u00e5l. Det \u00e4r faktiskt inte s\u00e5. <\/p>\n
    <\/p>\n
    Det finns n\u00e5got som kallas \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Om du \u00e4r en vanlig admin vet du sannolikt att Network Policy \u00e4r \u00e4nnu en yaml, av vilka det redan finns gott om i klustret. Och vissa Network Policies \u00e4r verkligen inte n\u00f6dv\u00e4ndiga. \u00c4ven om du har l\u00e4st vad en Network Policy \u00e4r, att den \u00e4r en yaml-brandv\u00e4gg f\u00f6r Kubernetes, som g\u00f6r det m\u00f6jligt att begr\u00e4nsa \u00e5tkomstr\u00e4ttigheter mellan namespaces, mellan pods, s\u00e5 har du s\u00e4kert kommit fram till att en brandv\u00e4gg i yaml-format i Kubernetes \u00e4r ytterligare en abstraktion\u2026 Nej, det beh\u00f6vs verkligen inte. <\/p>\n
    <\/p>\n
    \u00c4ven om era s\u00e4kerhetsspecialister inte har ber\u00e4ttat att ni kan bygga en mycket enkel och granul\u00e4r brandv\u00e4gg med hj\u00e4lp av er Kubernetes, beh\u00f6ver ni i alla fall Network Policy f\u00f6r att st\u00e4nga \u00e5tkomst till vissa k\u00e4nsliga platser som kan n\u00e5s fr\u00e5n er kluster utan n\u00e5gon autentisering. <\/p>\n
    <\/p>\n
    Som i exemplet jag n\u00e4mnde kan man n\u00e5 kube state metrics fr\u00e5n vilket namnrum som helst i Kubernetes-klustret utan att ha n\u00e5gra r\u00e4ttigheter. Network policies st\u00e4ngde \u00e5tkomst fr\u00e5n alla andra namnrum till \u00f6vervakningsnamnrymden, och s\u00e5 \u00e4r det: ingen \u00e5tkomst, inga problem. I alla diagram som finns, b\u00e5de i standard Prometheus och det Prometheus som finns i operat\u00f6ren, finns det helt enkelt ett alternativ att aktivera n\u00e4tverkspolicys f\u00f6r dem i values-filen i Helm. Det \u00e4r bara att aktivera, s\u00e5 fungerar de. <\/p>\n
    <\/p>\n
    Det finns dock ett problem med detta. Som en erfaren administrat\u00f6r har ni f\u00f6rmodligen kommit fram till att n\u00e4tverkspolicys inte \u00e4r n\u00f6dv\u00e4ndiga. Och efter att ha l\u00e4st olika artiklar p\u00e5 resurser som Habr, har ni beslutat att flannel, s\u00e4rskilt i host-gateway-l\u00e4get, \u00e4r det b\u00e4sta alternativet ni kan v\u00e4lja. <\/p>\n
    <\/p>\n
    Vad g\u00f6ra? <\/p>\n
    <\/p>\n
    Ni kan f\u00f6rs\u00f6ka omdeplaera den n\u00e4tverksl\u00f6sning som ni har i ert Kubernetes-kluster och byta ut den mot n\u00e5got mer funktionellt. Kanske Calico, till exempel. Men jag vill genast p\u00e5peka att det \u00e4r en ganska komplicerad uppgift att byta n\u00e4tverksl\u00f6sning i ett aktivt Kubernetes-kluster. Jag har l\u00f6st det tv\u00e5 g\u00e5nger (b\u00e5da g\u00e5ngerna, faktiskt, teoretiskt), men vi visade till och med p\u00e5 Slurm hur man g\u00f6r. F\u00f6r v\u00e5ra studenter visade vi hur man byter n\u00e4tverksl\u00f6sning i ett Kubernetes-kluster. Ni kan i princip f\u00f6rs\u00f6ka g\u00f6ra det s\u00e5 att det inte blir n\u00e5gon driftstopp i produktionsklustret. Men det \u00e4r troligt att ni misslyckas. <\/p>\n
    <\/p>\n
    Och problemet g\u00e5r faktiskt att l\u00f6sa ganska enkelt. I klustret finns det certifikat, och ni vet att certifikaten kommer att g\u00e5 ut om ett \u00e5r. Det normala tillv\u00e4gag\u00e5ngss\u00e4ttet med certifikat i klustret \u00e4r att vi s\u00e4tter upp ett nytt kluster bredvid, l\u00e5ter det gamla g\u00e5 ut, och allt deployas om. Visserligen kommer det gamla klustret att ligga stilla i en hel dag n\u00e4r det g\u00e5r ut, men d\u00e5 har vi \u00e5tminstone det nya klustret. <\/p>\n
    <\/p>\n
    N\u00e4r ni s\u00e4tter upp det nya klustret, se till att inkludera Calico ist\u00e4llet f\u00f6r flannel. <\/p>\n
    <\/p>\n
    Vad ska man g\u00f6ra om dina certifikat \u00e4r utf\u00e4rdade p\u00e5 hundra \u00e5r och du inte t\u00e4nker omdeploya klustret? Det finns n\u00e5got som heter Kube-RBAC-Proxy. Det \u00e4r en riktigt fantastisk l\u00f6sning som l\u00e5ter dig integrera den som en sidecar-container i valfri podd i Kubernetes-klustret. Den tillf\u00f6r i praktiken autentisering via RBAC i sj\u00e4lva Kubernetes. <\/p>\n
    <\/p>\n
    Det finns ett problem. Tidigare var Kube-RBAC-Proxy integrerat i Prometheus-operatorn. Men det finns inte l\u00e4ngre. Nu k\u00f6r moderna versioner p\u00e5 att du har en n\u00e4tverkspolicy som st\u00e4nger av \u00e5tkomst med hj\u00e4lp av dem. D\u00e4rf\u00f6r m\u00e5ste du \u00e4ndra diagrammet lite grann. Om du g\u00e5r in i detta repository<\/a><\/noindex>, hittar du exempel p\u00e5 hur man anv\u00e4nder det som sidecars, och diagrammen m\u00e5ste \u00e4ndras minimalt. <\/p>\n
    <\/p>\n
    Det finns \u00e4ven ett litet problem till. Inte bara Prometheus levererar sina m\u00e4tv\u00e4rden till vem som helst. Alla komponenter i Kubernetes-klustret kan ocks\u00e5 leverera sina egna m\u00e4tv\u00e4rden. <\/p>\n
    <\/p>\n
    Men som jag redan har n\u00e4mnt, om du inte kan f\u00e5 \u00e5tkomst till klustret och samla information, kan du \u00e5tminstone skada det. <\/p>\n
    <\/p>\n
    S\u00e5 jag ska snabbt visa tv\u00e5 s\u00e4tt att f\u00f6rst\u00f6ra h\u00e4lsan p\u00e5 ett Kubernetes-kluster. <\/p>\n
    <\/p>\n
    Du kommer att skratta n\u00e4r jag ber\u00e4ttar detta, det \u00e4r tv\u00e5 fall fr\u00e5n verkliga livet. <\/p>\n
    <\/p>\n
    Metod ett. Resursutarmning. <\/p>\n
    <\/p>\n
    Vi startar en s\u00e4rskild podd. Den kommer att ha en sektion som ser ut s\u00e5 h\u00e4r. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Som du vet \u00e4r requests den m\u00e4ngd CPU och minne som reserveras p\u00e5 v\u00e4rden f\u00f6r specifika poddar med requests. Om vi har en fyrk\u00e4rnig v\u00e4rd i Kubernetes-klustret, och det finns en podd med fyra CPU i requests, betyder det att ingen annan podd med requests kan \u00e5ka dit. <\/p>\n
    <\/p>\n
    Om jag startar en s\u00e5dan podd och sedan k\u00f6r kommandot: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    D\u00e5 kan ingen annan deploya i Kubernetes-klustret. Eftersom alla noder f\u00e5r slut p\u00e5 requests. P\u00e5 s\u00e5 s\u00e4tt kan jag stoppa ditt Kubernetes-kluster. Om jag g\u00f6r detta p\u00e5 kv\u00e4llen kan jag stoppa deployerna ganska l\u00e4nge. <\/p>\n
    <\/p>\n
    Om vi tittar igenom Kubernetes-dokumentationen s\u00e5 ser vi n\u00e5got som kallas Limit Range. Det s\u00e4tter resursgr\u00e4nser f\u00f6r klusterobjekt. Du kan skriva ett Limit Range-objekt i yaml, till\u00e4mpa det p\u00e5 specifika namespaces \u2014 och sedan kan du ange att du har standard-, maximal- och minimalresurser f\u00f6r pods i det namnet.<\/p>\n
    <\/p>\n
    Med den h\u00e4r funktionen kan vi begr\u00e4nsa anv\u00e4ndare i specifika produktnamn f\u00f6r team n\u00e4r det g\u00e4ller att ange o\u00f6nskade resurser f\u00f6r sina pods. Men tyv\u00e4rr, \u00e4ven om du informerar anv\u00e4ndaren att de inte f\u00e5r starta pods med beg\u00e4rningar som \u00f6verstiger en CPU, finns det en fantastisk skala-kommando, eller via dashboarden kan de utf\u00f6ra skalan.<\/p>\n
    <\/p>\n
    Och h\u00e4rifr\u00e5n kommer s\u00e4tt nummer tv\u00e5. Vi startar 11 111 111 111 111 pods. Det \u00e4r elva miljarder. Detta \u00e4r inte f\u00f6r att jag hittade p\u00e5 det numret, utan f\u00f6r att jag sj\u00e4lv har sett det. <\/p>\n
    <\/p>\n
    En sann historia. Sent p\u00e5 kv\u00e4llen var jag redo att l\u00e4mna kontoret. Jag s\u00e5g en grupp utvecklare sitta i ett h\u00f6rn och g\u00f6ra n\u00e5got hektiskt med sina laptops. Jag gick fram till killarna och fr\u00e5gade: \"Vad har h\u00e4nt?\"<\/p>\n
    <\/p>\n
    Lite tidigare, vid nio p\u00e5 kv\u00e4llen, var en av utvecklarna p\u00e5 v\u00e4g hem. Han best\u00e4mde sig: \"Jag ska skala min applikation till en.\" Han tryckte p\u00e5 enan, men internet blev lite segt. Han tryckte en g\u00e5ng till p\u00e5 enan, han tryckte p\u00e5 enan, klickade p\u00e5 Enter. Han tryckte p\u00e5 allt han kunde. D\u00e5 blev internet snabbt igen \u2014 och allt b\u00f6rjade skala till det numret. <\/p>\n
    <\/p>\n
    Men detta h\u00e4nde inte p\u00e5 Kubernetes, d\u00e5 var det Nomad. Detta slutade med att efter en timmes f\u00f6rs\u00f6k att stoppa Nomad fr\u00e5n att insistera p\u00e5 att skala, svarade Nomad att den inte skulle sluta skala och inte skulle g\u00f6ra n\u00e5got annat. \"Jag \u00e4r tr\u00f6tt, jag g\u00e5r\". Och l\u00e5g ner. <\/p>\n
    <\/p>\n
    Sj\u00e4lvklart f\u00f6rs\u00f6kte jag g\u00f6ra detsamma p\u00e5 Kubernetes. Elva miljarder pods gjorde Kubernetes besviken, den sa: \"Jag kan inte. \u00d6verskrider interna gr\u00e4nser.\" Men 1 000 000 000 pods gick att skapa. <\/p>\n
    <\/p>\n
    Som svar p\u00e5 en miljard Pods har Kubernetes inte st\u00e4ngt av sig sj\u00e4lv. Det b\u00f6rjade verkligen skala. Ju l\u00e4ngre processen fortskred, desto mer tid kr\u00e4vdes f\u00f6r att skapa nya Pods. Men processen fortsatte \u00e4nd\u00e5. Det enda problemet \u00e4r att om jag kan starta Pods utan begr\u00e4nsningar i mitt namnrymd, s\u00e5 kan jag, \u00e4ven utan requests och begr\u00e4nsningar, starta s\u00e5 m\u00e5nga Pods med olika uppgifter att noderna b\u00f6rjar lagra minne och CPU-resurser. N\u00e4r jag startar s\u00e5 m\u00e5nga Pods, m\u00e5ste informationen fr\u00e5n dem lagras, det vill s\u00e4ga i etcd. Och n\u00e4r f\u00f6r mycket information n\u00e5r lagringen, b\u00f6rjar den att ge ut data f\u00f6r l\u00e5ngsamt \u2014 och Kubernetes f\u00e5r problem. <\/p>\n
    <\/p>\n
    Och en ytterligare problem\u2026 Som ni vet, \u00e4r Kubernetes kontrollkomponenter inte en enskild central enhet, utan flera komponenter. D\u00e4r finns bland annat controller manager, scheduler och s\u00e5 vidare. Alla dessa komponenter kommer att b\u00f6rja utf\u00f6ra on\u00f6digt arbete samtidigt, vilket med tiden kommer att ta mer och mer tid. Controller manager kommer att skapa nya Pods. Scheduler kommer att f\u00f6rs\u00f6ka hitta nya noder \u00e5t dem. Nya noder i din kluster kommer sannolikt att ta slut snart. Kubernetes-klustret kommer att b\u00f6rja arbeta l\u00e5ngsammare och l\u00e5ngsammare.<\/p>\n
    <\/p>\n
    Men jag best\u00e4mde mig f\u00f6r att g\u00e5 \u00e4nnu l\u00e4ngre. Som ni vet finns det n\u00e5got i Kubernetes som kallas en tj\u00e4nst. Och som standard fungerar tj\u00e4nsten i era kluster, sannolikt, med hj\u00e4lp av IP-tables. <\/p>\n
    <\/p>\n
    Om man startar en miljard Pods, till exempel, och sedan med hj\u00e4lp av ett skript f\u00e5r Kubernetes att skapa nya tj\u00e4nster: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    P\u00e5 alla noder i klustret kommer nya IP-tables regler att genereras n\u00e4stan samtidigt. Dessutom kommer en miljard IP-tables regler att genereras f\u00f6r varje tj\u00e4nst. <\/p>\n
    <\/p>\n
    Jag har testat detta med n\u00e5gra tusen, upp till ett tiotal. Problemet \u00e4r att det redan p\u00e5 denna niv\u00e5 \u00e4r ganska problematiskt att g\u00f6ra en SSH-anslutning till en nod. Eftersom paketen, som passerar genom s\u00e5 m\u00e5nga kedjor, inte m\u00e5r s\u00e5 bra. <\/p>\n
    <\/p>\n
    Och detta l\u00f6ses ocks\u00e5 med hj\u00e4lp av Kubernetes. Det finns ett objekt som heter Resource quota. Det fastst\u00e4ller antalet tillg\u00e4ngliga resurser och objekt f\u00f6r namnomr\u00e5det i klustret. Vi kan skapa en yaml-objekt i varje namnomr\u00e5de i Kubernetes-klustret. Med hj\u00e4lp av detta objekt kan vi s\u00e4ga att vi har f\u00e5tt ett visst antal f\u00f6rfr\u00e5gningar och begr\u00e4nsningar f\u00f6r detta namnomr\u00e5de, och vidare kan vi s\u00e4ga att det \u00e4r m\u00f6jligt att skapa 10 tj\u00e4nster och 10 pods i detta namnomr\u00e5de. Och utvecklaren kan ge sig sj\u00e4lv kvot f\u00f6r att experimentera p\u00e5 kv\u00e4llarna. Kubernetes kommer att s\u00e4ga: \"Det g\u00e5r inte att skala upp dina pods till den m\u00e4ngden, eftersom det \u00f6verskrider resurskvoten.\" Problemet \u00e4r l\u00f6st. Dokumentation finns h\u00e4r<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Ett problematiskt moment uppst\u00e5r i samband med detta. Du k\u00e4nner hur sv\u00e5rt det blir att skapa ett namnomr\u00e5de i Kubernetes. F\u00f6r att skapa det beh\u00f6ver vi ta h\u00e4nsyn till en massa olika faktorer.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Skapa namnomr\u00e5de
    \n\u2022 Skapa en limit range inuti
    \n\u2022 Skapa en resource quota inuti
    \n\u2022 Skapa ett service account f\u00f6r CI
    \n\u2022 Skapa role binding f\u00f6r CI och anv\u00e4ndare
    \n\u2022 Eventuellt starta n\u00f6dv\u00e4ndiga service pods <\/p>\n
    <\/p>\n
    S\u00e5 jag vill g\u00e4rna passa p\u00e5 att dela med mig av mina projekt. Det finns en sak som kallas operator SDK. Det \u00e4r ett s\u00e4tt att skriva operat\u00f6rer f\u00f6r Kubernetes-klustret. Du kan skriva operat\u00f6rer med hj\u00e4lp av Ansible.<\/p>\n
    <\/p>\n
    F\u00f6rst hade vi skrivit det i Ansible, och sen s\u00e5g jag att det finns en operator SDK och skrev om Ansible-rollen till en operator. Denna operator g\u00f6r det m\u00f6jligt att skapa ett objekt i Kubernetes-klustret som kallas kommando. Inuti kommandot kan den beskriva milj\u00f6n f\u00f6r detta kommando i yaml. Och inom kommando-milj\u00f6n kan den beskriva hur mycket resurser vi tilldelar. <\/p>\n
    <\/p>\n
    Liten f\u00f6r att f\u00f6renkla hela denna komplicerade process<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Och slutligen. Vad ska man g\u00f6ra med allt detta?
    \nF\u00f6rsta. Pod Security Policy - det \u00e4r bra. Trots att ingen av Kubernetes-installat\u00f6rerna anv\u00e4nder dem till denna dag, b\u00f6r de \u00e4nd\u00e5 anv\u00e4ndas i era kluster. <\/p>\n
    <\/p>\n
    Network Policy - det \u00e4r ingen annan on\u00f6dig funktion. Det \u00e4r n\u00e5got som verkligen beh\u00f6vs i klustret. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota - det \u00e4r dags att anv\u00e4nda. Vi har anv\u00e4nt detta l\u00e4nge, och jag var l\u00e4nge \u00f6vertygad om att alla gjorde det. Det visade sig vara ganska s\u00e4llsynt. <\/p>\n
    <\/p>\n
    F\u00f6rutom det jag n\u00e4mnde under presentationen finns det odeklarerade funktioner som g\u00f6r det m\u00f6jligt att attackera klustret. Nyligen kom ut en stor analys av s\u00e5rbarheter i Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Vissa saker \u00e4r s\u00e5 sorgliga och uppr\u00f6rande. Som till exempel, under vissa f\u00f6rh\u00e5llanden kan kubeletar i Kubernetes-klustret ge obeh\u00f6riga anv\u00e4ndare \u00e5tkomst till inneh\u00e5llet i warlocks-katalogen. <\/p>\n
    <\/p>\n
    H\u00e4r<\/a><\/noindex> finns instruktioner om hur man \u00e5terskapar allt jag pratat om. Det finns filer med produktions exempel, som visar hur ResourceQuota och Pod Security Policy ser ut. Och allt detta kan man ta p\u00e5. <\/p>\n
    <\/p>\n
    Tack alla.<\/p>\n
    K\u00e4lla: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Vi \u00e5tg\u00e4rdar brister i Kubernetes-klustret. Presentation och transkription fr\u00e5n DevOpsConf | ProHoster","description":"Pavel Selivanov, l\u00f6sningsarkitekt p\u00e5 Southbridge och l\u00e4rare p\u00e5 Sl\u00f6rm, h\u00f6ll en presentation p\u00e5 DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019.","og:url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","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":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","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":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}