Pavel Selivanov, Southbridge-løsningsarkitekt og Slurm-lærer, holdt en presentasjon på DevOpsConf 2019. Denne foredraget er en del av et av temaene i dybdekurset om Kubernetes «Slurm Mega».
finner sted i Moskva 18.-20. november.
— Moskva, 22.-24. november.
alltid tilgjengelig.
Under snittet er en utskrift av rapporten.
God ettermiddag, kolleger og de som sympatiserer med dem. I dag skal jeg snakke om sikkerhet.
Jeg ser at det er mange vektere i hallen i dag. Jeg beklager på forhånd dersom jeg bruker termer fra sikkerhetsverdenen som ikke er helt som vanlig for deg.
Det skjedde slik at jeg for omtrent seks måneder siden kom over en offentlig Kubernetes-klynge. Offentlig betyr at det er et n-te antall navnerom; i disse navnerommene er det brukere isolert i deres navnerom. Alle disse brukerne tilhører forskjellige selskaper. Vel, det ble antatt at denne klyngen skulle brukes som en CDN. Det vil si at de gir deg en klynge, de gir deg en bruker der, du går dit til navneområdet ditt, distribuerer frontene dine.
Mitt forrige firma prøvde å selge en slik tjeneste. Og jeg ble bedt om å stikke i klyngen for å se om denne løsningen var egnet eller ikke.
Jeg kom til denne klyngen. Jeg fikk begrensede rettigheter, begrenset navneområde. Gutta der forsto hva sikkerhet var. De leste om Rollebasert tilgangskontroll (RBAC) i Kubernetes – og de vrir på det slik at jeg ikke kunne starte pods separat fra distribusjoner. Jeg husker ikke problemet jeg prøvde å løse ved å starte en pod uten distribusjon, men jeg ønsket virkelig å starte bare en pod. For hell og lykke bestemte jeg meg for å se hvilke rettigheter jeg har i klyngen, hva jeg kan gjøre, hva jeg ikke kan gjøre, og hva de har ødelagt der. Samtidig vil jeg fortelle deg hva de har konfigurert feil i RBAC.
Det skjedde slik at i løpet av to minutter mottok jeg en admin til klyngen deres, så på alle de nærliggende navneområdene, så de kjørende produksjonsfrontene til selskaper som allerede hadde kjøpt tjenesten og implementert. Jeg kunne knapt stoppe meg selv fra å gå foran noen og sette banneord på hovedsiden.
Jeg vil fortelle deg med eksempler hvordan jeg gjorde dette og hvordan du kan beskytte deg mot dette.
Men først, la meg presentere meg selv. Mitt navn er Pavel Selivanov. Jeg er arkitekt i Southbridge. Jeg forstår Kubernetes, DevOps og alle slags fancy ting. Southbridge-ingeniørene og jeg bygger alt dette, og jeg rådgiver.
I tillegg til hovedaktivitetene våre har vi nylig lansert prosjekter kalt Slurms. Vi prøver å bringe vår evne til å jobbe med Kubernetes litt til massene, for å lære andre mennesker å også jobbe med K8-er.
Hva skal jeg snakke om i dag? Temaet for rapporten er åpenbart - om sikkerheten til Kubernetes-klyngen. Men jeg vil si med en gang at dette temaet er veldig stort - og derfor vil jeg umiddelbart avklare hva jeg definitivt ikke vil snakke om. Jeg vil ikke snakke om forfalskede termer som allerede har blitt brukt hundre ganger på Internett. Alle slags RBAC og sertifikater.
Jeg vil snakke om hva som plager meg og mine kolleger med sikkerhet i en Kubernetes-klynge. Vi ser disse problemene både blant leverandører som leverer Kubernetes-klynger og blant kunder som kommer til oss. Og til og med fra kunder som kommer til oss fra andre konsulentselskaper. Det vil si at omfanget av tragedien faktisk er veldig stort.
Det er bokstavelig talt tre punkter jeg skal snakke om i dag:
- Brukerrettigheter vs podrettigheter. Brukerrettigheter og podrettigheter er ikke det samme.
- Samle informasjon om klyngen. Jeg skal vise at du kan samle all informasjon du trenger fra en klynge uten å ha spesielle rettigheter i denne klyngen.
- DoS-angrep på klyngen. Hvis vi ikke kan samle inn informasjon, vil vi uansett kunne sette en klynge. Jeg vil snakke om DoS-angrep på klyngekontrollelementer.
En annen generell ting som jeg vil nevne er hva jeg testet alt dette på, som jeg definitivt kan si at det hele fungerer på.
Vi tar utgangspunkt i installasjonen av en Kubernetes-klynge ved bruk av Kubespray. Hvis noen ikke vet, er dette faktisk et sett med roller for Ansible. Vi bruker det hele tiden i vårt arbeid. Det som er bra er at du kan rulle den hvor som helst – du kan rulle den på jernbiter eller inn i en sky et sted. Én installasjonsmetode fungerer i prinsippet for alt.
I denne klyngen vil jeg ha Kubernetes v1.14.5. Hele Cube-klyngen, som vi vil vurdere, er delt inn i navnerom, hvert navneområde tilhører et eget team, og medlemmer av dette teamet har tilgang til hvert navneområde. De kan ikke gå til forskjellige navneområder, bare til sitt eget. Men det er en viss admin-konto som har rettigheter til hele klyngen.
Jeg lovet at det første vi skal gjøre er å få administratorrettigheter til klyngen. Vi trenger en spesiallaget pod som vil bryte Kubernetes-klyngen. Alt vi trenger å gjøre er å bruke det på Kubernetes-klyngen.
kubectl apply -f pod.yamlDenne poden kommer til en av mesterne i Kubernetes-klyngen. Og etter dette vil klyngen med glede returnere en fil som heter admin.conf. I Cube lagrer denne filen alle administratorsertifikater, og konfigurerer samtidig cluster API. Så enkelt er det å få administratortilgang til, tror jeg, 98 % av Kubernetes-klynger.
Jeg gjentar, denne poden ble laget av en utvikler i klyngen din som har tilgang til å distribuere forslagene sine i ett lite navneområde, det hele er klemt av RBAC. Han hadde ingen rettigheter. Men sertifikatet ble likevel returnert.
Og nå om en spesiallaget pod. Vi kjører det på et hvilket som helst bilde. La oss ta debian:jessie som et eksempel.
Vi har denne tingen:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Hva er toleranse? Mestere i en Kubernetes-klynge er vanligvis merket med noe som kalles taint. Og essensen av denne "infeksjonen" er at den sier at pods ikke kan tilordnes masternoder. Men ingen gidder å indikere i noen pod at den er tolerant for "infeksjonen". Tolerasjonsdelen sier bare at hvis en node har NoSchedule, så er noden vår tolerant for en slik infeksjon - og det er ingen problemer.
Videre sier vi at vår under ikke bare er tolerant, men ønsker også å spesifikt målrette mot mesteren. For mesterne har det deiligste vi trenger – alle sertifikatene. Derfor sier vi nodeSelector - og vi har en standardetikett på mastere, som lar deg velge fra alle nodene i klyngen akkurat de nodene som er master.
Med disse to seksjonene vil han definitivt komme til mesteren. Og han skal få bo der.
Men bare å komme til mesteren er ikke nok for oss. Dette vil ikke gi oss noe. Så nå har vi disse to tingene:
hostNetwork: true
hostPID: true Vi spesifiserer at poden vår, som vi lanserer, vil leve i kjernenavneområdet, i nettverksnavnerommet og i PID-navnerommet. Når poden er lansert på masteren, vil den kunne se alle de virkelige, live grensesnittene til denne noden, lytte til all trafikk og se PID for alle prosesser.
Da er det snakk om små ting. Ta etcd og les hva du vil.
Det mest interessante er denne Kubernetes-funksjonen, som er til stede der som standard.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Og essensen er at vi kan si i poden som vi lanserer, selv uten rettigheter til denne klyngen, at vi ønsker å lage et volum av typen hostPath. Dette betyr å ta veien fra verten som vi skal lansere på – og ta den som volum. Og så kaller vi det navnet: vert. Vi monterer hele denne vertsbanen inne i poden. I dette eksemplet, til /host-katalogen.
Jeg skal gjenta det igjen. Vi ba poden komme til masteren, hente hostNetwork og hostPID der – og montere hele roten til masteren inne i denne poden.
Du forstår at i Debian har vi bash som kjører, og denne bash kjører under root. Det vil si at vi nettopp mottok root på masteren, uten å ha noen rettigheter i Kubernetes-klyngen.
Da er hele oppgaven å gå til underkatalogen /host /etc/kubernetes/pki, hvis jeg ikke tar feil, plukke opp alle mastersertifikatene til klyngen der og bli klyngeadministrator.
Hvis du ser på det på denne måten, er dette noen av de farligste rettighetene i pods – uavhengig av hvilke rettigheter brukeren har:
Hvis jeg har rettighetene til å kjøre en pod i et navneområde i klyngen, har denne poden disse rettighetene som standard. Jeg kan kjøre privilegerte pods, og disse er generelt alle rettigheter, praktisk talt root på noden.
Min favoritt er root-bruker. Og Kubernetes har dette alternativet Kjør som ikke-rot. Dette er en type beskyttelse fra en hacker. Vet du hva det "moldaviske viruset" er? Hvis du plutselig er en hacker og kommer til Kubernetes-klyngen min, spør vi, stakkars administratorer: "Vennligst angi i podene dine med hvilke du vil hacke klyngen min, kjør som ikke-root. Ellers vil det skje at du kjører prosessen i poden din under root, og det vil være veldig enkelt for deg å hacke meg. Beskytt deg selv mot deg selv."
Vertsbanevolum er etter min mening den raskeste måten å få ønsket resultat fra en Kubernetes-klynge.
Men hva skal man gjøre med alt dette?
Tanken som burde komme til enhver normal administrator som møter Kubernetes er: "Ja, jeg sa til deg, Kubernetes fungerer ikke. Det er hull i den. Og hele kuben er tull.» Faktisk er det noe som heter dokumentasjon, og hvis du ser der, er det en seksjon .
Dette er et yaml-objekt - vi kan lage det i Kubernetes-klyngen - som kontrollerer sikkerhetsaspekter spesifikt i beskrivelsen av podene. Det vil si at den faktisk kontrollerer rettighetene til å bruke alle vertsnettverk, hostPID, visse volumtyper som er i podene ved oppstart. Ved hjelp av Pod Security Policy kan alt dette beskrives.
Det mest interessante med Pod Security Policy er at i Kubernetes-klyngen er alle PSP-installatører ikke bare beskrevet på noen måte, de er ganske enkelt deaktivert som standard. Pod Security Policy er aktivert ved hjelp av admission plugin.
Ok, la oss distribuere Pod Security Policy i klyngen, la oss si at vi har noen tjenestepoder i navneområdet, som bare administratorer har tilgang til. La oss si at i alle andre tilfeller har pods begrensede rettigheter. Fordi utviklere sannsynligvis ikke trenger å kjøre privilegerte pods i klyngen din.
Og alt ser ut til å være bra med oss. Og Kubernetes-klyngen vår kan ikke hackes på to minutter.
Det er et problem. Mest sannsynlig, hvis du har en Kubernetes-klynge, er overvåking installert på klyngen din. Jeg vil til og med gå så langt som å forutsi at hvis klyngen din har overvåking, vil den hete Prometheus.
Det jeg skal fortelle deg vil være gyldig for både Prometheus-operatøren og Prometheus levert i sin rene form. Spørsmålet er at hvis jeg ikke kan få en admin inn i klyngen så raskt, betyr dette at jeg må se mer. Og jeg kan søke ved hjelp av overvåkingen din.
Sannsynligvis leser alle de samme artiklene på Habré, og overvåkingen ligger i overvåkingsnavneområdet. Rordiagram kalles omtrent det samme for alle. Jeg tipper at hvis du installerer helm stabil/prometheus, vil du ende opp med omtrent de samme navnene. Og mest sannsynlig trenger jeg ikke engang å gjette DNS-navnet i klyngen din. Fordi det er standard.
Deretter har vi en bestemt dev ns, der du kan kjøre en bestemt pod. Og så fra denne poden er det veldig enkelt å gjøre noe som dette:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics er en av Prometheus-eksportørene som samler inn beregninger fra selve Kubernetes API. Det er mye data der, hva som kjører i klyngen din, hva det er, hvilke problemer du har med det.
Som et enkelt eksempel:
kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=
"gcr.io/google-containers/kube-apiserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Ved å lage en enkel krølleforespørsel fra en uprivilegert pod, kan du få følgende informasjon. Hvis du ikke vet hvilken versjon av Kubernetes du kjører, vil den enkelt fortelle deg det.
Og det mest interessante er at i tillegg til å få tilgang til kube-state-metrics, kan du like enkelt få tilgang til selve Prometheus direkte. Du kan samle inn beregninger derfra. Du kan til og med bygge beregninger derfra. Selv teoretisk kan du bygge en slik spørring fra en klynge i Prometheus, som ganske enkelt vil slå den av. Og overvåkingen din vil slutte å fungere fra klyngen helt.
Og her oppstår spørsmålet om noen ekstern overvåking overvåker overvåkingen din. Jeg har nettopp fått muligheten til å operere i en Kubernetes-klynge uten at det får konsekvenser for meg selv. Du vil ikke engang vite at jeg opererer der, siden det ikke lenger er noen overvåking.
Akkurat som med PSP, føles det som om problemet er at alle disse fancy teknologiene – Kubernetes, Prometheus – de bare ikke fungerer og er fulle av hull. Ikke egentlig.
Det er en slik ting - .
Hvis du er en vanlig administrator, vet du mest sannsynlig om Network Policy at dette bare er en annen yaml, som det allerede er mange av i klyngen. Og noen nettverkspolicyer er definitivt ikke nødvendig. Og selv om du leser hva Network Policy er, at det er en yaml-brannmur av Kubernetes, den lar deg begrense tilgangsrettigheter mellom navneområder, mellom poder, så bestemte du deg for at brannmuren i yaml-format i Kubernetes er basert på de neste abstraksjonene ... Nei, nei. Dette er definitivt ikke nødvendig.
Selv om du ikke fortalte sikkerhetsspesialistene dine at ved å bruke Kubernetes kan du bygge en veldig enkel og enkel brannmur, og en veldig detaljert brannmur. Hvis de ikke vet dette ennå og ikke plager deg: "Vel, gi meg, gi meg..." Så trenger du i alle fall Network Policy for å blokkere tilgang til noen tjenestesteder som kan trekkes fra klyngen din uten noen autorisasjon.
Som i eksemplet jeg ga, kan du hente kube-tilstandsberegninger fra et hvilket som helst navneområde i Kubernetes-klyngen uten å ha noen rettigheter til å gjøre det. Nettverkspolicyer har stengt tilgang fra alle andre navneområder til overvåkingsnavneområdet, og det er det: ingen tilgang, ingen problemer. I alle kartene som finnes, både standard Prometheus og Prometheus som er i operatøren, er det ganske enkelt et alternativ i rorverdiene for å aktivere nettverkspolicyer for dem. Du trenger bare å slå den på, så fungerer de.
Det er egentlig ett problem her. Som en normal skjegg administrator, bestemte du deg sannsynligvis for at nettverkspolicyer ikke er nødvendig. Og etter å ha lest alle slags artikler om ressurser som Habr, bestemte du deg for at flanell, spesielt med vertsgateway-modus, er det beste du kan velge.
Hva gjør jeg?
Du kan prøve å omdistribuere nettverksløsningen du har i Kubernetes-klyngen din, prøv å erstatte den med noe mer funksjonelt. For samme Calico, for eksempel. Men jeg vil si med en gang at oppgaven med å endre nettverksløsningen i en Kubernetes-arbeidsklynge er ganske ikke-triviell. Jeg løste det to ganger (begge ganger imidlertid teoretisk), men vi viste til og med hvordan man gjør det på Slurms. For studentene våre viste vi hvordan man endrer nettverksløsningen i en Kubernetes-klynge. I prinsippet kan du prøve å sørge for at det ikke er nedetid på produksjonsklyngen. Men du vil sannsynligvis ikke lykkes.
Og problemet er faktisk løst veldig enkelt. Det er sertifikater i klyngen, og du vet at sertifikatene dine utløper om et år. Vel, og vanligvis en normal løsning med sertifikater i klyngen - hvorfor bekymrer vi oss, vi reiser en ny klynge i nærheten, lar den gamle bli råtten og omplasserer alt. Riktignok, når det blir råttent, må vi sitte i en dag, men her er en ny klynge.
Når du reiser en ny klynge, setter du samtidig inn Calico i stedet for flanell.
Hva gjør du hvis sertifikatene dine er utstedt for hundre år og du ikke kommer til å omdistribuere klyngen? Det er noe som heter Kube-RBAC-Proxy. Dette er en veldig kul utvikling, den lar deg bygge seg inn som en sidevognsbeholder til en hvilken som helst pod i Kubernetes-klyngen. Og det gir faktisk autorisasjon til denne poden gjennom RBAC av Kubernetes selv.
Det er ett problem. Tidligere ble denne Kube-RBAC-Proxy-løsningen innebygd i operatørens Prometheus. Men så var han borte. Nå er moderne versjoner avhengige av at du har en nettverkspolicy og lukker den ved å bruke dem. Og derfor må vi omskrive diagrammet litt. Faktisk, hvis du går til , det er eksempler på hvordan man kan bruke dette som sidevogner, og kartene må skrives om minimalt.
Det er et lite problem til. Prometheus er ikke den eneste som deler ut sine beregninger til hvem som helst. Alle Kubernetes-klyngekomponentene våre kan også returnere sine egne beregninger.
Men som jeg allerede sa, hvis du ikke får tilgang til klyngen og samler informasjon, kan du i det minste gjøre noe skade.
Så jeg vil raskt vise to måter hvordan en Kubernetes-klynge kan bli ødelagt.
Du vil le når jeg forteller deg dette, dette er to saker fra det virkelige livet.
Metode én. Ressursutarming.
La oss lansere en annen spesiell pod. Den vil ha en seksjon som dette.
resources:
requests:
cpu: 4
memory: 4Gi Som du vet, er forespørsler mengden CPU og minne som er reservert på verten for spesifikke pods med forespørsler. Hvis vi har en firekjernevert i en Kubernetes-klynge, og fire CPU-poder kommer dit med forespørsler, betyr det at ingen flere poder med forespørsler vil kunne komme til denne verten.
Hvis jeg kjører en slik pod, kjører jeg kommandoen:
$ kubectl scale special-pod --replicas=...Da vil ingen andre kunne distribuere til Kubernetes-klyngen. Fordi alle noder vil gå tom for forespørsler. Og dermed vil jeg stoppe Kubernetes-klyngen din. Hvis jeg gjør dette på kvelden, kan jeg stoppe utplasseringene ganske lenge.
Hvis vi ser på Kubernetes-dokumentasjonen igjen, vil vi se denne tingen som heter Limit Range. Den setter ressurser for klyngeobjekter. Du kan skrive et Limit Range-objekt i yaml, bruke det på bestemte navneområder – og så kan du i dette navneområdet si at du har standard-, maksimums- og minimumsressurser for podene.
Ved hjelp av noe slikt kan vi begrense brukere i bestemte produktnavneområder til team i muligheten til å indikere alle slags ekle ting på podene deres. Men dessverre, selv om du forteller brukeren at de ikke kan starte pods med forespørsler om mer enn én CPU, er det en så fantastisk skaleringskommando, eller de kan skalere gjennom dashbordet.
Og det er her metode nummer to kommer fra. Vi lanserer 11 pods. Det er elleve milliarder. Dette er ikke fordi jeg kom på et slikt tall, men fordi jeg så det selv.
Ekte historie. Sent på kvelden var jeg i ferd med å forlate kontoret. Jeg ser en gruppe utviklere som sitter i hjørnet og desperat gjør noe med de bærbare datamaskinene sine. Jeg går bort til gutta og spør: "Hva har skjedd med deg?"
Litt tidligere, rundt ni på kvelden, gjorde en av utviklerne seg klar til å reise hjem. Og jeg bestemte meg: «Jeg skal nå nedskalere søknaden min til én.» Jeg trykket på en, men Internett ble litt langsommere. Han trykket på den ene igjen, han trykket på den ene og klikket Enter. Jeg pirket på alt jeg kunne. Så kom Internett til live – og alt begynte å skalere ned til dette tallet.
Riktignok fant ikke denne historien sted på Kubernetes; på den tiden var det Nomad. Det endte med at etter en time med våre forsøk på å stoppe Nomad fra iherdige forsøk på skalering, svarte Nomad at han ikke ville slutte å skalere og ikke gjøre noe annet. "Jeg er sliten, jeg drar." Og han krøllet seg sammen.
Naturligvis prøvde jeg å gjøre det samme på Kubernetes. Kubernetes var ikke fornøyd med elleve milliarder pods, han sa: "Jeg kan ikke. Overgår interne munnbeskyttere." Men 1 pods kunne.
Som svar på en milliard trakk ikke kuben seg inn i seg selv. Han begynte virkelig å skalere. Jo lenger prosessen gikk, jo mer tid tok det ham å lage nye pods. Men likevel fortsatte prosessen. Det eneste problemet er at hvis jeg kan starte poder ubegrenset i navneområdet mitt, så kan jeg selv uten forespørsler og begrensninger starte så mange poder med noen oppgaver at ved hjelp av disse oppgavene vil nodene begynne å legge seg opp i minnet, i CPU. Når jeg starter så mange poder, skal informasjonen fra dem lagres, det vil si osv. Og når det kommer for mye informasjon dit, begynner lagringen å komme tilbake for sakte – og Kubernetes begynner å bli kjedelig.
Og ett problem til... Som du vet er ikke Kubernetes kontrollelementer én sentral ting, men flere komponenter. Spesielt er det en kontrolleransvarlig, planlegger og så videre. Alle disse gutta vil begynne å gjøre unødvendig, dumt arbeid på samme tid, som over tid vil begynne å ta mer og mer tid. Kontrolleren vil opprette nye pods. Planlegger vil prøve å finne en ny node for dem. Du vil mest sannsynlig gå tom for nye noder i klyngen din snart. Kubernetes-klyngen vil begynne å jobbe saktere og saktere.
Men jeg bestemte meg for å gå enda lenger. Som du vet, i Kubernetes er det noe slikt som kalles en tjeneste. Vel, som standard i dine klynger, mest sannsynlig, fungerer tjenesten ved å bruke IP-tabeller.
Hvis du kjører én milliard pods, for eksempel, og deretter bruker et skript for å tvinge Kubernetis til å lage nye tjenester:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done På alle noder i klyngen vil flere og flere nye iptables-regler genereres omtrent samtidig. I tillegg vil en milliard iptables-regler genereres for hver tjeneste.
Jeg sjekket hele denne greia på flere tusen, opptil ti. Og problemet er at allerede ved denne terskelen er det ganske problematisk å gjøre ssh til noden. Fordi pakker, som går gjennom så mange kjeder, begynner å føles ikke veldig bra.
Og også dette er alt løst ved hjelp av Kubernetes. Det finnes et slikt Ressurskvoteobjekt. Angir antall tilgjengelige ressurser og objekter for navneområdet i klyngen. Vi kan lage et yaml-objekt i hvert navneområde i Kubernetes-klyngen. Ved å bruke dette objektet kan vi si at vi har et visst antall forespørsler og grenser tildelt for dette navneområdet, og så kan vi si at i dette navnerommet er det mulig å lage 10 tjenester og 10 poder. Og en enkelt utvikler kan i det minste kvele seg selv om kveldene. Kubernetes vil fortelle ham: "Du kan ikke skalere podene dine til det beløpet, fordi ressursen overskrider kvoten." Det er det, problemet løst. .
Et problematisk punkt dukker opp i denne forbindelse. Du føler hvor vanskelig det blir å lage et navneområde i Kubernetes. For å lage den må vi ta hensyn til mange ting.
Ressurskvote + grenseområde + RBAC
• Opprett et navneområde
• Lag et grenseområde inne
• Opprett intern ressurskvote
• Opprett en tjenestekonto for CI
• Lag rollebinding for CI og brukere
• Start eventuelt de nødvendige servicepodene
Derfor vil jeg benytte anledningen til å dele utviklingen min. Det er noe som heter SDK-operatøren. Dette er en måte for en Kubernetes-klynge å skrive operatorer for den. Du kan skrive utsagn ved å bruke Ansible.
Først ble det skrevet i Ansible, og så så jeg at det var en SDK-operatør og skrev om Ansible-rollen til en operatør. Denne setningen lar deg lage et objekt i Kubernetes-klyngen kalt en kommando. Inne i en kommando lar den deg beskrive miljøet for denne kommandoen i yaml. Og innenfor teammiljøet lar det oss beskrive at vi tildeler så mange ressurser.
petite .
Og avslutningsvis. Hva skal man gjøre med alt dette?
Først. Pod Security Policy er bra. Og til tross for at ingen av Kubernetes-installatørene bruker dem til i dag, må du fortsatt bruke dem i klynger.
Nettverkspolicy er ikke bare en annen unødvendig funksjon. Dette er det som virkelig trengs i en klynge.
LimitRange/ResourceQuota - det er på tide å bruke det. Vi begynte å bruke denne for lenge siden, og jeg var lenge sikker på at alle brukte den. Det viste seg at dette er sjeldent.
I tillegg til det jeg nevnte under rapporten, er det udokumenterte funksjoner som lar deg angripe klyngen. Utgitt nylig .
Noen ting er så triste og sårende. For eksempel, under visse forhold, kan kubeletter i en Kubernetes-klynge gi innholdet i warlocks-katalogen til en uautorisert bruker.
Det er instruksjoner om hvordan du gjengir alt jeg fortalte deg. Det er filer med produksjonseksempler på hvordan ResourceQuota og Pod Security Policy ser ut. Og du kan ta på alt dette.
Takk alle sammen
Kilde: www.habr.com