{"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\/da\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Vi t\u00e6tner hullerne i Kubernetes-klyngen. Pr\u00e6sentation og transskription fra DevOpsConf.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, l\u00f8sninger arkitekt ved Southbridge og l\u00e6rer hos Slurm, holdt et foredrag p\u00e5 DevOpsConf 2019. Dette foredrag er en del af et af emnerne i det avancerede kursus om Kubernetes \"Slurm Mega\".<\/p>\n

<\/p>\n

Slurm Basic: Introduktion til Kubernetes<\/a><\/noindex> finder sted i Moskva den 18.-20. november.
\nSlurm Mega: Kigger ind i maskinrummet af Kubernetes<\/a><\/noindex> \u2014 Moskva, 22.-24. november.
\nSlurm Online: begge kurser om Kubernetes<\/a><\/noindex> er altid tilg\u00e6ngelig.<\/p>\n

\n

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

Under cutten \u2013 transskription af foredraget.<\/p>\n

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

Goddag, kolleger og sympathiserende. I dag vil jeg tale om sikkerhed.<\/p>\n

<\/p>\n

Jeg kan se, at der i dag er mange sikkerhedsfolk i salen. Jeg undskylder p\u00e5 forh\u00e5nd, hvis jeg bruger termer fra sikkerhedsverdenen ikke helt som I plejer. <\/p>\n

<\/p>\n

Det skete s\u00e5ledes, at for omkring et halvt \u00e5r siden fik jeg fat i en offentlig Kubernetes-klynge. Offentlig \u2014 betyder, at der er et antal namespaces, i disse namespaces er der brugere, isoleret i deres egen namespace. Alle disse brugere tilh\u00f8rer forskellige virksomheder. N\u00e5, og det var meningen, at denne klynge skulle bruges som CDN. Det vil sige, at de giver dig en klynge, giver dig en bruger, du g\u00e5r ind i din namespace, og deployer dine frontend. <\/p>\n

<\/p>\n

Mit tidligere firma fors\u00f8gte at s\u00e6lge en s\u00e5dan tjeneste. Og jeg blev bedt om at teste klyngen for at se, om denne l\u00f8sning var passende eller ej. <\/p>\n

<\/p>\n

Jeg kom ind i denne klynge. Jeg fik begr\u00e6nsede rettigheder, begr\u00e6nset namespace. Drenge der forstod, hvad sikkerhed var. De havde l\u00e6st, hvad Role-based access control (RBAC) er i Kubernetes \u2013 og de havde sat det op s\u00e5dan, at jeg ikke kunne starte pods adskilt fra deployments. Jeg kan ikke huske opgaven, jeg fors\u00f8gte at l\u00f8se ved at starte en pod uden deployment, men jeg havde virkelig lyst til bare at starte en pod. Jeg besluttede at se, hvilke rettigheder jeg havde i klyngen, hvad jeg kunne, hvad jeg ikke kunne, og hvad de havde sat op. Samtidig vil jeg fort\u00e6lle, hvad der var indstillet forkert i deres RBAC. <\/p>\n

<\/p>\n

Det lykkedes mig, at to minutter senere fik jeg admin-rettigheder til deres klynge, kiggede i alle nabonamespaces, og s\u00e5 de k\u00f8rende produktionsfrontender fra virksomheder, der allerede havde k\u00f8bt tjenesten og deployet sig. Jeg m\u00e5tte stoppe mig selv for ikke at g\u00e5 ind til nogen i fronten og placere et bandeord p\u00e5 hovedsiden. <\/p>\n

<\/p>\n

Jeg vil forklare med eksempler, hvordan jeg gjorde det, og hvordan man skal beskytte sig imod det. <\/p>\n

<\/p>\n

Men skal jeg starte med at pr\u00e6sentere mig. Mit navn er Pavel Selivanov. Jeg er arkitekt hos Southbridge. Jeg har ekspertise inden for Kubernetes, DevOps og andre trendy teknologier. Sammen med ingeni\u00f8rerne hos Southbridge opbygger vi alt dette, mens jeg r\u00e5dgiver. <\/p>\n

<\/p>\n

Udover vores prim\u00e6re aktiviteter har vi for nylig lanceret projekter, der kaldes Sl\u00fcrmer. Vi fors\u00f8ger at bringe vores evne til at arbejde med Kubernetes ud til folket og l\u00e6re andre mennesker at arbejde med K8s. <\/p>\n

<\/p>\n

Hvad vil jeg tale om i dag. Emnet for mit opl\u00e6g er klart \u2014 sikkerhed i Kubernetes-klynger. Men jeg vil straks sige, at dette emne er meget omfattende \u2014 og derfor vil jeg straks pr\u00e6cisere, hvad jeg bestemt ikke vil tale om. Jeg vil ikke tale om de overused begreber, som allerede er blevet mast igennem p\u00e5 internettet. Alt det der RBAC og certifikater. <\/p>\n

<\/p>\n

Jeg vil tale om, hvad jeg og mine kolleger bekymrer os om, n\u00e5r det kommer til sikkerheden i Kubernetes-klynger. Vi ser disse problemer b\u00e5de hos udbydere, der tilbyder Kubernetes-klynger, og hos kunder, der henvender sig til os. Selv kunder, der kommer til os fra andre konsulentadministrative virksomheder. S\u00e5 skalaen af tragedien er faktisk meget stor. <\/p>\n

<\/p>\n

Lad mig pr\u00e6sentere tre punkter, som jeg vil tale om i dag: <\/p>\n

<\/p>\n

    \n
  1. Brugerrettigheder vs pod-rettigheder. Brugerrettigheder og pod-rettigheder er ikke det samme. <\/li>\n
  2. Indsamling af information om klyngen. Jeg vil vise, hvilken information der kan samles fra en klynge, uden at have specielle rettigheder i denne klynge. <\/li>\n
  3. DoS-angreb p\u00e5 klyngen. Hvis vi ikke kan indsamle information, kan vi stadig bringe klyngen ned. Jeg vil tale om DoS-angreb p\u00e5 de styrende elementer i klyngen. <\/li>\n<\/ol>\n

    <\/p>\n

    En anden generel ting, jeg vil n\u00e6vne \u2014 hvad jeg har testet dette p\u00e5, og hvad jeg kan sige fungerer.<\/p>\n

    <\/p>\n

    Vi tager udgangspunkt i installationen af en Kubernetes-klynge ved hj\u00e6lp af Kubespray. Hvis nogen ikke ved, hvad det er, s\u00e5 er det faktisk en samling roller til Ansible. Vi bruger det konstant i vores arbejde. Det er godt, fordi det kan installeres hvor som helst \u2014 b\u00e5de p\u00e5 fysisk hardware og i skyen. En installationsmetode fungerer generelt overalt. <\/p>\n

    <\/p>\n

    I denne klynge vil jeg have Kubernetes v1.14.5. Hele Kubernetes-klyngen, som vi vil overveje, er opdelt i namespaces, hvor hver namespace tilh\u00f8rer et separat team, og medlemmerne af dette team har adgang til deres eget namespace. De kan ikke g\u00e5 ind i andre namespaces, kun deres eget. Men der findes en admin-konto, som har rettigheder til hele klyngen. <\/p>\n

    <\/p>\n

    \"Vi<\/p>\n

    <\/p>\n

    Jeg lovede, at det f\u00f8rste, vi skulle g\u00f8re, var at f\u00e5 admin-rettigheder til klyngen. Vi har brug for en specielt forberedt pod, som skal bryde klyngen i Kubernetes. Alt, hvad vi skal g\u00f8re, er at anvende den i Kubernetes-klyngen. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Denne pod vil komme til en af masterne i Kubernetes-klyngen. Efter dette vil klyngen gladeligt returnere en fil, der hedder admin.conf. I denne fil gemmes alle admin-certifikater, og API'en for klyngen er desuden konfigureret. S\u00e5dan kan man nemt f\u00e5 admin-adgang, jeg vil sige til 98% af Kubernetes-klynger. <\/p>\n
    <\/p>\n
    Jeg gentager, denne pod blev lavet af en udvikler i din klynge, som har adgang til at implementere sine forslag i en lille namespace, han er helt begr\u00e6nset af RBAC. Han havde ingen rettigheder. Men alligevel kom certifikatet tilbage. <\/p>\n
    <\/p>\n
    Og nu til den specielt forberedte pod. Vi k\u00f8rer den p\u00e5 en hvilken som helst image. For eksempel vil vi tage debian:jessie. <\/p>\n
    <\/p>\n
    Vi har noget som dette: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Hvad er en toleration? Masterne i Kubernetes-klyngen er normalt markeret med noget, der kaldes taint. Essensen af denne 'taint' er, at pod'er ikke kan tildeles til master-noder. Men ingen forhindrer os i at angive i enhver pod, at den er tolerant over for 'taint'. Toleration-sektionen siger netop, at hvis der er NoSchedule p\u00e5 en node, er vores pod tolerant over for denne taint \u2014 og der er ingen problemer. <\/p>\n
    <\/p>\n
    Derudover siger vi, at vores pod ikke bare er tolerant, men ogs\u00e5 \u00f8nsker at g\u00e5 specifikt til masteren. Fordi de mest v\u00e6rdifulde ting, vi har brug for, findes p\u00e5 masterne \u2014 alle certifikaterne. Derfor angiver vi nodeSelector \u2014 og vi har en standardlabel p\u00e5 masterne, der tillader os at v\u00e6lge de noder fra hele klyngen, som er mastere. <\/p>\n
    <\/p>\n
    Med disse to sektioner vil pod'en helt sikkert komme til masteren. Og den vil f\u00e5 lov til at bo der. <\/p>\n
    <\/p>\n
    Men det er ikke nok bare at komme til masteren. Det giver os ikke noget. Derfor har vi to ting mere:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Vi angiver, at vores pod, som vi k\u00f8rer, vil leve i kernens namespace, i netv\u00e6rks-namespace og i PID-namespace. S\u00e5 snart pod'en k\u00f8rer p\u00e5 masteren, vil den kunne se alle de rigtige, levende interfaces p\u00e5 denne node, lytte til al trafik og se PID for alle processer.<\/p>\n
    <\/p>\n
    N\u00e6ste skridt er enkelt. Tag etcd og l\u00e6s, hvad du \u00f8nsker. <\/p>\n
    <\/p>\n
    Det mest interessante er denne mulighed i Kubernetes, som er til stede 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
    Og essensen er, at vi i pod'en, som vi k\u00f8rer, selv uden rettigheder til denne klynge, kan sige, at vi \u00f8nsker at oprette et volume af typen hostPath. Det vil sige, tage stien fra v\u00e6rten, hvori vi vil k\u00f8re \u2014 og tage den som et volume. Og s\u00e5 giver vi det navnet: host. Hele denne hostPath monterer vi inde i pod'en. I dette eksempel i mappen \/host. <\/p>\n
    <\/p>\n
    Jeg gentager. Vi sagde til pod'en at komme til masteren, f\u00e5 hostNetwork og hostPID \u2014 og montere hele roden fra masteren ind i denne pod. <\/p>\n
    <\/p>\n
    Du forst\u00e5r, at vi har bash k\u00f8rende i debian, og denne bash k\u00f8rer som root. Det vil sige, at vi lige har f\u00e5et root-adgang til masteren uden at have nogen slags rettigheder i Kubernetes-klyngen.<\/p>\n
    <\/p>\n
    Dern\u00e6st er hele opgaven at g\u00e5 ind i pod'en i mappen \/host \/etc\/kubernetes\/pki, hvis jeg ikke tager fejl, og hente alle masterens certifikater fra klyngen og dermed blive admin p\u00e5 klyngen. <\/p>\n
    <\/p>\n
    Ser man det s\u00e5dan, er det nogle af de mest farlige rettigheder i pods \u2014 uanset hvad rettigheder brugeren har:
    \n\"Vi<\/p>\n
    <\/p>\n
    Hvis jeg har ret til at starte en pod i et bestemt namespace af klyngen, s\u00e5 har denne pod som standard de samme rettigheder. Jeg kan starte privilegerede pods, og det er i praksis alle rettigheder, n\u00e6sten root p\u00e5 noden. <\/p>\n
    <\/p>\n
    Mit favorit er Root-bruger. Og Kubernetes har denne mulighed, Run As Non-Root. Det er en slags beskyttelse mod hackere. Ved du, hvad et 'moldovisk virus' er? Hvis du er hacker og er kommet ind i min Kubernetes-klynge, s\u00e5 beder vi, de stakkels administratorer: 'Angiv venligst i dine pods, som du vil hacke min klynge med, run as non-root. Ellers risikerer du at k\u00f8re en proces i din pod som root, og det vil g\u00f8re det meget nemt at hacke mig. Beskyt dig selv, tak.' <\/p>\n
    <\/p>\n
    Host path volume \u2014 efter min mening den hurtigste m\u00e5de at opn\u00e5 det \u00f8nskede resultat fra Kubernetes-klyngen. <\/p>\n
    <\/p>\n
    Men hvad skal man g\u00f8re med alt dette? <\/p>\n
    <\/p>\n
    Tankerne, der b\u00f8r komme til enhver normal administrator, der st\u00e5r over for Kubernetes: \"\u00c5h, jeg sagde det, Kubernetes fungerer ikke. Der er huller i det. Og hele Kubernetes er skrammel.\" I virkeligheden findes der noget, der hedder dokumentation, og hvis man kigger der, er der et afsnit Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Dette er et yaml-objekt \u2014 vi kan oprette det i Kubernetes-klassen \u2014 som kontrollerer sikkerhedsaspekter specifikt ved beskrivelsen af pods. Det vil sige, at det faktisk kontrollerer de rettigheder til at bruge forskellige hostNetwork, hostPID, bestemte typer volume, der findes i pods, n\u00e5r de startes. Ved hj\u00e6lp af Pod Security Policy kan alt dette beskrives. <\/p>\n
    <\/p>\n
    Det mest interessante ved Pod Security Policy er, at PSP-installationerne i Kubernetes-klassen ikke er beskrevet p\u00e5 nogen m\u00e5de, de er simpelthen slukket som standard. Pod Security Policy aktiveres ved hj\u00e6lp af en admission plugin.<\/p>\n
    <\/p>\n
    Okay, lad os deployere Pod Security Policy til klassen og sige, at vi har nogle administrative pods i et namespace, som kun administratorer har adgang til. Lad os sige, at i alle andre pods har begr\u00e6nsede rettigheder. For det er sandsynligvis ikke n\u00f8dvendig for udviklerne at k\u00f8re privilegerede pods i din klasse. <\/p>\n
    <\/p>\n
    Og alt ser ud til at v\u00e6re i orden. Og vores Kubernetes-klasse kan ikke hacked p\u00e5 to minutter. <\/p>\n
    <\/p>\n
    Der er et problem. Sandsynligvis, hvis du har en Kubernetes-klasse, s\u00e5 er der installeret overv\u00e5gning i din klasse. Jeg t\u00f8r endda forudsige, at hvis der er overv\u00e5gning i din klasse, s\u00e5 hedder den Prometheus. <\/p>\n
    <\/p>\n
    Det, jeg nu vil fort\u00e6lle, vil v\u00e6re gyldigt b\u00e5de for Prometheus-operat\u00f8ren og for Prometheus, der er sat op i sin reneste form. Sp\u00f8rgsm\u00e5let er, at hvis jeg ikke hurtigt kan f\u00e5 en administrator i klassen, betyder det, at jeg skal lede mere. Og jeg kan lede ved hj\u00e6lp af din overv\u00e5gning.<\/p>\n
    <\/p>\n
    Sandsynligvis har alle l\u00e6st de samme artikler p\u00e5 Habr\u00e9, og overv\u00e5gningen findes i namespace'et monitoring. Helm-chartet kaldes n\u00e6sten det samme af alle. Jeg antager, at hvis du laver helm install stable\/prometheus, vil du f\u00e5 cirka de samme navne. Og det er endda sandsynligt, at DNS-navnet i din klasse ikke skal g\u00e6tte. For det er standard. <\/p>\n
    <\/p>\n
    \"Vi<\/p>\n
    <\/p>\n
    Videre har vi et slags dev ns, i hvilket man kan starte en slags pod. Og derfra er det meget let at g\u00f8re s\u00e5dan her: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics er en af Prometheus' eksport\u00f8rer, der indsamler metrics fra Kubernetes API'en selv. Der er mange data om, hvad der k\u00f8rer i din klynge, hvordan det er, og hvilke problemer du m\u00e5tte have med det. <\/p>\n
    <\/p>\n
    Som et simpelt eksempel: <\/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
    Ved at lave en simpel curl-foresp\u00f8rgsel fra en ikke-privilegeret pod kan du f\u00e5 s\u00e5dan en information. Hvis du ikke ved, hvilken version af Kubernetes du k\u00f8rer, s\u00e5 kan den nemt fort\u00e6lle dig det. <\/p>\n
    <\/p>\n
    Og det mest interessante er, at udover at du tilg\u00e5r kube-state-metrics, kan du liges\u00e5 godt tilg\u00e5 Prometheus direkte. Du kan indsamle metrics derfra. Du kan endda bygge metrics derfra. Teoretisk set kan du bygge en foresp\u00f8rgsel fra klyngen til Prometheus, som simpelthen slukker den. Og din overv\u00e5gning vil overhovedet stoppe med at fungere. <\/p>\n
    <\/p>\n
    Og her opst\u00e5r sp\u00f8rgsm\u00e5let, overv\u00e5ger nogen ekstern overv\u00e5gning din overv\u00e5gning. Lige nu har jeg f\u00e5et mulighed for at agere i Kubernetes-klyngen uden konsekvenser for mig selv. Du vil ikke engang vide, at jeg handler der, da overv\u00e5gningen allerede er v\u00e6k. <\/p>\n
    <\/p>\n
    Ligesom med PSP, opst\u00e5r der en f\u00f8lelse af, at problemet er, at alle disse trendy teknologier \u2014 Kubernetes, Prometheus \u2014 de virker bare ikke og er fulde af huller. Men det g\u00f8r de ikke. <\/p>\n
    <\/p>\n
    Der er s\u00e5dan en ting \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Hvis du er en normal administrator, s\u00e5 ved du sandsynligvis, at Network Policy er endnu en yaml, der allerede findes i klyngen. Og nogle Network Policies er bestemt ikke n\u00f8dvendige. Selvom du har l\u00e6st om, hvad en Network Policy er, at det er en yaml-firewall i Kubernetes, som begr\u00e6nser adgangen mellem namespaces og pods, s\u00e5 har du helt sikkert besluttet, at en firewall i yaml-format i Kubernetes er bare endnu en abstraktion\u2026 Nej, det er slet ikke n\u00f8dvendigt. <\/p>\n
    <\/p>\n
    Selv hvis dine sikkerhedsspecialister ikke har f\u00e5et fortalt, at du nemt og enkelt kan bygge en meget granular firewall ved hj\u00e6lp af din Kubernetes, hvis de ikke ved dette endnu, og ikke trykker p\u00e5: \u00abLad os f\u00e5 det...\u00bb. S\u00e5 er Network Policy noget, du har brug for, for at lukke adgangen til visse services, som kan tilg\u00e5s fra din klynge uden nogen form for autorisation. <\/p>\n
    <\/p>\n
    Som i det eksempel, jeg n\u00e6vnte, kan man tilg\u00e5 kube state metrics fra enhver namespace i Kubernetes-klyngen uden at have nogen rettigheder til det. Network policies har lukket adgangen fra alle andre namespaces til overv\u00e5gningsnamespace, og som s\u00e5dan: ingen adgang, ingen problemer. I alle chartene, der findes, b\u00e5de den standard Prometheus og den Prometheus, der er i operatoren, er der blot en mulighed i Helm values for at aktivere network policies for dem. Du skal blot aktivere det, s\u00e5 vil det fungere. <\/p>\n
    <\/p>\n
    Der er dog \u00e9t problem. Som en ordentlig bearded admin har du nok besluttet, at network policies ikke er n\u00f8dvendige. Og efter at have l\u00e6st forskellige artikler p\u00e5 ressourcer som Habr, har du besluttet, at flannel, is\u00e6r med host-gateway mode, er det bedste, du kan v\u00e6lge. <\/p>\n
    <\/p>\n
    Hvad skal man g\u00f8re? <\/p>\n
    <\/p>\n
    Du kan pr\u00f8ve at redeploye den netv\u00e6rksl\u00f8sning, du har i din Kubernetes-klynge, og fors\u00f8ge at erstatte den med noget mere funktionelt. Det samme Calico, for eksempel. Men jeg vil straks sige, at opgaven at skifte netv\u00e6rksl\u00f8sningen i en arbejds-Kubernetes-klynge er ganske ikke-triviel. Jeg har l\u00f8st den to gange (begge gange teoretisk), men vi har endda p\u00e5 Slyerma vist, hvordan man g\u00f8r det. For vores studerende har vi vist, hvordan man skifter netv\u00e6rksl\u00f8sning i en Kubernetes-klynge. Du kan principielt pr\u00f8ve at g\u00f8re det, s\u00e5 der ikke er nedetid p\u00e5 produktionsklyngen. Men sandsynligvis vil du ikke have held. <\/p>\n
    <\/p>\n
    Og problemet l\u00f8ses faktisk meget enkelt. I klyngen findes der certifikater, og du ved, at dine certifikater udl\u00f8ber om et \u00e5r. N\u00e5, og den normale l\u00f8sning med certifikater i klyngen er \u2013 hvorfor skal vi bryde os om det, vi kan oprette en ny klynge ved siden af, lad den gamle v\u00e6re, indtil den udl\u00f8ber, og s\u00e5 redeployer vi alt. Sandt nok, n\u00e5r den udl\u00f8ber, vil vi have en dag, hvor alt ligger ned, men vi har i det mindste en ny klynge. <\/p>\n
    <\/p>\n
    N\u00e5r du opretter den nye klynge, s\u00e5 inds\u00e6t Calico i stedet for flannel. <\/p>\n
    <\/p>\n
    Hvad skal man g\u00f8re, hvis du har certifikater udstedt i hundrede \u00e5r, og du ikke planl\u00e6gger at genudrulle klyngen? Der findes noget kaldet Kube-RBAC-Proxy. Det er en ret smart l\u00f8sning, som g\u00f8r det muligt at integrere sig selv som en sidecar-container til en hvilken som helst pod i Kubernetes-klyngen. Og den tilf\u00f8jer faktisk godkendelse via RBAC fra Kubernetes til denne pod. <\/p>\n
    <\/p>\n
    Der er et problem. Tidligere var denne Kube-RBAC-Proxy-l\u00f8sning indbygget i Prometheus-operatoren. Men det findes ikke l\u00e6ngere. Moderne versioner foruds\u00e6tter, at du har netv\u00e6rkspolitikker, og at du lukker af med dem. S\u00e5 du bliver n\u00f8dt til at omskrive diagrammet en smule. Hvis du g\u00e5r ind i dette repository<\/a><\/noindex>, vil der v\u00e6re eksempler p\u00e5, hvordan dette kan bruges som sidecars, og diagrammerne skal kun omskrives minimalt. <\/p>\n
    <\/p>\n
    Der er et andet lille problem. Ikke kun Prometheus giver sine metrikker til hvem som helst. Alle komponenterne i Kubernetes-klyngen kan ogs\u00e5 sende deres egne metrikker. <\/p>\n
    <\/p>\n
    Men som jeg allerede har sagt, hvis du ikke kan f\u00e5 adgang til klyngen og indsamle information, kan du i det mindste skabe nogen skade. <\/p>\n
    <\/p>\n
    S\u00e5 jeg vil hurtigt vise to m\u00e5der, hvordan man kan skade sundheden af Kubernetes-klyngen. <\/p>\n
    <\/p>\n
    Du vil grine, n\u00e5r jeg fort\u00e6ller det, det er to tilf\u00e6lde fra virkeligheden. <\/p>\n
    <\/p>\n
    F\u00f8rste metode. Udnyttelse af ressourcer. <\/p>\n
    <\/p>\n
    Vi starter en anden speciel pod. Den vil have s\u00e5dan en sektion. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Som du ved, er requests den m\u00e6ngde CPU og hukommelse, der reserveres p\u00e5 v\u00e6rten for specifikke pods med requests. Hvis vi har en firekernet v\u00e6rt i Kubernetes-klyngen, og der ankommer en pod med requests p\u00e5 fire CPU'er, s\u00e5 kan der ikke ankomme flere pods med requests til denne v\u00e6rt. <\/p>\n
    <\/p>\n
    Hvis jeg lancerer en s\u00e5dan pod, og derefter udf\u00f8rer kommandoen: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    S\u00e5 vil ingen andre kunne deploye til Kubernetes-klyngen. Fordi alle noder vil l\u00f8be t\u00f8r for requests. Og p\u00e5 den m\u00e5de vil jeg stoppe din Kubernetes-klynge. Hvis jeg g\u00f8r det om aftenen, kan jeg stoppe deployeringen i ret lang tid. <\/p>\n
    <\/p>\n
    Hvis vi ser endnu en gang i Kubernetes-dokumentationen, vil vi se noget, der hedder Limit Range. Det fasts\u00e6tter ressourcer for klyngeobjekter. Du kan skrive et Limit Range-objekt i yaml, anvende det i bestemte namespaces \u2013 og derefter kan du angive, at du har standard, maksimale og minimale ressourcer til pods i dette namespace.<\/p>\n
    <\/p>\n
    Med en s\u00e5dan ordning kan vi begr\u00e6nse brugerne i specifikke produkt-namespace til at angive alt muligt snavs i deres pods. Men desv\u00e6rre, selvom du siger til brugeren, at de ikke m\u00e5 starte pods med requests st\u00f8rre end \u00e9n CPU, er der en fantastisk kommando kaldet scale, eller de kan g\u00f8re det gennem dashboardet.<\/p>\n
    <\/p>\n
    Og herfra kommer den anden metode. Vi starter 11 111 111 111 111 pods. Det er elleve milliarder. Det er ikke, fordi jeg har fundet p\u00e5 det tal, men fordi jeg selv har set det. <\/p>\n
    <\/p>\n
    En sand historie. Senere om aftenen var jeg allerede ved at forlade kontoret. Jeg ser en gruppe udviklere sidde sammen i hj\u00f8rnet og g\u00f8re noget nerv\u00f8st med deres b\u00e6rbare computere. Jeg n\u00e6rmer mig dem og sp\u00f8rger: \u00abHvad er der sket?\u00bb<\/p>\n
    <\/p>\n
    Tidligere, omkring kl. 21, havde en af udviklerne t\u00e6nkt sig at tage hjem. Og besluttede: \u00abJeg vil skalere min applikation til \u00e9n.\u00bb Han trykkede p\u00e5 \u00e9n, men internettet var lidt langsomt. Han trykkede igen p\u00e5 \u00e9n, han trykkede p\u00e5 \u00e9n, klikkede p\u00e5 Enter. Han trykkede p\u00e5 alt, hvad han kunne. S\u00e5 blev internettet levende \u2013 og alt begyndte at skalere til dette tal. <\/p>\n
    <\/p>\n
    Faktisk foregik denne historie ikke p\u00e5 Kubernetes, det var p\u00e5 det tidspunkt Nomad. Det sluttede med, at efter en times fors\u00f8g p\u00e5 at stoppe Nomad fra sin insisterende skalering, svarede Nomad, at den ikke ville stoppe med at skalere og ikke ville lave noget andet. \u00abJeg er tr\u00e6t, jeg g\u00e5r.\u00bb Og lukkede ned. <\/p>\n
    <\/p>\n
    Jeg fors\u00f8gte naturligvis at g\u00f8re det samme p\u00e5 Kubernetes. Elleve milliarder pods gl\u00e6dede ikke Kubernetes, den sagde: \u00abJeg kan ikke. Overskrider interne gr\u00e6nser.\u00bb Men 1 000 000 000 pods kunne den h\u00e5ndtere. <\/p>\n
    <\/p>\n
    Som svar p\u00e5 en milliard pods i sig selv, er han virkelig begyndt at skalere. Jo l\u00e6ngere processen skred frem, desto mere tid brugte han p\u00e5 at oprette nye pods. Men processen gik stadig. Det eneste problem er, at hvis jeg kan k\u00f8re pods uden begr\u00e6nsninger i mit namespaces, kan jeg selv uden requests og limits starte et s\u00e5dant antal pods med nogle opgaver, at noderne begynder at kollapsere p\u00e5 grund af hukommelse og CPU. N\u00e5r jeg starter s\u00e5 mange pods, skal informationen fra dem gemmes i lagringen, det vil sige etcd. Og n\u00e5r der kommer for meget information derind, begynder lagringen at returnere for langsomt - og Kubernetes oplever flaskehalse. <\/p>\n
    <\/p>\n
    Men der er endnu et problem... Som I ved, er Kubernetes kontrolmoduler ikke bare \u00e9n central ting, men flere komponenter. Herunder er der controller manager, scheduler osv. Alle disse drenge vil begynde at udf\u00f8re un\u00f8dvendigt og meningsl\u00f8st arbejde samtidig, som med tiden vil tage mere og mere tid. Controller manageren vil oprette nye pods. Scheduler vil fors\u00f8ge at finde en ny node til dem. Nye noder i jeres klynge vil snart v\u00e6re opbrugt. Kubernetes-klyngen vil begynde at arbejde langsommere og langsommere.<\/p>\n
    <\/p>\n
    Men jeg besluttede at tage det et skridt videre. Som I ved, i Kubernetes er der noget, der kaldes en service. Og som standard fungerer servicen sandsynligvis i jeres klynger ved hj\u00e6lp af IP tables. <\/p>\n
    <\/p>\n
    Hvis man starter en milliard pods, for eksempel, og derefter med et lille script f\u00e5r Kubernetes til at oprette nye services: <\/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 alle noder i klyngen vil der omtrent samtidigt blive genereret nye og nye iptables-regler. Hver service vil generere \u00e9n milliard iptables-regler. <\/p>\n
    <\/p>\n
    Jeg har testet det hele med et par tusinde, op til ti. Og problemet er, at allerede ved dette niveau er det ret problematisk at SSH'e ind p\u00e5 noden. Fordi pakkerne, der passerer gennem s\u00e5 mange k\u00e6der, begynder at f\u00e5 det lidt skidt. <\/p>\n
    <\/p>\n
    Og det hele kan ogs\u00e5 l\u00f8ses ved hj\u00e6lp af Kubernetes. Der findes et objekt kaldet Resource quota. Det fasts\u00e6tter antallet af tilg\u00e6ngelige ressourcer og objekter for et namespace i klyngen. Vi kan oprette et yaml-objekt i hvert namespace i Kubernetes-klyngen. Ved hj\u00e6lp af dette objekt kan vi angive, at der er afsat et bestemt antal requests og limits til dette namespace, og derefter kan vi sige, at der i dette namespace kan oprettes 10 services og 10 pods. Og udvikleren kan g\u00f8re hvad som helst i aftentimerne. Kubernetes vil sige til ham: \"Du kan ikke skalere dine pods op til det antal, fordi det overskrider ressourcekvoten.\" Problemet er l\u00f8st. Dokumentation her<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Et problem opst\u00e5r i den forbindelse. Du kan m\u00e6rke, hvor sv\u00e6rt det bliver at oprette et namespace i Kubernetes. For at oprette det skal vi tage h\u00f8jde for en masse ting.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Opretter namespace
    \n\u2022 Opretter limitrange indeni
    \n\u2022 Opretter resourcequota indeni
    \n\u2022 Opretter serviceaccount til CI
    \n\u2022 Opretter rolebinding til CI og brugere
    \n\u2022 Valgfrit kan der startes de n\u00f8dvendige tjenester i pods <\/p>\n
    <\/p>\n
    Derfor vil jeg benytte lejligheden til at dele mine udviklinger. Der findes noget, der hedder operator SDK. Det er en m\u00e5de at skrive operatorer til Kubernetes-klyngen. Du kan skrive operatorer ved hj\u00e6lp af Ansible.<\/p>\n
    <\/p>\n
    F\u00f8rst havde vi skrevet det med Ansible, men s\u00e5 s\u00e5 jeg, at der er en operator SDK og skrev Ansible-rollen om til en operator. Denne operator g\u00f8r det muligt at oprette et objekt i Kubernetes-klyngen, som hedder en kommando. Inden for kommandoen giver det mulighed for at beskrive et yaml-milj\u00f8 til denne kommando. Og inden for milj\u00f8et for kommandoen giver det mulighed for at beskrive, at vi tildeler s\u00e5 mange ressourcer. <\/p>\n
    <\/p>\n
    Lille lettelse af hele denne komplekse proces<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Og til sidst. Hvad skal vi g\u00f8re med alt dette?
    \nFor det f\u00f8rste. Pod Security Policy \u2014 det er godt. Og selvom ingen af Kubernetes-installat\u00f8rerne bruger dem til dato, b\u00f8r de alligevel anvendes i jeres klynger. <\/p>\n
    <\/p>\n
    Network Policy \u2014 det er ikke bare en un\u00f8dvendig funktion. Det er noget, der virkelig er n\u00f8dvendigt i klyngen. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 det er p\u00e5 tide at bruge. Vi begyndte for l\u00e6nge siden at anvende dette, og jeg var l\u00e6nge overbevist om, at alle anvendte det. Det viste sig at v\u00e6re sj\u00e6ldent. <\/p>\n
    <\/p>\n
    Udover det, jeg n\u00e6vnte i mit foredrag, er der udocumenterede funktioner, der muligg\u00f8r angreb p\u00e5 klyngen. For nylig kom der en stor analyse af s\u00e5rbarheder i Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Nogle ting er s\u00e5 triste og frustrerende. For eksempel, under visse omst\u00e6ndigheder kan kubelets i Kubernetes-klyngen returnere indholdet af warlocks-mappen til uautoriserede brugere. <\/p>\n
    <\/p>\n
    Her<\/a><\/noindex> Der ligger instruktioner om, hvordan man genskaber alt, hvad jeg har talt om. Der ligger filer med produktionsudgaver, som viser, hvordan ResourceQuota og Pod Security Policy ser ud. Og alt dette kan man r\u00f8re ved. <\/p>\n
    <\/p>\n
    Tak til alle.<\/p>\n
    Kilde: 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 d\u00e6kker huller i Kubernetes-klyngen. Foredrag og transkription fra DevOpsConf | ProHoster","description":"Pavel Selivanov, l\u00f8sningsarkitekt hos Southbridge og underviser ved Slyrma, pr\u00e6senterede et foredrag p\u00e5 DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}