{"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\/ro\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Umplem golurile din clusterul Kubernetes. Prezentare \u0219i transcriere de la DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, arhitect de solu\u021bii Southbridge \u0219i profesor la Slyorm, a sus\u021binut o prezentare la DevOpsConf 2019. Aceast\u0103 prezentare face parte dintr-unul dintre temele cursului aprofundat despre Kubernetes \u201eSlyorm Mega\u201d.<\/p>\n

<\/p>\n

Slyorm Basic: introducere \u00een Kubernetes<\/a><\/noindex> se desf\u0103\u0219oar\u0103 la Moscova \u00eentre 18-20 noiembrie.
\nSlyorm Mega: privim sub capot\u0103 Kubernetes<\/a><\/noindex> \u2014 Moscova, 22-24 noiembrie.
\nSlyorm Online: ambele cursuri despre Kubernetes<\/a><\/noindex> sunt disponibile \u00een permanen\u021b\u0103.<\/p>\n

\n

\r\n \"Reda\u021bi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Sub acest articol \u2014 transcrierea prezent\u0103rii.<\/p>\n

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

Bun\u0103 ziua, colegi \u0219i sus\u021bin\u0103tori. Ast\u0103zi voi vorbi despre securitate.<\/p>\n

<\/p>\n

V\u0103d c\u0103 \u00een sal\u0103 sunt mul\u021bi speciali\u0219ti \u00een securitate. \u00cemi cer scuze anticipat dac\u0103 termenii din domeniul securit\u0103\u021bii nu-i voi folosi exact cum este uzual. <\/p>\n

<\/p>\n

A\u0219a s-a \u00eent\u00e2mplat, c\u0103 acum aproximativ jum\u0103tate de an am avut \u00een m\u00e2n\u0103 un cluster Kubernetes public. Public \u00eenseamn\u0103 c\u0103 are un anumit num\u0103r de namespaces, \u00een aceste namespaces sunt utilizatori, izola\u021bi \u00een propriul lor namespace. To\u021bi ace\u0219ti utilizatori apar\u021bin unor companii diferite. \u015ei se presupunea c\u0103 acest cluster ar trebui folosit ca CDN. Adic\u0103 v\u0103 este oferit un cluster, se creaz\u0103 un utilizator pentru el, veni\u021bi \u00een namespace-ul vostru \u0219i desf\u0103\u0219ura\u021bi frontend-urile voastre. <\/p>\n

<\/p>\n

Compania mea anterioar\u0103 a \u00eencercat s\u0103 v\u00e2nd\u0103 un astfel de serviciu. \u0218i am fost rugat s\u0103 verific cluster-ul pentru a vedea dac\u0103 o astfel de solu\u021bie se potrive\u0219te. <\/p>\n

<\/p>\n

Am ajuns \u00een acest cluster. Mi s-au oferit drepturi limitate, un namespace limitat. Acolo oamenii \u00een\u021belegeau ce \u00eenseamn\u0103 securitate. Au citit despre controlul accesului bazat pe roluri (RBAC) din Kubernetes \u2014 \u0219i l-au implementat a\u0219a, \u00eenc\u00e2t nu puteam lansa pod-uri separat de deployment-uri. Nu-mi amintesc ce problem\u0103 \u00eencercam s\u0103 rezolv lanc\u00e2nd un pod f\u0103r\u0103 deployment, dar mi-a pl\u0103cut foarte mult s\u0103 lansez pur \u0219i simplu un pod. Am decis s\u0103 verific ce drepturi am \u00een cluster, ce pot \u0219i ce nu pot, ce au configurat acolo. De asemenea, voi spune ce au configurat gre\u0219it \u00een RBAC. <\/p>\n

<\/p>\n

A\u0219a s-a \u00eent\u00e2mplat c\u0103 \u00een dou\u0103 minute am devenit admin al cluster-ului lor, am verificat toate namespaces-urile vecine \u0219i am observat frontend-uri de produc\u021bie ale companiilor care au cump\u0103rat deja serviciul \u0219i s-au desf\u0103\u0219urat. M-am oprit cu greu s\u0103 nu merg la cineva \u00een frontend \u0219i s\u0103 plasez un cuv\u00e2nt obscen pe pagina principal\u0103. <\/p>\n

<\/p>\n

Voi ilustra prin exemple cum am f\u0103cut asta \u0219i cum ar trebui s\u0103 ne ap\u0103r\u0103m de astfel de situa\u021bii. <\/p>\n

<\/p>\n

Dar mai \u00eent\u00e2i, permite\u021bi-mi s\u0103 m\u0103 prezint. Numele meu este Pavel Selivanov. Sunt arhitect la compania Southbridge. M\u0103 pricep la Kubernetes, DevOps \u0219i la tot felul de tehnologii moderne. \u00cempreun\u0103 cu inginerii Southbridge, construit tot acest sistem, iar eu ofer consultan\u021b\u0103. <\/p>\n

<\/p>\n

\u00cen afar\u0103 de activitatea principal\u0103, recent am lansat proiecte numite Slerme. \u00cencerc\u0103m s\u0103 aducem abilit\u0103\u021bile noastre \u00een lucrul cu Kubernetes \u00een r\u00e2ndul publicului larg, \u00eenv\u0103\u021b\u00e2nd \u0219i pe al\u021bii s\u0103 foloseasc\u0103 K8s. <\/p>\n

<\/p>\n

Despre ce voi vorbi ast\u0103zi. Tema prezent\u0103rii este evident\u0103 \u2013 despre securitatea clusterului Kubernetes. Dar trebuie s\u0103 spun de la bun \u00eenceput c\u0103 acest subiect este foarte amplu \u2013 \u0219i din acest motiv trebuie s\u0103 clarific despre ce nu voi vorbi. Nu voi aborda termeni uzita\u021bi, care au fost deja r\u0103scoliti de o sut\u0103 de ori pe internet. Tot felul de RBAC \u0219i certificate. <\/p>\n

<\/p>\n

Voi vorbi despre problemele de securitate pe care le observ eu \u0219i colegii mei \u00een clusterul Kubernetes. Vedem aceste probleme at\u00e2t la furnizorii care ofer\u0103 clustere Kubernetes, c\u00e2t \u0219i la clien\u021bii care ne viziteaz\u0103. \u0218i chiar \u0219i la clien\u021bi care vin la noi de la alte companii de consultan\u021b\u0103 administrative. Deci, amploarea tragediei este, de fapt, foarte mare. <\/p>\n

<\/p>\n

\u00cen mod concret, voi discuta despre trei puncte ast\u0103zi: <\/p>\n

<\/p>\n

    \n
  1. Drepturile utilizatorilor vs drepturile pod-urilor. Drepturile utilizatorilor \u0219i drepturile pod-urilor nu sunt acela\u0219i lucru. <\/li>\n
  2. Colectarea informa\u021biilor despre cluster. Voi ar\u0103ta c\u0103, din cluster, putem colecta toate informa\u021biile necesare f\u0103r\u0103 a avea drepturi speciale \u00een acel cluster. <\/li>\n
  3. Atac DoS asupra cluster-ului. Dac\u0103 nu putem colecta informa\u021bii, putem totu\u0219i provoca pr\u0103bu\u0219irea cluster-ului. Voi vorbi despre atacurile DoS asupra elementelor de control ale cluster-ului. <\/li>\n<\/ol>\n

    <\/p>\n

    \u00cenc\u0103 un aspect general despre care voi men\u021biona \u2013 pe ce am testat toate acestea \u0219i pe ce pot spune cu certitudine c\u0103 func\u021bioneaz\u0103.<\/p>\n

    <\/p>\n

    Ne baz\u0103m pe instalarea cluster-ului Kubernetes folosind Kubespray. Dac\u0103 cineva nu \u0219tie, aceasta este practic o colec\u021bie de roluri pentru Ansible. O folosim constant \u00een munc\u0103. Este bun\u0103 deoarece poate fi aplicat\u0103 oriunde \u2013 at\u00e2t pe echipamente fizice, c\u00e2t \u0219i \u00een cloud. O singur\u0103 metod\u0103 de instalare este, \u00een principiu, potrivit\u0103 pentru toate. <\/p>\n

    <\/p>\n

    \u00cen acest cluster, voi avea Kubernetes v1.14.5. \u00centregul cluster Kubernetes, despre care vom vorbi, este \u00eemp\u0103r\u021bit \u00een namespace-uri, fiecare namespace apar\u021bine unei echipe separate, iar membrii acestei echipe au acces \u00een fiecare namespace. Nu au voie s\u0103 acceseze namespace-uri diferite, doar pe al lor. Dar exist\u0103 un cont de administrator, care are drepturi asupra \u00eentregului cluster. <\/p>\n

    <\/p>\n

    \"Umplem<\/p>\n

    <\/p>\n

    Am promis c\u0103 primul lucru pe care \u00eel vom face va fi ob\u021binerea drepturilor de administrator asupra cluster-ului. Avem nevoie de un pod special preg\u0103tit, care va compromite cluster-ul Kubernetes. Tot ce trebuie s\u0103 facem este s\u0103-l aplic\u0103m \u00een cluster-ul Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Acest pod va ajunge pe unul dintre masterele cluster-ului Kubernetes. Iar cluster-ul ne va returna dup\u0103 aceea un fi\u0219ier numit admin.conf. \u00cen acest fi\u0219ier se afl\u0103 toate certificatele administratorului \u0219i, \u00een plus, este configurat API-ul cluster-ului. A\u0219a de simplu putem ob\u021bine acces de administrator, cred c\u0103 la 98% din cluster-urile Kubernetes. <\/p>\n
    <\/p>\n
    Reiterez, acest pod a fost creat de un dezvoltator din cluster-ul vostru, care are acces s\u0103 implementeze propunerile sale \u00eentr-un mic namespace, fiind complet restric\u021bionat de RBAC. Nu avea niciun drept. Dar, cu toate acestea, certificatul a fost returnat. <\/p>\n
    <\/p>\n
    Acum despre podul special preg\u0103tit. \u00cel lans\u0103m pe o imagine oricare. Ca exemplu, s\u0103 lu\u0103m debian:jessie. <\/p>\n
    <\/p>\n
    Avem a\u0219a ceva: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Ce este tolera\u021bia? Masterele din cluster-ul Kubernetes sunt de obicei marcate cu ceva numit taint. \u0218i esen\u021ba acestei \u201ezgarieturi\u201d este c\u0103 nu se pot aloca poduri pe nodurile master. Dar nimeni nu \u00eempiedic\u0103 un pod s\u0103 declare c\u0103 este tolerant la \u201ezgarieturi\u201d. Sec\u021biunea Tolerations arat\u0103 exact c\u0103, dac\u0103 pe un nod este setat NoSchedule, atunci podul nostru este tolerant la aceast\u0103 \u201ezgarietur\u0103\u201d \u2014 \u0219i nu sunt probleme. <\/p>\n
    <\/p>\n
    Mai departe, spunem c\u0103 podul nostru nu este doar tolerant, ci \u0219i c\u0103 vrea s\u0103 ajung\u0103 \u00een mod special pe master. Deoarece pe mastere se afl\u0103 cele mai importante lucruri de care avem nevoie \u2014 toate certificatele. De aceea, spunem nodeSelector \u2014 \u0219i avem un label standard pe mastere, care permite selectarea nodurilor care sunt mastere din toate nodurile cluster-ului. <\/p>\n
    <\/p>\n
    Cu aceste dou\u0103 sec\u021biuni, podul va ajunge cu siguran\u021b\u0103 pe master. \u0218i i se va permite s\u0103 r\u0103m\u00e2n\u0103 acolo. <\/p>\n
    <\/p>\n
    Dar a ajunge pe master nu este suficient. Nu ne va ajuta cu nimic. De aceea, avem dou\u0103 lucruri de ansamblu:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Specific\u0103m c\u0103 pod-ul nostru, pe care \u00eel vom rula, va tr\u0103i \u00een namespace-ul kernel, \u00een network namespace \u0219i \u00een PID namespace. Odat\u0103 ce pod-ul porne\u0219te pe master, acesta va putea vedea toate interfe\u021bele reale, active ale acestei noduri, va asculta tot traficul \u0219i va vedea PID-urile tuturor proceselor.<\/p>\n
    <\/p>\n
    Apoi, este simplu. Lua\u021bi etcd \u0219i citi\u021bi ce dori\u021bi. <\/p>\n
    <\/p>\n
    Cea mai interesant\u0103 este aceast\u0103 capacitate Kubernetes, care este implicit\u0103 acolo. <\/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
    \u0218i esen\u021ba sa este c\u0103 putem \u00een pod-ul pe care \u00eel rul\u0103m, chiar \u0219i f\u0103r\u0103 drepturi pe acest cluster, s\u0103 spunem c\u0103 vrem s\u0103 cre\u0103m un volum de tip hostPath. Adic\u0103 s\u0103 lu\u0103m calea de pe gazd\u0103, pe care ne vom rula \u2014 \u0219i s\u0103 o folosim ca volum. \u0218i ulterior \u00eel numim name: host. \u00centreg acest hostPath \u00eel mont\u0103m \u00een interiorul pod-ului. \u00cen acest exemplu \u00een directorul \/host. <\/p>\n
    <\/p>\n
    Reiter\u0103m. Am spus pod-ului s\u0103 vin\u0103 pe master, s\u0103 ob\u021bin\u0103 acolo hostNetwork \u0219i hostPID \u2014 \u0219i s\u0103 monteze \u00eentregul root al master-ului \u00een acest pod. <\/p>\n
    <\/p>\n
    \u00cen\u021belegi c\u0103 \u00een Debian avem bash-ul pornit, \u0219i acest bash func\u021bioneaz\u0103 sub root. Asta \u00eenseamn\u0103 c\u0103 tocmai am ob\u021binut root pe master, f\u0103r\u0103 a avea vreo autoritate \u00een cluster-ul Kubernetes.<\/p>\n
    <\/p>\n
    Apoi, toat\u0103 sarcina este s\u0103 intri \u00een pod \u00een directorul \/host \/etc\/kubernetes\/pki, dac\u0103 nu m\u0103 \u00een\u0219el, \u0219i s\u0103 iei toate certificatele master-ului din cluster \u0219i, prin urmare, s\u0103 devii administratorul cluster-ului. <\/p>\n
    <\/p>\n
    Dac\u0103 st\u0103m s\u0103 ne uit\u0103m, acestea sunt unele dintre cele mai periculoase drepturi \u00een pod-uri \u2014 indiferent de drepturile utilizatorului:
    \n\"Umplem<\/p>\n
    <\/p>\n
    Dac\u0103 am dreptul s\u0103 pornesc un pod \u00eentr-un anumit namespace al cluster-ului, atunci acest pod are acele drepturi implicit. Pot rula pod-uri privilegiate, ceea ce \u00eenseamn\u0103 practic toate drepturile, aproape root pe nod. <\/p>\n
    <\/p>\n
    Favoritul meu \u2014 utilizatorul Root. \u0218i Kubernetes are aceast\u0103 op\u021biune Run As Non-Root. Este o form\u0103 de protec\u021bie \u00eempotriva hackerului. \u0218ti\u021bi ce este un \"virus moldovenesc\"? Dac\u0103 e\u0219ti hacker \u0219i ai intrat \u00een cluster-ul meu Kubernetes, atunci noi, s\u0103racii administratori, cerem: \u201eV\u0103 rug\u0103m, specifica\u021bi \u00een pod-urile dvs. cu care ve\u021bi hack-ui cluster-ul meu, s\u0103 rula\u021bi ca non-root. Altfel, ar putea s\u0103 se \u00eent\u00e2mple c\u0103 ve\u021bi porni un proces \u00een pod-ul dvs. sub root, iar astfel va fi foarte simplu s\u0103 m\u0103 hack-ui\u021bi. Proteja\u021bi-v\u0103, v\u0103 rug\u0103m, singuri.\u201d <\/p>\n
    <\/p>\n
    Host path volume \u2014 din punctul meu de vedere, este cea mai rapid\u0103 modalitate de a ob\u021bine rezultatul dorit de la cluster-ul Kubernetes. <\/p>\n
    <\/p>\n
    Dar ce s\u0103 facem cu toate acestea? <\/p>\n
    <\/p>\n
    G\u00e2nduri care ar trebui s\u0103 vin\u0103 oric\u0103rui administrator normal care se confrunt\u0103 cu Kubernetes: \u201eAha, am spus eu, Kubernetes nu func\u021bioneaz\u0103. Are sl\u0103biciuni. Tot Kubernetesul e o prostie\u201d. De fapt, exist\u0103 un lucru numit documenta\u021bie, iar dac\u0103 prive\u0219ti acolo, exist\u0103 o sec\u021biune Politica de Securitate a Pod-urilor<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Acesta este un obiect yaml - pe care \u00eel putem crea \u00een clusterul Kubernetes - care controleaz\u0103 aspectele de securitate \u00een descrierea pod-urilor. Practic, el controleaz\u0103 drepturile de utilizare a diferitelor hostNetwork, hostPID, anumite tipuri de volume care exist\u0103 \u00een pod-uri la lansare. Cu ajutorul Politicii de Securitate a Pod-urilor, toate acestea pot fi descrise. <\/p>\n
    <\/p>\n
    Cel mai interesant \u00een Politica de Securitate a Pod-urilor este c\u0103 \u00een clusterul Kubernetes, toate instan\u021bele PSP nu sunt descrise \u00een niciun fel \u0219i sunt dezactivate din start. Politica de Securitate a Pod-urilor se activeaz\u0103 printr-un plugin de admitere.<\/p>\n
    <\/p>\n
    Ok, s\u0103 implement\u0103m Politica de Securitate a Pod-urilor \u00een cluster, s\u0103 spunem c\u0103 avem anumite pod-uri de serviciu \u00een namespace, la care au acces doar administratorii. S\u0103 spunem c\u0103 \u00een rest, pod-urile au drepturi limitate. Probabil c\u0103 dezvoltatorilor nu le-ar trebui s\u0103 ruleze pod-uri privilegiate \u00een clusterul vostru. <\/p>\n
    <\/p>\n
    \u0218i p\u0103rea c\u0103 totul este \u00een regul\u0103. \u0218i clusterul nostru Kubernetes nu poate fi spart \u00een dou\u0103 minute. <\/p>\n
    <\/p>\n
    Exist\u0103 o problem\u0103. Probabil c\u0103, dac\u0103 ave\u021bi un cluster Kubernetes, atunci \u00een clusterul vostru este instalat un sistem de monitorizare. M\u0103 aventurez s\u0103 prev\u0103d c\u0103, dac\u0103 \u00een clusterul voastre exist\u0103 monitorizare, acesta se nume\u0219te Prometheus. <\/p>\n
    <\/p>\n
    Ceea ce voi povesti acum va fi valabil at\u00e2t pentru operatorul Prometheus, c\u00e2t \u0219i pentru Prometheus instalat \u00een mod curat. Problema este c\u0103, dac\u0103 nu pot ob\u021bine rapid un administrator \u00een cluster, atunci asta \u00eenseamn\u0103 c\u0103 trebuie s\u0103 caut mai mult. \u0218i pot c\u0103uta cu ajutorul monitoriz\u0103rii voastre.<\/p>\n
    <\/p>\n
    Probabil c\u0103 toat\u0103 lumea a citit acelea\u0219i articole pe Habr \u0219i monitorizarea se afl\u0103 \u00een namespace-ul monitoring. Helm chart-urile tuturor se numesc aproximativ la fel. M\u0103 a\u0219tept ca, dac\u0103 face\u021bi helm install stable\/prometheus, ve\u021bi ob\u021bine nume aproximativ identice. \u0218i cel mai probabil, nu va trebui s\u0103 ghicesc numele DNS \u00een clusterul vostru. Pentru c\u0103 este standard. <\/p>\n
    <\/p>\n
    \"Umplem<\/p>\n
    <\/p>\n
    Mai departe, avem un anumit namespace de dev, \u00een care putem lansa un anumit pod. \u0218i apoi, din acest pod, este foarte u\u0219or s\u0103 facem a\u0219a: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics este unul dintre exportatorii Prometheus, care colecteaz\u0103 metrici din API-ul Kubernetes-ului. Exist\u0103 multe date despre ceea ce este activ \u00een clusterul dvs., ce este \u0219i ce probleme ave\u021bi cu acesta. <\/p>\n
    <\/p>\n
    Ca un exemplu simplu: <\/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
    F\u0103c\u00e2nd o solicitare curl simpl\u0103 dintr-un pod neprivilegiat, pute\u021bi ob\u021bine astfel de informa\u021bii. Dac\u0103 nu \u0219ti\u021bi ce versiune de Kubernetes ave\u021bi, acesta v\u0103 va spune cu u\u0219urin\u021b\u0103. <\/p>\n
    <\/p>\n
    \u0218i cel mai interesant este c\u0103, pe l\u00e2ng\u0103 faptul c\u0103 v\u0103 adresa\u021bi kube-state-metrics, pute\u021bi s\u0103 v\u0103 adresa\u021bi, la fel de bine, \u0219i direct lui Prometheus. Pute\u021bi aduna metrici de acolo. Chiar pute\u021bi construi metrici de acolo. Teoretic, chiar pute\u021bi construi o astfel de solicitare din cluster c\u0103tre Prometheus, care pur \u0219i simplu \u00eel va opri. \u0218i monitorizarea dvs. va \u00eenceta complet s\u0103 func\u021bioneze \u00een cluster. <\/p>\n
    <\/p>\n
    \u0218i aici se pune \u00eentrebarea dac\u0103 un anumit monitor extern v\u0103 monitorizeaz\u0103 monitorizarea. Tocmai am ob\u021binut posibilitatea de a ac\u021biona \u00een clusterul Kubernetes f\u0103r\u0103 consecin\u021be pentru mine. Chiar nu ve\u021bi afla c\u0103 eu ac\u021bionez acolo, deoarece monitorizarea nu mai exist\u0103. <\/p>\n
    <\/p>\n
    La fel ca \u0219i cu PSP, exist\u0103 senza\u021bia c\u0103 problema este c\u0103 toate aceste tehnologii moderne \u2014 Kubernetes, Prometheus \u2014 pur \u0219i simplu nu func\u021bioneaz\u0103 \u0219i sunt pline de bre\u0219e. De fapt, nu este a\u0219a. <\/p>\n
    <\/p>\n
    Exist\u0103 ceva numit \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Dac\u0103 sunte\u021bi un administrator obi\u0219nuit, probabil \u0219ti\u021bi despre Network Policy, c\u0103 este un alt yaml, care \u00een cluster exist\u0103 \u00eentr-un num\u0103r mare. \u0218i Network Policies nu sunt cu siguran\u021b\u0103 necesare. Chiar dac\u0103 a\u021bi citit ceea ce este Network Policy, c\u0103 este un firewall yaml al Kubernetes-ului, care permite restric\u021bionarea accesului \u00eentre namespace-uri, \u00eentre pod-uri, cu siguran\u021b\u0103 a\u021bi decis c\u0103 un firewall \u00een format yaml \u00een Kubernetes este doar o alt\u0103 abstrac\u021bie\u2026 Nu, nu este deloc necesar. <\/p>\n
    <\/p>\n
    Chiar dac\u0103 exper\u021bii dvs. \u00een securitate nu au fost informa\u021bi c\u0103 cu ajutorul Kubernetes-ului se poate construi foarte u\u0219or un firewall, \u0219i anume unul foarte granular. Dac\u0103 \u00eenc\u0103 nu \u0219tiu acest lucru \u0219i nu v\u0103 trag de m\u00e2nec\u0103: \u201eHai, d\u0103-ne...\u201d. Totu\u0219i, \u00een orice caz, ave\u021bi nevoie de Network Policy pentru a restric\u021biona accesul la anumite loca\u021bii de serviciu, care pot fi accesate din clusterul dvs., f\u0103r\u0103 a avea vreo autorizare. <\/p>\n
    <\/p>\n
    A\u0219a cum am men\u021bionat \u00een exemplul meu, se poate accesa kube state metrics din orice namespace din clusterul Kubernetes, f\u0103r\u0103 a avea nimic de spus. Politicile de re\u021bea au restric\u021bionat accesul din toate celelalte namespace-uri c\u0103tre namespace-ul de monitorizare \u0219i cam asta e: f\u0103r\u0103 acces, f\u0103r\u0103 probleme. \u00cen toate diagrama pe care le avem, at\u00e2t pentru Prometheus standard, c\u00e2t \u0219i pentru cel care se afl\u0103 \u00een operator, exist\u0103 pur \u0219i simplu \u00een values de helm o op\u021biune de a activa politicile de re\u021bea pentru ele. Trebuie doar s\u0103 le activa\u021bi, iar ele vor func\u021biona. <\/p>\n
    <\/p>\n
    Aici exist\u0103, totu\u0219i, o problem\u0103. Fiind un administrator competent, probabil c\u0103 a\u021bi decis c\u0103 politicile de re\u021bea nu sunt necesare. \u0218i citind diverse articole pe resurse precum Habr, a\u021bi ajuns la concluzia c\u0103 flannel, \u00een special \u00een modul host-gateway \u2014 este cea mai bun\u0103 alegere pe care o pute\u021bi face. <\/p>\n
    <\/p>\n
    Ce s\u0103 fac? <\/p>\n
    <\/p>\n
    Pute\u021bi \u00eencerca s\u0103 redeploya\u021bi solu\u021bia de re\u021bea care se afl\u0103 \u00een clusterul dvs. Kubernetes, s\u0103 \u00eencerca\u021bi s\u0103 o \u00eenlocui\u021bi cu ceva mai func\u021bional. De exemplu, cu Calico. Dar vreau s\u0103 spun imediat, sarcina de a schimba solu\u021bia de re\u021bea \u00eentr-un cluster Kubernetes activ \u2014 este destul de complicat\u0103. Eu am rezolvat-o de dou\u0103 ori (ambele ori, de altfel, teoretic), dar chiar \u0219i la Slyrms am ar\u0103tat cum s\u0103 facem acest lucru. Le-am ar\u0103tat celor care se \u00eenva\u021b\u0103 cum s\u0103 schimbe solu\u021bia de re\u021bea \u00een clusterul Kubernetes. \u00cen principiu, pute\u021bi \u00eencerca s\u0103 face\u021bi astfel \u00eenc\u00e2t s\u0103 nu existe timp de nefunc\u021bionare \u00een clusterul de produc\u021bie. Dar probabil c\u0103 nu ve\u021bi reu\u0219i. <\/p>\n
    <\/p>\n
    \u0218i problema, de fapt, se rezolv\u0103 foarte simplu. \u00cen cluster exist\u0103 certificate, \u0219i \u0219ti\u021bi c\u0103 aceste certificate vor expira \u00een decurs de un an. Ei bine, de obicei, solu\u021bia normal\u0103 pentru certificate \u00een cluster este \u2014 de ce ne-am stresa, ridic\u0103m un nou cluster l\u00e2ng\u0103 cel vechi, iar \u00een cel vechi s\u0103 expire, \u0219i apoi redeploy\u0103m totul. Dar, c\u00e2nd va expira, va fi o zi \u00een care totul va sta, dar m\u0103car avem un nou cluster. <\/p>\n
    <\/p>\n
    C\u00e2nd ve\u021bi ridica un nou cluster, nu uita\u021bi s\u0103 include\u021bi Calico \u00een loc de flannel. <\/p>\n
    <\/p>\n
    Ce s\u0103 faci dac\u0103 ai certificate emise pe o sut\u0103 de ani \u0219i nu inten\u021bionezi s\u0103 redeploiezi clusterul? Exist\u0103 un instrument numit Kube-RBAC-Proxy. Este o dezvoltare foarte interesant\u0103, care permite s\u0103 te integrezi ca un container sidecar \u00een orice pod din clusterul Kubernetes. Aceasta adaug\u0103, de fapt, autorizare prin RBAC-ul propriu al Kubernetes acestui pod. <\/p>\n
    <\/p>\n
    Exist\u0103 o problem\u0103. Anterior, acest instrument Kube-RBAC-Proxy era integrat \u00een operatorul Prometheus. Dar nu mai exist\u0103. Acum, versiunile moderne se bazeaz\u0103 pe faptul c\u0103 ai o politic\u0103 de re\u021bea \u0219i le \u00eenchizi prin intermediul acestora. A\u0219adar, va trebui s\u0103 rescrii pu\u021bin chart-ul. De fapt, dac\u0103 intri \u00een acest repository<\/a><\/noindex>, acolo sunt exemple despre cum s\u0103-l folose\u0219ti ca sidecars, \u0219i chart-urile vor trebui rescrise minim. <\/p>\n
    <\/p>\n
    Exist\u0103 \u0219i o alt\u0103 problem\u0103 mic\u0103. Nu doar Prometheus \u00ee\u0219i ofer\u0103 metricile oricui. Toate componentele clusterului Kubernetes \u0219tiu de asemenea s\u0103-\u0219i ofere metricile. <\/p>\n
    <\/p>\n
    Dar, a\u0219a cum am spus, dac\u0103 nu po\u021bi accesa clusterul \u0219i aduna informa\u021bii, cel pu\u021bin po\u021bi provoca daune. <\/p>\n
    <\/p>\n
    A\u0219a c\u0103 v\u0103 voi ar\u0103ta rapid dou\u0103 moduri \u00een care po\u021bi afecta s\u0103n\u0103tatea unui cluster Kubernetes. <\/p>\n
    <\/p>\n
    Ve\u021bi r\u00e2de c\u00e2nd o voi povesti, sunt dou\u0103 cazuri din via\u021ba real\u0103. <\/p>\n
    <\/p>\n
    Primul mod. Epuizarea resurselor. <\/p>\n
    <\/p>\n
    Lans\u0103m \u00eenc\u0103 un pod special. Acesta va avea urm\u0103toarea sec\u021biune. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    A\u0219a cum \u0219ti\u021bi, requests reprezint\u0103 cantitatea de CPU \u0219i memorie rezervat\u0103 pe host pentru anumite poduri cu cereri. Dac\u0103 avem un host cu patru nuclee \u00een clusterul Kubernetes \u0219i un pod cu cereri de patru CPU \u00eei vine, atunci nu va mai putea veni alt pod cu cereri pe acest host. <\/p>\n
    <\/p>\n
    Dac\u0103 voi lansa un astfel de pod, apoi voi da comanda: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Atunci nimeni altcineva nu va putea s\u0103 se deploy-eze \u00een clusterul Kubernetes. Deoarece pe toate nodurile vor termina cererile. Astfel, eu voi opri clusterul vostru Kubernetes. Dac\u0103 fac asta seara, atunci deploy-urile pot fi oprite destul de mult timp. <\/p>\n
    <\/p>\n
    Dac\u0103 privim din nou documenta\u021bia Kubernetes, vom observa un element denumit Limit Range. Acesta stabile\u0219te resursele pentru obiectele din cluster. Pute\u021bi scrie un obiect Limit Range \u00een yaml, s\u0103-l aplica\u021bi \u00een anumite spa\u021bii de nume \u2014 \u0219i mai departe \u00een acest spa\u021biu de nume pute\u021bi spune c\u0103 ave\u021bi resurse pentru module care sunt implicite, maxime \u0219i minime.<\/p>\n
    <\/p>\n
    Folosind un astfel de mecanism, putem restric\u021biona utilizatorii \u00een anumite spa\u021bii de nume de produse \u00een ceea ce prive\u0219te posibilitatea de a specifica resurse inadecvate pentru modulele lor. Dar, din p\u0103cate, chiar dac\u0103 \u00eei spune\u021bi utilizatorului c\u0103 nu poate rula module cu cereri mai mari de un CPU, exist\u0103 o comand\u0103 minunat\u0103 numit\u0103 scale, sau pot face scaling prin dashboard.<\/p>\n
    <\/p>\n
    \u0218i de aici decurge metoda num\u0103rul doi. Rul\u0103m 11 111 111 111 111 module. Aceasta reprezint\u0103 unsprezece miliarde. Nu este deoarece am inventat eu un astfel de num\u0103r, ci pentru c\u0103 am v\u0103zut cu ochii mei. <\/p>\n
    <\/p>\n
    O poveste real\u0103. Seara t\u00e2rziu, m\u0103 preg\u0103team s\u0103 plec din birou. Am observat \u00een col\u021b o grup\u0103 de dezvoltatori care f\u0103ceau ceva frenetic cu laptopurile. M-am apropiat de ei \u0219i i-am \u00eentrebat: \u201eCe s-a \u00eent\u00e2mplat?\u201d<\/p>\n
    <\/p>\n
    Cu pu\u021bin timp \u00eenainte, \u00een jurul orei nou\u0103 seara, unul dintre dezvoltatori se preg\u0103tea s\u0103 plece acas\u0103. \u0218i a decis: \u201eVoi scala acum aplica\u021bia mea la un singur modul.\u201d A ap\u0103sat pe \u201e1\u201d, iar internetul s-a \u00eencetinit pu\u021bin. A mai ap\u0103sat o dat\u0103 pe \u201e1\u201d, a ap\u0103sat din nou pe \u201e1\u201d, a dat clic pe Enter. A \u00eencercat tot ce a putut. Apoi internetul \u0219i-a revenit \u2014 \u0219i totul a \u00eenceput s\u0103 se scaleze la acel num\u0103r. <\/p>\n
    <\/p>\n
    Adev\u0103rul este c\u0103 aceast\u0103 poveste nu se desf\u0103\u0219ura pe Kubernetes, ci pe Nomad \u00een acel moment. S-a finalizat cu faptul c\u0103 dup\u0103 o or\u0103 de \u00eencerc\u0103ri de a opri Nomad de la insisten\u021bele sale de scalare, Nomad a r\u0103spuns c\u0103 nu se va opri din scalare \u0219i nu va face nimic altceva. \u201eSunt obosit, plec.\u201d \u0219i s-a retras. <\/p>\n
    <\/p>\n
    Desigur, am \u00eencercat s\u0103 fac acela\u0219i lucru pe Kubernetes. Unsprezece miliarde de module nu l-au \u00eenc\u00e2ntat pe Kubernetes, care a spus: \u201eNu pot. Dep\u0103\u0219e\u0219te capele interne.\u201d \u00cens\u0103 1 000 000 000 de module a reu\u0219it. <\/p>\n
    <\/p>\n
    \u00cen r\u0103spuns la un miliard de poduri, Kubernetes nu a fost afectat. A \u00eenceput cu adev\u0103rat s\u0103 scaleze. Cu c\u00e2t procesul avansa, cu at\u00e2t mai mult timp era necesar pentru a crea noi poduri. Totu\u0219i, procesul continua. Problema unic\u0103 este c\u0103, dac\u0103 pot rula poduri nelimitat \u00een spa\u021biul meu de nume, chiar \u0219i f\u0103r\u0103 limite de solicitare \u0219i limit\u0103ri, pot s\u0103 lansez at\u00e2t de multe poduri cu sarcini, \u00eenc\u00e2t nodurile vor \u00eencepe s\u0103 sufere din cauza memoriei \u0219i a CPU-ului. Atunci c\u00e2nd lansez at\u00e2t de multe poduri, informa\u021bia din acestea trebuie s\u0103 ajung\u0103 \u00een stocare, adic\u0103 etcd. Iar c\u00e2nd prea multe informa\u021bii ajung acolo, stocarea \u00eencepe s\u0103 r\u0103spund\u0103 mult mai \u00eencet \u2013 \u0219i Kubernetes \u00eencepe s\u0103 aib\u0103 probleme de performan\u021b\u0103. <\/p>\n
    <\/p>\n
    \u0218i mai exist\u0103 o problem\u0103... A\u0219a cum \u0219ti\u021bi, componentele de control ale Kubernetes nu sunt un singur element central, ci mai multe componente. Printre acestea se afl\u0103 managerul de control, scheduler-ul \u0219i a\u0219a mai departe. Toate aceste componente vor \u00eencepe s\u0103 execute simultan o munc\u0103 inutil\u0103 \u0219i confuz\u0103, care, \u00een timp, va \u00eencepe s\u0103 ocupe din ce \u00een ce mai mult timp. Managerul de control va crea noi poduri. Scheduler-ul va \u00eencerca s\u0103 g\u0103seasc\u0103 o nou\u0103 nod\u0103 pentru acestea. Noile noduri din clusterul dvs. se vor epuiza foarte cur\u00e2nd. Clusterul Kubernetes va \u00eencepe s\u0103 func\u021bioneze din ce \u00een ce mai lent.<\/p>\n
    <\/p>\n
    Dar am decis s\u0103 merg \u0219i mai departe. A\u0219a cum \u0219ti\u021bi, \u00een Kubernetes exist\u0103 ceva numit serviciu. De obicei, \u00een cluster-urile dvs., serviciul func\u021bioneaz\u0103 prin intermediul ip tables. <\/p>\n
    <\/p>\n
    Dac\u0103 lansezi un miliard de poduri, de exemplu, \u0219i apoi, cu ajutorul unui script, for\u021bezi Kubernetes s\u0103 creeze noi servicii: <\/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
    Pe toate nodurile din cluster, aproximativ simultan, vor fi generate din ce \u00een ce mai multe reguli iptables. \u00cen plus, pentru fiecare serviciu vor fi generate un miliard de reguli iptables. <\/p>\n
    <\/p>\n
    Am testat totul pe c\u00e2teva mii, p\u00e2n\u0103 la o zecime. \u0218i problema este c\u0103, deja la acest prag, conectarea SSH la nod devine destul de problematic\u0103. Deoarece pachetele, trec\u00e2nd printr-un astfel de num\u0103r de lan\u021buri, \u00eencep s\u0103 aib\u0103 dificult\u0103\u021bi. <\/p>\n
    <\/p>\n
    \u0218i asta se rezolv\u0103 tot cu ajutorul Kubernetes. Este unul dintre obiectele Resource quota. Acesta stabile\u0219te cantitatea de resurse \u0219i obiecte disponibile pentru namespace-ul din cluster. Putem crea un obiect yaml \u00een fiecare namespace al cluster-ului Kubernetes. Cu ajutorul acestui obiect, putem specifica c\u0103 pentru acest namespace sunt alocate un anumit num\u0103r de cereri, limite \u0219i apoi putem spune c\u0103 \u00een acest namespace pot fi create 10 servicii \u0219i 10 pod-uri. Iar dezvoltatorul nu poate dep\u0103\u0219i aceste limite. Kubernetes \u00eei va spune: \u201eNu po\u021bi scala pod-urile tale p\u00e2n\u0103 la acest num\u0103r, deoarece dep\u0103\u0219e\u0219te cota de resurse\u201d. Asta e, problema s-a rezolvat. Documenta\u021bia este aici<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    O problem\u0103 problematic\u0103 legat\u0103 de acest lucru apare. Sim\u021bi\u021bi c\u00e2t de greu devine s\u0103 crea\u021bi un namespace \u00een Kubernetes. Pentru a-l crea, trebuie s\u0103 \u021binem cont de o mul\u021bime de lucruri.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Cre\u0103m un namespace
    \n\u2022 Cre\u0103m \u00een interior limitrange
    \n\u2022 Cre\u0103m \u00een interior resourcequota
    \n\u2022 Cre\u0103m un serviceaccount pentru CI
    \n\u2022 Cre\u0103m rolebinding pentru CI \u0219i utilizatori
    \n\u2022 Op\u021bional, lans\u0103m pod-urile de servicii necesare <\/p>\n
    <\/p>\n
    A\u0219a c\u0103, profit\u00e2nd de ocazie, a\u0219 dori s\u0103 \u00eemp\u0103rt\u0103\u0219esc dezvolt\u0103rile mele. Exist\u0103 o unealt\u0103 numit\u0103 operator SDK. Este un mod de a scrie operatori \u00een cluster-ul Kubernetes. Pute\u021bi scrie operatori folosind Ansible.<\/p>\n
    <\/p>\n
    Ini\u021bial a fost scris \u00een Ansible, iar apoi am observat c\u0103 exist\u0103 operator SDK \u0219i am rescris rolul Ansible \u00een operator. Acest operator permite crearea \u00eentr-un cluster Kubernetes a unui obiect numit comand\u0103. \u00cen interiorul comenzii permite descrierea mediului \u00een format yaml pentru aceast\u0103 comand\u0103. \u0218i \u00een interiorul mediului comenzii permite descrierea resurselor alocate. <\/p>\n
    <\/p>\n
    Mic facilitate pentru \u00eentregul acest proces complex<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    \u0218i \u00een concluzie, ce s\u0103 facem cu toate acestea?
    \n\u00cen primul r\u00e2nd. Pod Security Policy - este o idee bun\u0103. \u0218i de\u0219i niciunul dintre instalatorii Kubernetes nu le folose\u0219te p\u00e2n\u0103 \u00een prezent, totu\u0219i trebuie s\u0103 le folosi\u021bi \u00een clusterele voastre. <\/p>\n
    <\/p>\n
    Network Policy - aceasta nu este o alt\u0103 caracteristic\u0103 inutil\u0103. Este ceva ce este cu adev\u0103rat necesar \u00een cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota - ar fi timpul s\u0103 le folosi\u021bi. Noi am \u00eenceput s\u0103 le folosim de mult timp \u0219i am crezut mult timp c\u0103 to\u021bi le aplic\u0103. Se pare c\u0103 este o raritate. <\/p>\n
    <\/p>\n
    \u00cen afar\u0103 de ceea ce am men\u021bionat \u00een prezentare, exist\u0103 caracteristici nedocumentate care permit atacarea clusterului. Recent a fost publicat\u0103 o analiz\u0103 extins\u0103 a vulnerabilit\u0103\u021bilor Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Unele lucruri sunt at\u00e2t de triste \u0219i frustrante. De exemplu, \u00een anumite condi\u021bii, kubeletele din clusterul Kubernetes pot expune con\u021binutul directorului warlocks, chiar \u0219i utilizatorilor neautorizati. <\/p>\n
    <\/p>\n
    Aici<\/a><\/noindex> exist\u0103 instruc\u021biuni despre cum s\u0103 reproduce\u021bi tot ce am discutat. Sunt fi\u0219iere cu exemple din produc\u021bie, cum ar fi cum arat\u0103 ResourceQuota \u0219i Pod Security Policy. \u0218i toate acestea pot fi testate. <\/p>\n
    <\/p>\n
    Mul\u021bumesc tuturor.<\/p>\n
    Sursa: 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\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\udd47\u00cenchidem bre\u0219ele din clusterul Kubernetes. Prezentare \u0219i transcriere de la DevOpsConf | ProHoster","description":"Pavel Selivanov, arhitect de solu\u021bii la Southbridge \u0219i profesor la Slyerma, a sus\u021binut o prezentare la DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}