{"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\/cs\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Zaslepeme d\u00edry v clusteru Kubernetes. P\u0159edn\u00e1\u0161ka a p\u0159epis z DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, architekt \u0159e\u0161en\u00ed ve Southbridge a lektor Slery, p\u0159ednesl p\u0159edn\u00e1\u0161ku na DevOpsConf 2019. Tato p\u0159edn\u00e1\u0161ka je sou\u010d\u00e1st\u00ed jednoho z t\u00e9mat pokro\u010dil\u00e9ho kurzu Kubernetes \u201eSlery Mega\u201d.<\/p>\n

<\/p>\n

Slery Z\u00e1kladn\u00ed: \u00favod do Kubernetes<\/a><\/noindex> se kon\u00e1 v Moskv\u011b od 18. do 20. listopadu.
\nSlery Mega: pod pokli\u010dkou Kubernetes<\/a><\/noindex> \u2014 Moskva, 22. a\u017e 24. listopadu.
\nSlery Online: oba kurzy o Kubernetes<\/a><\/noindex> jsou dostupn\u00e9 kdykoli.<\/p>\n

\n

\r\n \"P\u0159ehr\u00e1t\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Pod \u010dl\u00e1nkem \u2014 p\u0159epis p\u0159edn\u00e1\u0161ky.<\/p>\n

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

Dobr\u00fd den, kolegov\u00e9 a sympathici. Dnes budu mluvit o bezpe\u010dnosti.<\/p>\n

<\/p>\n

Vid\u00edm, \u017ee v s\u00e1le je dnes mnoho odborn\u00edk\u016f na bezpe\u010dnost. Omlouv\u00e1m se p\u0159edem, pokud n\u011bkter\u00e9 term\u00edny ze sv\u011bta bezpe\u010dnosti nebudu pou\u017e\u00edvat p\u0159esn\u011b tak, jak jste zvykl\u00ed. <\/p>\n

<\/p>\n

P\u0159ed p\u016fl rokem mi do rukou p\u0159i\u0161el jeden ve\u0159ejn\u00fd cluster Kubernetes. Ve\u0159ejn\u00fd \u2014 to znamen\u00e1, \u017ee tam je ur\u010dit\u00e9 mno\u017estv\u00ed namespaces, v t\u011bchto namespaces jsou u\u017eivatel\u00e9, izolovan\u00ed ve sv\u00e9m namespace. V\u0161ichni tito u\u017eivatel\u00e9 pat\u0159\u00ed r\u016fzn\u00fdm spole\u010dnostem. P\u0159edpokl\u00e1dalo se, \u017ee tento cluster bude pou\u017eit jako CDN. To znamen\u00e1, \u017ee v\u00e1m daj\u00ed cluster, daj\u00ed v\u00e1m tam u\u017eivatele, p\u0159ijdete do sv\u00e9ho namespace a deployujete sv\u00e9 fronty. <\/p>\n

<\/p>\n

M\u00e9mu p\u0159edchoz\u00edmu zam\u011bstnavateli se pokusili takovou slu\u017ebu prodat. A po\u017e\u00e1dali m\u011b, abych otestoval, zda je takov\u00e9 \u0159e\u0161en\u00ed vhodn\u00e9. <\/p>\n

<\/p>\n

P\u0159i\u0161el jsem do tohoto clusteru. Dali mi omezen\u00e1 pr\u00e1va, omezen\u00fd namespace. Kluci tam ch\u00e1pali, co je bezpe\u010dnost. \u010cetli, co je Role-based access control (RBAC) u Kubernetes \u2014 a nastavili to tak, \u017ee jsem nemohl spou\u0161t\u011bt pody samostatn\u011b od deployments. Nepamatuji si \u00fakol, kter\u00fd jsem se sna\u017eil vy\u0159e\u0161it, kdy\u017e jsem spou\u0161t\u011bl pod bez deploymente, ale velmi jsem cht\u011bl spustit prost\u011b pod. Rozhodl jsem se, \u017ee se pod\u00edv\u00e1m, jak\u00e1 pr\u00e1va m\u00e1m v clusteru, co mohu a co nemohu, co tam nastavili. Ostatn\u011b v\u00e1m pov\u00edm, co m\u011bli v RBAC nastaveno \u0161patn\u011b. <\/p>\n

<\/p>\n

Poda\u0159ilo se mi, \u017ee za dv\u011b minuty jsem z\u00edskal admin p\u0159\u00edstup k jejich clusteru, pod\u00edval jsem se do v\u0161ech sousedn\u00edch namespaces, vid\u011bl tam b\u011b\u017e\u00edc\u00ed produk\u010dn\u00ed fronty spole\u010dnost\u00ed, kter\u00e9 ji\u017e tuto slu\u017ebu zakoupily a nasadily se. Sotva jsem se udr\u017eel, abych n\u011bkomu nevsunul na hlavn\u00ed str\u00e1nku n\u011bjak\u00e9 vulg\u00e1rn\u00ed slovo. <\/p>\n

<\/p>\n

Pov\u00edm p\u0159\u00edklady, jak jsem to ud\u011blal a jak se tomu br\u00e1nit. <\/p>\n

<\/p>\n

Nejprve se ale p\u0159edstav\u00edm. Jmenuji se Pavel Selivanov. Jsem architektem spole\u010dnosti Southbridge. Rozum\u00edm Kubernetes, DevOps a r\u016fzn\u00fdm modern\u00edm technologi\u00edm. Spolu s in\u017een\u00fdry ze Southbridge to v\u0161echno stav\u00edme, zat\u00edmco j\u00e1 poskytuju konzultace. <\/p>\n

<\/p>\n

Krom\u011b na\u0161\u00ed hlavn\u00ed \u010dinnosti jsme ned\u00e1vno zah\u00e1jili projekty, kter\u00e9 se naz\u00fdvaj\u00ed Slyrmy. Sna\u017e\u00edme se sd\u00edlet na\u0161e dovednosti v pr\u00e1ci s Kubernetes a u\u010dit ostatn\u00ed, jak pracovat s K8s. <\/p>\n

<\/p>\n

O \u010dem dnes budu mluvit. T\u00e9ma prezentace je jasn\u00e9 \u2014 o bezpe\u010dnosti Kubernetes cluster\u016f. Hned chci \u0159\u00edct, \u017ee tato t\u00e9ma je velmi rozs\u00e1hl\u00e9 \u2014 a proto chci p\u0159edem ujasnit, o \u010dem rozhodn\u011b mluvit nebudu. Nebudu mluvit o ohran\u00e9 terminologii, kter\u00e1 byla na internetu u\u017e stokr\u00e1t opakov\u00e1na. R\u016fzn\u00e9 RBAC a certifik\u00e1ty. <\/p>\n

<\/p>\n

Budu mluvit o probl\u00e9mech, kter\u00e9 j\u00e1 a moji kolegov\u00e9 m\u00e1me ohledn\u011b bezpe\u010dnosti Kubernetes cluster\u016f. Tyto probl\u00e9my vid\u00edme u poskytovatel\u016f, kte\u0159\u00ed nab\u00edzuj\u00ed Kubernetes clustery, a tak\u00e9 u klient\u016f, kte\u0159\u00ed k n\u00e1m p\u0159ich\u00e1zej\u00ed. A dokonce i u klient\u016f, kte\u0159\u00ed p\u0159ich\u00e1zej\u00ed k n\u00e1m od jin\u00fdch konzulta\u010dn\u00edch administrativn\u00edch spole\u010dnost\u00ed. Tak\u017ee rozsah trag\u00e9die je ve skute\u010dnosti velmi velk\u00fd. <\/p>\n

<\/p>\n

Doslova t\u0159i body, o kter\u00fdch dnes budu mluvit: <\/p>\n

<\/p>\n

    \n
  1. Pr\u00e1va u\u017eivatel\u016f vs pr\u00e1va pod\u016f. Pr\u00e1va u\u017eivatel\u016f a pr\u00e1va pod\u016f \u2014 to nejsou tot\u00e9\u017e. <\/li>\n
  2. Shroma\u017e\u010fov\u00e1n\u00ed informac\u00ed o clusteru. Uk\u00e1\u017eu, jak lze shrom\u00e1\u017edit v\u0161echny informace z clusteru, ani\u017e bychom m\u011bli speci\u00e1ln\u00ed pr\u00e1va v tomto clusteru. <\/li>\n
  3. DoS \u00fatok na cluster. Pokud nebudeme schopni shrom\u00e1\u017edit informace, budeme moci cluster p\u0159esto sabotovat. Budu mluvit o DoS \u00fatoc\u00edch na \u0159\u00eddic\u00ed prvky clusteru. <\/li>\n<\/ol>\n

    <\/p>\n

    Je\u0161t\u011b jedna obecn\u00e1 v\u011bc, o kter\u00e9 zm\u00edn\u00edm \u2014 na \u010dem jsem to v\u0161echno testoval, na \u010dem mohu s jistotou \u0159\u00edct, \u017ee to v\u0161echno funguje.<\/p>\n

    <\/p>\n

    Za z\u00e1klad bereme nasazen\u00ed clusteru Kubernetes pomoc\u00ed Kubespray. Pokud to n\u011bkdo nev\u00ed, je to vlastn\u011b sada rol\u00ed pro Ansible. V pr\u00e1ci ho neust\u00e1le pou\u017e\u00edv\u00e1me. Je dobr\u00fd t\u00edm, \u017ee lze nasadit kamkoli \u2014 na fyzick\u00e9 stroje, stejn\u011b jako do cloudu. Jeden zp\u016fsob nasazen\u00ed vyhovuje v podstat\u011b v\u0161emu. <\/p>\n

    <\/p>\n

    V tomto klastru budu m\u00edt Kubernetes v1.14.5. Cel\u00fd klastr Kubernetes, kter\u00fd budeme zva\u017eovat, je rozd\u011blen na namespacy, p\u0159i\u010dem\u017e ka\u017ed\u00fd namespace n\u00e1le\u017e\u00ed jin\u00e9 t\u00fdmu a \u010dlenov\u00e9 tohoto t\u00fdmu maj\u00ed p\u0159\u00edstup pouze do sv\u00e9ho namespace. Do r\u016fzn\u00fdch namespaces nemohou vstupovat. Ale existuje ur\u010dit\u00fd administrativn\u00ed \u00fa\u010det, kter\u00fd m\u00e1 pr\u00e1va na cel\u00fd klastr. <\/p>\n

    <\/p>\n

    \"Zaslepeme<\/p>\n

    <\/p>\n

    Sliboval jsem, \u017ee prvn\u00ed, co ud\u011bl\u00e1me, je z\u00edsk\u00e1n\u00ed administrativn\u00edch pr\u00e1v na klastr. Pot\u0159ebujeme speci\u00e1ln\u011b p\u0159ipraven\u00fd pod, kter\u00fd rozbije klastr Kubernetes. V\u0161echno, co mus\u00edme ud\u011blat, je aplikovat ho do klastra Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Tento pod k n\u00e1m p\u0159ijede na jeden z master\u016f klastru Kubernetes. A klastr n\u00e1m po tom r\u00e1do vr\u00e1t\u00ed soubor, kter\u00fd se naz\u00fdv\u00e1 admin.conf. V Kubernetes se v tomto souboru uchov\u00e1vaj\u00ed v\u0161echny certifik\u00e1ty admina a sou\u010dasn\u011b je nastaven API klastru. Takto jednodu\u0161e m\u016f\u017eete z\u00edskat administrativn\u00ed p\u0159\u00edstup, mysl\u00edm, \u017ee k 98% klastr\u016f Kubernetes. <\/p>\n
    <\/p>\n
    Opakuji, tento pod vytvo\u0159il jeden v\u00fdvoj\u00e1\u0159 ve va\u0161em klastru, kter\u00fd m\u00e1 p\u0159\u00edstup nasazovat sv\u00e9 nab\u00eddky v jednom mal\u00e9m namespace, cel\u00fd je z\u00fa\u017een RBAC. Nem\u011bl \u017e\u00e1dn\u00e1 pr\u00e1va. P\u0159esto certifik\u00e1t vr\u00e1til. <\/p>\n
    <\/p>\n
    A nyn\u00ed k speci\u00e1ln\u011b p\u0159\u00edpraven\u00e9mu podu. Spou\u0161t\u00edme na jak\u00e9mkoli obrazu. Nap\u0159\u00edklad pou\u017eijeme debian:jessie. <\/p>\n
    <\/p>\n
    M\u00e1me takovou v\u011bc: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Co je to toleration? Masterov\u00e9 uzly v klastru Kubernetes jsou obvykle ozna\u010deny n\u011b\u010d\u00edm, co se naz\u00fdv\u00e1 taint (\"z\u00e1roda\" v angli\u010dtin\u011b). A podstata t\u00e9to \"z\u00e1rody\" je takov\u00e1, \u017ee na masterov\u00e9 uzly nelze p\u0159i\u0159azovat pod. Ale nikdo nebr\u00e1n\u00ed v jak\u00e9mkoli podu uv\u00e9st, \u017ee je tolerantn\u00ed k \"z\u00e1rod\u011b\". Sekce Toleration \u0159\u00edk\u00e1, \u017ee pokud na n\u011bjak\u00e9m uzlu stoj\u00ed NoSchedule, pak je n\u00e1\u0161 pod tolerantn\u00ed k takov\u00e9 z\u00e1rod\u011b \u2014 a \u017e\u00e1dn\u00e9 probl\u00e9my. <\/p>\n
    <\/p>\n
    D\u00e1le \u0159\u00edk\u00e1me, \u017ee n\u00e1\u0161 pod nen\u00ed jen tolerantn\u00ed, ale tak\u00e9 chce b\u00fdt speci\u00e1ln\u011b p\u0159i\u0159azen na mastera. Proto\u017ee na masterech se nach\u00e1z\u00ed to nejzaj\u00edmav\u011bj\u0161\u00ed, co pot\u0159ebujeme \u2014 v\u0161echny certifik\u00e1ty. Proto \u0159\u00edk\u00e1me nodeSelector \u2014 a m\u00e1me standardn\u00ed label na masterech, kter\u00fd umo\u017e\u0148uje vybrat z v\u0161ech uzl\u016f klastru pr\u00e1v\u011b ty uzly, kter\u00e9 jsou mastery. <\/p>\n
    <\/p>\n
    S takov\u00fdmi dv\u011bma sekcemi pod ur\u010dit\u011b p\u0159ijede na master. A bude mu povoleno tam \u017e\u00edt. <\/p>\n
    <\/p>\n
    Ale jen p\u0159ij\u00edt na master n\u00e1m nesta\u010d\u00ed. To n\u00e1m nic ned\u00e1. Proto m\u00e1me d\u00e1le takov\u00e9 dv\u011b v\u011bci:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Uv\u00e1d\u00edme, \u017ee n\u00e1\u0161 pod, kter\u00fd spou\u0161t\u00edme, bude \u017e\u00edt v name space j\u00e1dra, v name space s\u00edt\u011b a v name space PID. Jakmile se pod spust\u00ed na masteru, bude moci vid\u011bt v\u0161echny skute\u010dn\u00e9, \u017eiv\u00e9 rozhran\u00ed tohoto uzlu, poslouchat ve\u0161ker\u00fd provoz a vid\u011bt PID v\u0161ech proces\u016f.<\/p>\n
    <\/p>\n
    D\u00e1le je to u\u017e jednoduch\u00e9. Vezmete etcd a \u010dtete, co chcete. <\/p>\n
    <\/p>\n
    Nejzaj\u00edmav\u011bj\u0161\u00ed je, \u017ee tuto schopnost m\u00e1 Kubernetes, kter\u00e1 tam je ve v\u00fdchoz\u00edm nastaven\u00ed. <\/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
    A jej\u00ed podstatou je, \u017ee m\u016f\u017eeme v podu, kter\u00fd spou\u0161t\u00edme, i bez pr\u00e1v na tento klastr, \u0159\u00edci, \u017ee chceme vytvo\u0159it volume typu hostPath. To znamen\u00e1 vz\u00edt cestu z hostitele, na kter\u00e9m se spust\u00edme \u2014 a vz\u00edt ji jako volume. A pot\u00e9 ji naz\u00fdv\u00e1me name: host. Cel\u00fd tento hostPath montujeme dovnit\u0159 podu. V tomto p\u0159\u00edkladu do adres\u00e1\u0159e \/host. <\/p>\n
    <\/p>\n
    Je\u0161t\u011b jednou opakuji. \u0158ekli jsme podu, aby p\u0159i\u0161el na master, z\u00edskal tam hostNetwork a hostPID \u2014 a cel\u00fd root masteru byl namontov\u00e1n dovnit\u0159 tohoto podu. <\/p>\n
    <\/p>\n
    Ch\u00e1pete, \u017ee v debianu m\u00e1me spu\u0161t\u011bn\u00fd bash, a tento bash n\u00e1m b\u011b\u017e\u00ed pod rootem. To znamen\u00e1, \u017ee jsme pr\u00e1v\u011b z\u00edskali roota na master, ani\u017e bychom m\u011bli n\u011bjak\u00e1 pr\u00e1va v klastru Kubernetes.<\/p>\n
    <\/p>\n
    Dal\u0161\u00edm \u00fakolem je dostat se do podu do adres\u00e1\u0159e \/host \/etc\/kubernetes\/pki, pokud se nem\u00fdl\u00edm, vz\u00edt tam v\u0161echny masterov\u00e9 certifik\u00e1ty klastru a st\u00e1t se tak administr\u00e1torem klastru. <\/p>\n
    <\/p>\n
    Pokud se na to pod\u00edv\u00e1te, to jsou jedno z nejnebezpe\u010dn\u011bj\u0161\u00edch pr\u00e1v v podech \u2014 bez ohledu na to, jak\u00e1 pr\u00e1va m\u00e1 u\u017eivatel:
    \n\"Zaslepeme<\/p>\n
    <\/p>\n
    Pokud m\u00e1m pr\u00e1vo spustit pod v n\u011bjak\u00e9m name space klastru, pak tento pod tato pr\u00e1va m\u00e1 v\u00fdchoz\u00ed. Mohu spou\u0161t\u011bt privilegovan\u00e9 pody, a to znamen\u00e1, \u017ee m\u00e1m prakticky v\u0161echna pr\u00e1va, t\u00e9m\u011b\u0159 root na uzlu. <\/p>\n
    <\/p>\n
    M\u016fj obl\u00edben\u00fd \u2014 Root u\u017eivatel. A Kubernetes m\u00e1 tuto mo\u017enost Run As Non-Root. To je takov\u00e1 ochrana proti hackerovi. V\u00ed\u0161, co je to \u201emoldavsk\u00fd virus\u201c? Pokud jste n\u00e1hodou hacker a p\u0159i\u0161li jste do m\u00e9ho klastru Kubernetes, pak my, chud\u00ed administr\u00e1to\u0159i, pros\u00edme: \u201ePros\u00edm, uve\u010fte ve sv\u00fdch podech, kter\u00fdmi budete hackovat m\u016fj klastr, run as non-root. Proto\u017ee tak by se mohlo st\u00e1t, \u017ee spust\u00edte proces ve sv\u00e9m pode pod rootem, a velmi snadno byste m\u011b mohli hacknout. Pros\u00edm, chra\u0148te se sami p\u0159ed sebou.\u201c <\/p>\n
    <\/p>\n
    Host path volume \u2014 podle m\u00e9ho n\u00e1zoru nejrychlej\u0161\u00ed zp\u016fsob, jak z\u00edskat po\u017eadovan\u00fd v\u00fdsledek z klastru Kubernetes. <\/p>\n
    <\/p>\n
    Co s t\u00edm v\u0161\u00edm d\u011blat? <\/p>\n
    <\/p>\n
    My\u0161lenky, kter\u00e9 by m\u011bly p\u0159ij\u00edt ka\u017ed\u00e9mu norm\u00e1ln\u00edmu administr\u00e1torovi, kter\u00fd se setk\u00e1v\u00e1 s Kubernetes: \u201eAha, j\u00e1 jsem \u0159\u00edkal, Kubernetes nefunguje. M\u00e1 v sob\u011b d\u00edry. A cel\u00fd Kubernetes je blbost.\u201c Ve skute\u010dnosti existuje n\u011bco jako dokumentace, a pokud se na ni pod\u00edv\u00e1te, najdete tam sekci Politika zabezpe\u010den\u00ed pod\u016f<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    To je takov\u00fd yaml-objekt \u2013 m\u016f\u017eeme ho vytv\u00e1\u0159et v klastru Kubernetes \u2013 kter\u00fd \u0159\u00edd\u00ed aspekty bezpe\u010dnosti t\u00fdkaj\u00edc\u00ed se samotn\u00fdch pod\u016f. To znamen\u00e1, \u017ee fakticky \u0159\u00edd\u00ed pr\u00e1va na pou\u017e\u00edv\u00e1n\u00ed r\u016fzn\u00fdch hostNetwork, hostPID, ur\u010dit\u00fdch typ\u016f volume, kter\u00e9 jsou v podech p\u0159i spu\u0161t\u011bn\u00ed. Pomoc\u00ed Politiky zabezpe\u010den\u00ed pod\u016f lze toto v\u0161echno popsat. <\/p>\n
    <\/p>\n
    Nejzaj\u00edmav\u011bj\u0161\u00ed na Politice zabezpe\u010den\u00ed pod\u016f je, \u017ee v klastru Kubernetes nejsou pro v\u0161echny instalace PSP v\u016fbec pops\u00e1ny; jsou zkr\u00e1tka ve v\u00fdchoz\u00edm nastaven\u00ed vypnut\u00e9. Politika zabezpe\u010den\u00ed pod\u016f se aktivuje prost\u0159ednictv\u00edm admission pluginu.<\/p>\n
    <\/p>\n
    Dob\u0159e, do klastru nasad\u00edme Politiku zabezpe\u010den\u00ed pod\u016f, \u0159ekn\u011bme, \u017ee m\u00e1me n\u011bjak\u00e9 provozn\u00ed pody v namespace, k n\u011bmu\u017e maj\u00ed p\u0159\u00edstup pouze administr\u00e1to\u0159i. \u0158ekn\u011bme, \u017ee ve v\u0161ech ostatn\u00edch podech maj\u00ed omezen\u00e1 pr\u00e1va. Proto\u017ee pravd\u011bpodobn\u011b v\u00fdvoj\u00e1\u0159i nemus\u00ed spou\u0161t\u011bt privilegovan\u00e9 pody ve va\u0161em klastru. <\/p>\n
    <\/p>\n
    A zd\u00e1 se, \u017ee v\u0161e je v po\u0159\u00e1dku. A n\u00e1\u0161 klastr Kubernetes nelze hacknout za dv\u011b minuty. <\/p>\n
    <\/p>\n
    Je tu probl\u00e9m. Pravd\u011bpodobn\u011b, pokud m\u00e1te klastr Kubernetes, m\u00e1te v n\u011bm nainstalovan\u00fd monitoring. Dokonce bych se odv\u00e1\u017eil p\u0159edpov\u011bd\u011bt, \u017ee pokud v va\u0161em klastru existuje monitoring, jmenuje se Prometheus. <\/p>\n
    <\/p>\n
    To, co te\u010f pov\u00edm, bude platn\u00e9 jak pro Prometheus-operator, tak i pro \u010distou instalaci Prometheus. Ot\u00e1zka je, \u017ee pokud nemohu rychle z\u00edskat administr\u00e1tora do klastru, znamen\u00e1 to, \u017ee mus\u00edm v\u00edce hledat. A hledat mohu s pomoc\u00ed va\u0161eho monitoringu.<\/p>\n
    <\/p>\n
    Pravd\u011bpodobn\u011b v\u0161ichni \u010detli stejn\u00e9 \u010dl\u00e1nky na habru a monitoring se nach\u00e1z\u00ed v namespace monitoring. Helm chart maj\u00ed v\u0161ichni zhruba stejn\u00e9. P\u0159edpokl\u00e1d\u00e1m, \u017ee pokud provedete helm install stable\/prometheus, dostanete zhruba stejn\u00e9 n\u00e1zvy. A dokonce pravd\u011bpodobn\u011b nebudu muset h\u00e1dat DNS-n\u00e1zev ve va\u0161em klastru. Proto\u017ee je standardn\u00ed. <\/p>\n
    <\/p>\n
    \"Zaslepeme<\/p>\n
    <\/p>\n
    D\u00e1le m\u00e1me n\u011bjak\u00fd dev ns, v n\u011bm\u017e lze spustit n\u011bjak\u00fd pod. A pot\u00e9 z tohoto podu je velmi snadn\u00e9 ud\u011blat toto: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics je jedn\u00edm z exporter\u016f Prometheuse, kter\u00fd sb\u00edr\u00e1 metriky z API samotn\u00e9ho Kubernetes. Existuje spousta dat o tom, co m\u00e1te spu\u0161t\u011bno ve va\u0161em clusteru, jak\u00e9 je to a jak\u00e9 s t\u00edm m\u00e1te probl\u00e9my. <\/p>\n
    <\/p>\n
    Jako jednoduch\u00fd p\u0159\u00edklad: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-system\u00bb,pod=\u00abkube-apiserver-k8s-1\u00bb,container=\u00abkube-apiserver\u00bb,image= <\/p>\n
    <\/p>\n
    \u00abgcr.io\/google-containers\/kube-apiserver:v1.14.5\u00bb <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\u00abdocker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\u00bb,container_id=\u00abdocker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\u00bb} 1 <\/p>\n
    <\/p>\n
    Proveden\u00edm jednoduch\u00e9ho curl po\u017eadavku z nep\u0159 privileged podu m\u016f\u017eete z\u00edskat informace, kter\u00e9 vypadaj\u00ed takto. Pokud nev\u00edte, v jak\u00e9 verzi Kubernetes b\u011b\u017e\u00edte, snadno v\u00e1m to pov\u00ed. <\/p>\n
    <\/p>\n
    A nejzaj\u00edmav\u011bj\u0161\u00ed na tom je, \u017ee krom\u011b toho, \u017ee se obrac\u00edte na kube-state-metrics, m\u016f\u017eete se stejn\u00fdm \u00fasp\u011bchem obr\u00e1tit i na samotn\u00fd Prometheus. M\u016f\u017eete z n\u011bj sb\u00edrat metriky. Dokonce m\u016f\u017eete z n\u011bj konstruovat metriky. Teoreticky m\u016f\u017eete vytvo\u0159it takov\u00fd po\u017eadavek z clusteru do Prometheusu, kter\u00fd ho prost\u011b vypne. A v\u00e1\u0161 monitoring p\u0159estane fungovat. <\/p>\n
    <\/p>\n
    A zde se ji\u017e objevuje ot\u00e1zka, zda n\u011bjak\u00fd extern\u00ed monitoring sleduje v\u00e1\u0161 monitoring. Pr\u00e1v\u011b jsem z\u00edskal mo\u017enost jednat v clusteru Kubernetes bez n\u00e1sledk\u016f pro sebe. Ani nepozn\u00e1te, \u017ee tam jedn\u00e1m, proto\u017ee monitoring u\u017e neexistuje. <\/p>\n
    <\/p>\n
    Stejn\u011b jako s PSP se zd\u00e1, \u017ee probl\u00e9m spo\u010d\u00edv\u00e1 v tom, \u017ee v\u0161echny tyto modern\u00ed technologie \u2014 Kubernetes, Prometheus \u2014 prost\u011b nefunguj\u00ed a jsou pln\u00e9 d\u011br. Ve skute\u010dnosti to tak nen\u00ed. <\/p>\n
    <\/p>\n
    Existuje takov\u00e1 v\u011bc \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Pokud jste norm\u00e1ln\u00ed administr\u00e1tor, pravd\u011bpodobn\u011b v\u00edte, \u017ee o Network Policy je to dal\u0161\u00ed yaml, kter\u00fdch je v clusteru u\u017e spousta. A n\u011bjak\u00e9 Network Policies rozhodn\u011b nejsou nutn\u00e9. A i kdybyste si p\u0159e\u010detli, co je to Network Policy, \u017ee to je yaml firewall Kubernetes, kter\u00fd umo\u017e\u0148uje omezit p\u0159\u00edstupov\u00e1 pr\u00e1va mezi namespacemi a mezi podi, ur\u010dit\u011b jste si rozmysleli, \u017ee firewall ve form\u00e1tu yaml v Kubernetes na dal\u0161\u00edch abstrakc\u00edch \u2026 Ne, to rozhodn\u011b nen\u00ed nutn\u00e9. <\/p>\n
    <\/p>\n
    I kdy\u017e va\u0161i bezpe\u010dnostn\u00ed specialist\u00e9 nev\u011bd\u00ed, \u017ee s pomoc\u00ed va\u0161eho Kubernetes m\u016f\u017eete snadno postavit velmi podrobnou firewall, pokud v\u00e1m to je\u0161t\u011b ne\u0159ekli a netla\u010d\u00ed v\u00e1s: \"No dejte, dejte...\" V ka\u017ed\u00e9m p\u0159\u00edpad\u011b pot\u0159ebujete Network Policy, abyste uzav\u0159eli p\u0159\u00edstup k n\u011bkter\u00fdm slu\u017eb\u00e1m, kter\u00e9 lze z va\u0161eho clusteru vy\u017e\u00e1dat bez jak\u00e9koliv autorizace. <\/p>\n
    <\/p>\n
    Jak jsem uvedl v p\u0159\u00edkladu, m\u016f\u017eete po\u017e\u00e1dat kube state metrics z jak\u00e9hokoli namespace v clusteru Kubernetes, ani\u017e byste k tomu m\u011bli jak\u00e1koliv opr\u00e1vn\u011bn\u00ed. Network policies uzav\u0159ely p\u0159\u00edstup ze v\u0161ech ostatn\u00edch namespace do monitorovac\u00edho namespace a jakoby v\u0161echno: bez p\u0159\u00edstupu, bez probl\u00e9m\u016f. Ve v\u0161ech chartech, kter\u00e9 jsou k dispozici, v standardn\u00edm Prometheovi i v Prometheovi, kter\u00fd je v operatorovi, je ve values Helmu mo\u017enost jednodu\u0161e zapnout network policies pro n\u011b. Je pot\u0159eba jen zapnout, a budou fungovat. <\/p>\n
    <\/p>\n
    Zde je v\u0161ak jedna pravda. Jako norm\u00e1ln\u00ed vousat\u00fd administr\u00e1tor jste pravd\u011bpodobn\u011b dosp\u011bli k n\u00e1zoru, \u017ee network policies nejsou pot\u0159eba. A po p\u0159e\u010dten\u00ed r\u016fzn\u00fdch \u010dl\u00e1nk\u016f na zdroj\u00edch typu Habr jste se rozhodli, \u017ee flannel, zejm\u00e9na v re\u017eimu host-gateway, je v\u016fbec to nejlep\u0161\u00ed, co m\u016f\u017eete zvolit. <\/p>\n
    <\/p>\n
    Co d\u011blat? <\/p>\n
    <\/p>\n
    M\u016f\u017eete se pokusit p\u0159e-deployovat s\u00ed\u0165ov\u00e9 \u0159e\u0161en\u00ed, kter\u00e9 m\u00e1te ve sv\u00e9m clusteru Kubernetes, a zkusit ho nahradit n\u011b\u010d\u00edm funk\u010dn\u011bj\u0161\u00edm. Nap\u0159\u00edklad t\u00edm sam\u00fdm Calico. Ale hned chci \u0159\u00edct, \u017ee \u00fakol zm\u011bnit s\u00ed\u0165ov\u00e9 \u0159e\u0161en\u00ed v pracovn\u00edm clusteru Kubernetes je docela nejednoduch\u00fd. \u0158e\u0161il jsem ho dvakr\u00e1t (oba p\u0159\u00edpady byly pravda teoreticky), ale dokonce jsme na Sluormu uk\u00e1zali, jak to ud\u011blat. Na\u0161im student\u016fm jsme ukazovali, jak zm\u011bnit s\u00ed\u0165ov\u00e9 \u0159e\u0161en\u00ed v clusteru Kubernetes. V z\u00e1sad\u011b se m\u016f\u017eete pokusit ud\u011blat to tak, abyste v produk\u010dn\u00edm clusteru nem\u011bli \u017e\u00e1dn\u00fd v\u00fdpadek. Ale pravd\u011bpodobn\u011b se v\u00e1m to nepoda\u0159\u00ed. <\/p>\n
    <\/p>\n
    A probl\u00e9m se skute\u010dn\u011b \u0159e\u0161\u00ed velmi jednodu\u0161e. V clusteru jsou certifik\u00e1ty, a v\u00edte, \u017ee certifik\u00e1ty v\u00e1m za rok vypr\u0161\u00ed. Tak\u017ee obvykl\u00e9 \u0159e\u0161en\u00ed s certifik\u00e1ty v clusteru je \u2013 pro\u010d si d\u011blat starosti, vedle postav\u00edme nov\u00fd cluster, a ve star\u00e9m a\u0165 vypr\u0161\u00ed, a v\u0161echno znovu deployneme. Pravda, kdy\u017e to vypr\u0161\u00ed, budeme m\u00edt den, kdy to v\u0161echno le\u017e\u00ed, ale p\u0159esto nov\u00fd cluster. <\/p>\n
    <\/p>\n
    A\u017e budete zvedat nov\u00fd cluster, nezapome\u0148te vlo\u017eit Calico m\u00edsto flannel. <\/p>\n
    <\/p>\n
    Co d\u011blat, pokud m\u00e1te certifik\u00e1ty vydan\u00e9 na sto let a nepl\u00e1nujete znovu nasadit cluster? Existuje n\u00e1stroj Kube-RBAC-Proxy. To je skv\u011bl\u00fd n\u00e1stroj, kter\u00fd se d\u00e1 integrovat jako sidecar container do jak\u00e9hokoli podu v clusteru Kubernetes. A v podstat\u011b p\u0159id\u00e1v\u00e1 k tomuto podu autorizaci p\u0159es RBAC samotn\u00e9ho Kubernetes. <\/p>\n
    <\/p>\n
    Je tu v\u0161ak jeden probl\u00e9m. D\u0159\u00edve bylo toto \u0159e\u0161en\u00ed Kube-RBAC-Proxy integrovan\u00e9 v Prometheus oper\u00e1toru. Ale pot\u00e9 se to ztratilo. Modern\u00ed verze se spol\u00e9haj\u00ed na to, \u017ee m\u00e1te network policy a pomoc\u00ed nich v\u0161e uzav\u00edr\u00e1te. A proto bude t\u0159eba trochu upravit chart. Ve skute\u010dnosti, pokud se pod\u00edv\u00e1te na tomto repozit\u00e1\u0159i<\/a><\/noindex>, najdete p\u0159\u00edklady, jak to pou\u017e\u00edvat jako sidecars, a chart bude pot\u0159eba upravit minim\u00e1ln\u011b. <\/p>\n
    <\/p>\n
    Je tu tak\u00e9 jeden mal\u00fd probl\u00e9m. Nejen Prometheus poskytuje sv\u00e9 metriky komukoli. V\u0161echny komponenty clusteru Kubernetes tak\u00e9 um\u00ed poskytovat sv\u00e9 metriky. <\/p>\n
    <\/p>\n
    Ale jak jsem ji\u017e \u0159ekl, pokud nem\u016f\u017eete z\u00edskat p\u0159\u00edstup k clusteru a shrom\u00e1\u017edit informace, m\u016f\u017eete alespo\u0148 u\u0161kodit. <\/p>\n
    <\/p>\n
    Tak\u017ee rychle uk\u00e1\u017eu dva zp\u016fsoby, jak m\u016f\u017eete Kubernetes clusteru po\u0161kodit zdrav\u00ed. <\/p>\n
    <\/p>\n
    Budete se sm\u00e1t, kdy\u017e to usly\u0161\u00edte, jsou to dva p\u0159\u00edklady z re\u00e1ln\u00e9ho \u017eivota. <\/p>\n
    <\/p>\n
    Prvn\u00ed zp\u016fsob. Vy\u010derp\u00e1n\u00ed zdroj\u016f. <\/p>\n
    <\/p>\n
    Spust\u00edme dal\u0161\u00ed speci\u00e1ln\u00ed pod. Ten bude m\u00edt takovouto sekci. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Jak v\u00edte, requests \u2014 to je mno\u017estv\u00ed CPU a pam\u011bti, kter\u00e9 je na hostiteli rezervov\u00e1no pro konkr\u00e9tn\u00ed pody s requests. Pokud m\u00e1me \u010dty\u0159j\u00e1drov\u00fd host v clusteru Kubernetes a doraz\u00ed tam pod s requests na \u010dty\u0159i CPU, tak na tento host u\u017e \u017e\u00e1dn\u00fd dal\u0161\u00ed pod s requests dorazit nem\u016f\u017ee. <\/p>\n
    <\/p>\n
    Pokud spust\u00edm takov\u00fd pod a pot\u00e9 provedu p\u0159\u00edkaz: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Pak u\u017e se nikdo do clusteru Kubernetes nebude moci nasadit. Proto\u017ee na v\u0161ech nodech dojdou requests. A t\u00edmto zp\u016fsobem v\u00e1\u0161 cluster Kubernetes zastav\u00edm. Pokud to ud\u011bl\u00e1m ve\u010der, mohu nasazen\u00ed zastavit na docela dlouho. <\/p>\n
    <\/p>\n
    Pokud se pod\u00edv\u00e1me do dokumentace Kubernetes je\u0161t\u011b jednou, uvid\u00edme v\u011bc naz\u00fdvanou Limit Range. Tato funkce stanovuje zdroje pro objekty v clusteru. M\u016f\u017eete vytvo\u0159it objekt Limit Range v yaml, aplikovat ho na ur\u010dit\u00e9 namespace \u2013 a pot\u00e9 v tomto namespace m\u016f\u017eete \u0159\u00edct, \u017ee m\u00e1te pro pody p\u0159eddefinovan\u00e9, maxim\u00e1ln\u00ed a minim\u00e1ln\u00ed zdroje.<\/p>\n
    <\/p>\n
    D\u00edky t\u00e9to funkci m\u016f\u017eeme omezit u\u017eivatele v konkr\u00e9tn\u00edch produktov\u00fdch namespace na to, co mohou uv\u00e1d\u011bt ve sv\u00fdch podech. Ale bohu\u017eel, i kdy\u017e u\u017eivateli \u0159eknete, \u017ee si nem\u016f\u017ee spustit pody s po\u017eadavky vy\u0161\u0161\u00edmi ne\u017e jedno CPU, existuje p\u0159\u00edkaz scale, nebo mohou prov\u00e9st scale p\u0159es dashboard.<\/p>\n
    <\/p>\n
    A odtud vych\u00e1z\u00ed druh\u00fd zp\u016fsob. Spust\u00edme 11 111 111 111 111 pod\u016f. To jsou jeden\u00e1ct miliard. To nen\u00ed proto, \u017ee bych si vymyslel to \u010d\u00edslo, ale proto\u017ee jsem to s\u00e1m vid\u011bl. <\/p>\n
    <\/p>\n
    Skute\u010dn\u00fd p\u0159\u00edb\u011bh. Pozd\u011b ve\u010der jsem se u\u017e chystal odej\u00edt z kancel\u00e1\u0159e. Vid\u011bl jsem skupinku v\u00fdvoj\u00e1\u0159\u016f v rohu, jak n\u011bco panika\u0159\u00ed s notebooky. P\u0159istoupil jsem k nim a zeptal se: \"Co se stalo?\"<\/p>\n
    <\/p>\n
    Chv\u00edli p\u0159edt\u00edm, kolem dev\u00e1t\u00e9 hodiny ve\u010dern\u00ed, se jeden z v\u00fdvoj\u00e1\u0159\u016f chystal dom\u016f. A rozhodl se: \"Te\u010f to sv\u00e9 aplikaci posunu na jedni\u010dku.\" Stiskl jedni\u010dku, ale internet trochu zpomalil. Znovu stiskl jedni\u010dku, zatla\u010dil na jedni\u010dku, \u0165ukl na Enter. Zkusil v\u0161e, co mohl. Pak internet o\u017eil \u2013 a v\u0161echno se za\u010dalo \u0161k\u00e1lovat na toto \u010d\u00edslo. <\/p>\n
    <\/p>\n
    Pravda je, \u017ee tento p\u0159\u00edb\u011bh se nestal na Kubernetes, tenkr\u00e1t to byl Nomad. Skon\u010dilo to t\u00edm, \u017ee po hodin\u011b pokus\u016f zastavit Nomad od ne\u00fanavn\u00e9ho \u0161k\u00e1lov\u00e1n\u00ed, Nomad odpov\u011bd\u011bl, \u017ee \u0161k\u00e1lov\u00e1n\u00ed nep\u0159estane a nebude se v\u011bnovat ni\u010demu jin\u00e9mu. \"Jsem unaven\u00fd, odch\u00e1z\u00edm.\" A vypnul se. <\/p>\n
    <\/p>\n
    Samoz\u0159ejm\u011b jsem se pokusil ud\u011blat tot\u00e9\u017e na Kubernetes. Jeden\u00e1ct miliard pod\u016f Kubernetes nep\u0159ijalo s radost\u00ed, \u0159ekl: \"Nemohu. P\u0159evy\u0161uje intern\u00ed limity.\" Ale 1 000 000 000 pod\u016f zvl\u00e1dnul. <\/p>\n
    <\/p>\n
    Na odpov\u011b\u010f na jeden miliard Kub se s\u00e1m nep\u0159esunul. Opravu za\u010dal \u0161k\u00e1lovat. \u010c\u00edm d\u00e1le proces postupoval, t\u00edm v\u00edce \u010dasu mu to zab\u00edralo na vytv\u00e1\u0159en\u00ed nov\u00fdch pod\u016f. Ale proces st\u00e1le prob\u00edhal. Jedin\u00fd probl\u00e9m je, \u017ee pokud mohu ve sv\u00e9 jmenn\u00e9m prostoru bez omezen\u00ed spou\u0161t\u011bt pody, mohu i bez po\u017eadavk\u016f a limit\u016f spustit s ur\u010dit\u00fdmi \u00fakoly takov\u00e9 mno\u017estv\u00ed pod\u016f, \u017ee d\u00edky t\u011bmto \u00fakol\u016fm za\u010dnou uzly spadnout z pohledu pam\u011bti a CPU. Kdy\u017e spou\u0161t\u00edm tolik pod\u016f, informace z nich mus\u00ed dorazit do \u00falo\u017ei\u0161t\u011b, tedy do etcd. A kdy\u017e tam p\u0159ich\u00e1z\u00ed p\u0159\u00edli\u0161 mnoho informac\u00ed, \u00falo\u017ei\u0161t\u011b za\u010dne p\u0159\u00edli\u0161 pomalu vyd\u00e1vat \u2014 a Kubernetes za\u010d\u00edn\u00e1 zpomalovat. <\/p>\n
    <\/p>\n
    A je\u0161t\u011b jeden probl\u00e9m\u2026 Jak v\u00edte, \u0159\u00edd\u00edc\u00ed prvky Kubernetes nejsou jen jedna centr\u00e1ln\u00ed v\u011bc, ale n\u011bkolik komponent\u016f. Mezi nimi je controller manager, scheduler a tak d\u00e1le. V\u0161ichni tito lid\u00e9 za\u010dnou vykon\u00e1vat sou\u010dasn\u011b zbyte\u010dnou bezduchou pr\u00e1ci, kter\u00e1 s \u010dasem za\u010dne zab\u00edrat st\u00e1le v\u00edce a v\u00edce \u010dasu. Controller manager bude vytv\u00e1\u0159et nov\u00e9 pody. Scheduler se pokus\u00ed naj\u00edt pro n\u011b nov\u00e9 uzly. Nov\u00e9 uzly ve va\u0161em clusteru pravd\u011bpodobn\u011b brzy dojdou. Cluster Kubernetes za\u010dne pracovat st\u00e1le pomaleji.<\/p>\n
    <\/p>\n
    Ale rozhodl jsem se j\u00edt je\u0161t\u011b d\u00e1l. Jak v\u00edte, v Kubernetes existuje n\u011bco, \u010demu se \u0159\u00edk\u00e1 slu\u017eba. A ve v\u00fdchoz\u00edm nastaven\u00ed va\u0161e slu\u017eby ve clusterech pravd\u011bpodobn\u011b funguj\u00ed pomoc\u00ed IP tables. <\/p>\n
    <\/p>\n
    Pokud spust\u00edte miliardy pod\u016f, nap\u0159\u00edklad, a pak pomoc\u00ed skriptu p\u0159inut\u00edte Kubernetes vytv\u00e1\u0159et nov\u00e9 slu\u017eby: <\/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
    Na v\u0161ech uzlech clustru se p\u0159ibli\u017en\u011b sou\u010dasn\u011b budou generovat st\u00e1le nov\u00e9 a nov\u00e9 pravidla iptables. A pro ka\u017edou slu\u017ebu bude generov\u00e1no jedno miliarda pravidel iptables. <\/p>\n
    <\/p>\n
    Tohle v\u0161echno jsem kontroloval na n\u011bkolika tis\u00edc\u00edch, a\u017e po des\u00edtku. A probl\u00e9m je v tom, \u017ee u\u017e na t\u00e9to \u00farovni je docela probl\u00e9m ud\u011blat ssh na uzel. Proto\u017ee pakety, proch\u00e1zej\u00edc\u00ed takov\u00fdm mno\u017estv\u00edm \u0159et\u011bzc\u016f, za\u010d\u00ednaj\u00ed nefungovat p\u0159\u00edli\u0161 dob\u0159e. <\/p>\n
    <\/p>\n
    A to v\u0161e se d\u00e1 vy\u0159e\u0161it pomoc\u00ed Kubernetes. Existuje objekt Resource quota. Nastavuje mno\u017estv\u00ed dostupn\u00fdch zdroj\u016f a objekt\u016f pro namespace v clusteru. M\u016f\u017eeme vytvo\u0159it yaml objekt v ka\u017ed\u00e9m namespace clusteru Kubernetes. Pomoc\u00ed tohoto objektu m\u016f\u017eeme \u0159\u00edci, \u017ee pro tento namespace je vyhrazeno ur\u010dit\u00e9 mno\u017estv\u00ed request\u016f a limit\u016f, a d\u00e1le m\u016f\u017eeme \u0159\u00edci, \u017ee v tomto namespace je mo\u017en\u00e9 vytvo\u0159it 10 slu\u017eeb a 10 pod\u016f. A v\u00fdvoj\u00e1\u0159 si m\u016f\u017ee klidn\u011b ve\u010der odpo\u010dinout. Kubernetes mu \u0159ekne: \u201eNelze \u0161k\u00e1lovat va\u0161e pody do takov\u00e9ho mno\u017estv\u00ed, proto\u017ee p\u0159esahuje kv\u00f3tu zdroj\u016f.\u201c A je po probl\u00e9mu. Dokumentace zde<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Jeden probl\u00e9mov\u00fd bod v tomto ohledu nast\u00e1v\u00e1. C\u00edt\u00edte, jak obt\u00ed\u017en\u00e9 se st\u00e1v\u00e1 vytvo\u0159en\u00ed namespace v Kubernetes. Abychom ho vytvo\u0159ili, mus\u00edme zv\u00e1\u017eit mnoho faktor\u016f.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Vytvo\u0159te namespace
    \n\u2022 Vytvo\u0159te limit range uvnit\u0159
    \n\u2022 Vytvo\u0159te resource quota uvnit\u0159
    \n\u2022 Vytvo\u0159te service account pro CI
    \n\u2022 Vytvo\u0159te rolebinding pro CI a u\u017eivatele
    \n\u2022 Voliteln\u011b spus\u0165te pot\u0159ebn\u00e9 pomocn\u00e9 pody <\/p>\n
    <\/p>\n
    Proto bych cht\u011bl vyu\u017e\u00edt p\u0159\u00edle\u017eitosti a pod\u011blit se o sv\u00e9 v\u00fdvoje. Existuje n\u00e1stroj zvan\u00fd Operator SDK. To je zp\u016fsob, jak v clusteru Kubernetes ps\u00e1t oper\u00e1tory. M\u016f\u017eete ps\u00e1t oper\u00e1tory pomoc\u00ed Ansible.<\/p>\n
    <\/p>\n
    Nejprve jsme to m\u011bli naps\u00e1no v Ansible, a pak jsem zjistil, \u017ee existuje Operator SDK a p\u0159epsal Ansible roli na operator. Tento operator umo\u017e\u0148uje vytvo\u0159it v clusteru Kubernetes objekt zvan\u00fd command. Uvnit\u0159 commandu umo\u017e\u0148uje popisovat v yaml prost\u0159ed\u00ed pro tento command. A uvnit\u0159 prost\u0159ed\u00ed commandu umo\u017e\u0148uje popisovat, kolik zdroj\u016f vy\u010dle\u0148ujeme. <\/p>\n
    <\/p>\n
    Mal\u00e1 usnadn\u011bn\u00ed cel\u00e9ho tohoto slo\u017eit\u00e9ho procesu<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    A z\u00e1v\u011brem. Co s t\u00edm v\u0161\u00edm d\u011blat?
    \nPrvn\u00ed. Pod Security Policy \u2014 to je dobr\u00e9. A i kdy\u017e \u017e\u00e1dn\u00fd z instal\u00e1tor\u016f Kubernetes to dosud nepou\u017e\u00edv\u00e1, ve va\u0161ich clusterech to st\u00e1le pou\u017e\u00edvat pot\u0159ebujete. <\/p>\n
    <\/p>\n
    Network Policy \u2014 to nen\u00ed jen n\u011bjak\u00e1 dal\u0161\u00ed zbyte\u010dn\u00e1 funkce. To je n\u011bco, co je v clusteru skute\u010dn\u011b pot\u0159eba. <\/p>\n
    <\/p>\n
    Limit Range\/ResourceQuota \u2014 u\u017e by bylo na \u010dase to pou\u017e\u00edt. U\u017e jsme to za\u010dali pou\u017e\u00edvat d\u00e1vno, a dlouho jsem byl p\u0159esv\u011bd\u010den, \u017ee to pou\u017e\u00edvaj\u00ed v\u0161ichni. Uk\u00e1zalo se, \u017ee je to vz\u00e1cnost. <\/p>\n
    <\/p>\n
    Krom\u011b toho, co jsem zm\u00ednil b\u011bhem p\u0159edn\u00e1\u0161ky, existuj\u00ed nedokumentovan\u00e9 funkce, kter\u00e9 umo\u017e\u0148uj\u00ed \u00fatok na klastr. Ned\u00e1vno byl zve\u0159ejn\u011bn rozs\u00e1hl\u00fd p\u0159ehled zranitelnost\u00ed Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    N\u011bkter\u00e9 v\u011bci jsou tak smutn\u00e9 a zklam\u00e1vaj\u00edc\u00ed. Nap\u0159\u00edklad za ur\u010dit\u00fdch podm\u00ednek mohou kubelety v klastru Kubernetes vracet obsah adres\u00e1\u0159e warlocks neautorizovan\u00e9mu u\u017eivateli. <\/p>\n
    <\/p>\n
    Tady<\/a><\/noindex> obsahuj\u00ed pokyny, jak reprodukovat v\u0161e, o \u010dem jsem mluvil. Jsou tam soubory s uk\u00e1zkami produkce, jak vypadaj\u00ed ResourceQuota, Pod Security Policy. A to v\u0161echno si m\u016f\u017eete vyzkou\u0161et. <\/p>\n
    <\/p>\n
    D\u011bkuji v\u0161em.<\/p>\n
    Zdroj: 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\udd47Zav\u00edr\u00e1n\u00ed mezer v klastru Kubernetes. Prezentace a p\u0159epis z DevOpsConf | ProHoster","description":"Pavel Selivanov, architekt \u0159e\u0161en\u00ed Southbridge a lektor Sl\u00ebrma, vystoupil s p\u0159edn\u00e1\u0161kou na DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","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\/cs\/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\/cs\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}