Pavel Selivanov, Southbridge-løsningsarkitekt og Slurm-lærer, holdt et foredrag på DevOpsConf 2019. Dette foredrag er en del af et af emnerne på Slurm Mega Advanced Kubernetes-kurset.
finder sted i Moskva den 18.-20. november.
- Moskva, 22.-24. november.
altid tilgængelig.
Under klippet - udskrift af rapporten.
God eftermiddag, kolleger og sympatisører. I dag vil jeg tale om sikkerhed.
Jeg kan se, at der er mange sikkerhedsfolk i hallen i dag. Jeg undskylder på forhånd over for dig, hvis jeg bruger termer fra sikkerhedsverdenen, som ikke er helt som du plejer.
Det skete så, at for omkring seks måneder siden faldt en offentlig Kubernetes-klynge i mine hænder. Offentlig - betyder, at der er n-te antal navnerum, i disse navnerum er der brugere isoleret i deres navnerum. Alle disse brugere tilhører forskellige virksomheder. Nå, det blev antaget, at denne klynge skulle bruges som en CDN. Det vil sige, de giver dig en klynge, giver en bruger der, du går derhen i dit navneområde, implementerer dine fronter.
Mit tidligere firma forsøgte at sælge sådan en service. Og jeg blev bedt om at stikke i klyngen om emnet - om en sådan løsning er egnet eller ej.
Jeg kom til denne klynge. Jeg fik begrænsede rettigheder, begrænset navnerum. Der forstod fyrene, hvad sikkerhed er. De læste, hvad Rollebaseret adgangskontrol (RBAC) er i Kubernetes – og de snoede det, så jeg ikke kunne køre pods adskilt fra implementeringer. Jeg kan ikke huske det problem, jeg prøvede at løse ved at køre en pod uden implementering, men jeg ville virkelig bare køre en pod. Jeg besluttede mig for held og lykke for at se, hvilke rettigheder jeg har i klyngen, hvad jeg kan gøre, hvad jeg ikke kan, hvad de har lavet om der. Samtidig vil jeg fortælle dig, hvad de har konfigureret forkert i RBAC.
Det skete sådan, at jeg på to minutter fik en admin til deres klynge, kiggede på alle de tilstødende navneområder, så produktionsfronterne for virksomheder, der allerede havde købt tjenesten og implementeret der. Jeg stoppede næsten ikke mig selv for ikke at komme til nogen foran og sætte nogle bandeord på hovedsiden.
Jeg vil fortælle dig med eksempler, hvordan jeg gjorde det, og hvordan man forsvarer sig imod det.
Men først, lad mig præsentere mig selv. Mit navn er Pavel Selivanov. Jeg er arkitekt for Southbridge. Jeg forstår Kubernetes, DevOps og alle mulige smarte ting. Southbridge-ingeniørerne og jeg bygger det hele, og jeg rådgiver.
Ud over vores hovedaktiviteter har vi for nylig lanceret projekter kaldet Slurms. Vi forsøger at bringe vores evne til at arbejde med Kubernetes til masserne lidt, for også at lære andre mennesker, hvordan man arbejder med K8'er.
Hvad vil jeg tale om i dag. Emnet for rapporten er indlysende - om sikkerheden i Kubernetes-klyngen. Men jeg vil med det samme sige, at dette emne er meget stort – og derfor vil jeg præcisere med det samme, hvad jeg bestemt ikke vil tale om. Jeg vil ikke tale om forfalskede udtryk, der allerede er blevet overbrugt hundrede gange på internettet. Eventuelle RBAC og certifikater.
Jeg vil tale om, hvad der sårer mig og mine kolleger fra sikkerhed i en Kubernetes-klynge. Vi ser disse problemer både hos udbydere, der leverer Kubernetes-klynger, og hos kunder, der kommer til os. Og endda for kunder, der kommer til os fra andre konsulentfirmaer. Det vil sige, at omfanget af tragedien faktisk er meget stort.
Tre punkter, som jeg vil tale om i dag:
- Brugerrettigheder vs pod-rettigheder. Brugerrettigheder og pod-rettigheder er ikke det samme.
- Indsamling af information om klyngen. Jeg vil vise, at du kan samle alle de oplysninger, du har brug for, fra en klynge uden at have særlige rettigheder i denne klynge.
- DoS-angreb på klyngen. Hvis vi undlader at indsamle oplysninger, vil vi være i stand til at sætte klyngen under alle omstændigheder. Jeg vil tale om DoS-angreb på klyngekontrolelementer.
En anden generel ting, som jeg vil nævne, er, hvad jeg testede det hele på, hvorpå jeg med sikkerhed kan sige, at det hele virker.
Som udgangspunkt tager vi installationen af en Kubernetes-klynge ved hjælp af Kubespray. Hvis nogen ikke ved det, er dette faktisk et sæt roller for Ansible. Vi bruger det hele tiden på arbejdet. Det gode er, at du kan rulle overalt – og du kan rulle på jernstykkerne, og et sted i skyen. Én monteringsmetode er i princippet velegnet til alt.
I denne klynge vil jeg have Kubernetes v1.14.5. Hele Cube-klyngen, som vi vil overveje, er opdelt i navnerum, hvert navneområde tilhører et separat team, medlemmer af dette team har adgang til hvert navneområde. De kan ikke gå til forskellige navneområder, kun til deres eget. Men der er en bestemt administratorkonto, der har rettigheder til hele klyngen.
Jeg lovede, at det første, vi vil have, er at få administratorrettigheder til klyngen. Vi har brug for en specielt forberedt pod, der vil bryde Kubernetes-klyngen. Alt, hvad vi skal gøre, er at anvende det på Kubernetes-klyngen.
kubectl apply -f pod.yamlDenne pod kommer til en af mestrene i Kubernetes-klyngen. Og klyngen vil med glæde returnere en fil kaldet admin.conf efter det. I Cuba gemmer denne fil alle admin-certifikater, og samtidig konfigureres klynge-API'en. Sådan er det nemt at få administratoradgang, tror jeg, til 98% af Kubernetes-klynger.
Igen, denne pod blev lavet af en udvikler i din klynge, som har adgang til at implementere deres forslag i et lille navneområde, han er alle fastklemt af RBAC. Han havde ingen rettigheder. Men ikke desto mindre vendte certifikatet tilbage.
Og nu om et specielt forberedt ildsted. Vi starter på ethvert billede. Lad os tage debian:jessie som et eksempel.
Vi har sådan noget:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Hvad er tolerance? Mestere i en Kubernetes-klynge er normalt mærket med en ting, der kaldes taint. Og essensen af denne "infektion" er, at den siger, at pods ikke kan tildeles master noder. Men ingen gider at angive i nogen pod, at den er tolerant over for "infektionen". Tolerationsafsnittet siger bare, at hvis NoSchedule er installeret på en eller anden node, så er vores pod tolerant over for sådan en infektion - og der er ingen problemer.
Yderligere siger vi, at vores pod ikke kun er tolerant, men også ønsker at ramme mesteren med vilje. Fordi mestrene har det lækreste, som vi har brug for - alle certifikaterne. Derfor siger vi nodeSelector - og vi har et standardmærke på masterne, som giver dig mulighed for at vælge fra alle klyngens noder præcis de noder, der er mastere.
Med disse to sektioner vil det helt sikkert komme til mesteren. Og han får lov at bo der.
Men bare at komme til mesteren er ikke nok for os. Det vil ikke give os noget. Så nu har vi disse to ting:
hostNetwork: true
hostPID: true Vi specificerer, at vores pod, vi kører, vil leve i kernenavneområdet, netværksnavnerummet og PID-navnerummet. Når en pod kører på masteren, vil den være i stand til at se alle de rigtige, live-grænseflader for den node, lytte til al trafik og se PID'erne for alle processer.
Så er det op til de små ting. Tag etcd og læs hvad du vil.
Det mest interessante er denne Kubernetes-funktion, som er der som standard.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Og dens essens er, at vi i den pod, vi lancerer, selv uden rettigheder til denne klynge, kan sige, at vi vil oprette en volumen af typen hostPath. Så tag stien fra værten, som vi starter på - og tag den som volumen. Og så kalder vi det navn: vært. Vi monterer hele denne hostPath inde i poden. I dette eksempel til mappen /host.
Endnu en gang vil jeg gentage. Vi bad poden om at komme til masteren, hente hostNetwork og hostPID der - og montere hele masterens rod inde i denne pod.
Du forstår, at i debian har vi bash kørende, og denne bash fungerer for os som root. Det vil sige, at vi lige har fået rod på masteren, mens vi ikke har nogen rettigheder i Kubernetes-klyngen.
Så er hele opgaven at gå ind i mappen / host / etc / kubernetes / pki, hvis jeg ikke tager fejl, henter du alle klyngens mastercertifikater der og bliver derfor klyngeadministrator.
Når de ses på denne måde, er disse nogle af de farligste rettigheder i pods, uanset hvilke rettigheder brugeren har:
Hvis jeg har rettigheder til at køre en pod i et klyngenavneområde, så har denne pod disse rettigheder som standard. Jeg kan køre privilegerede pods, hvilket generelt er alle rettigheder, og praktisk talt rooting en node.
Min favorit er root-bruger. Og Kubernetes har denne mulighed for Kør som ikke-rod. Dette er en form for beskyttelse mod en hacker. Ved du, hvad den "moldoviske virus" er? Hvis du pludselig er en hacker og kom til min Kubernetes-klynge, så spørger vi, stakkels administratorer: "Venligst angiv i dine pods, med hvilken du vil hacke min klynge, køre som ikke-root. Ellers vil det vise sig, at du starter processen i din pod under roden, og det vil være meget nemt for dig at hacke mig. Beskyt dig selv, tak."
Værtsstivolumen - efter min mening den hurtigste måde at få det ønskede resultat fra Kubernetes-klyngen.
Men hvad skal man gøre med alt dette?
Tanker, der burde komme til enhver normal administrator, der støder på Kubernetes: "Ja, jeg fortalte dig, Kubernetes virker ikke. Der er huller i den. Og hele terningen er noget lort.” Faktisk er der sådan noget som dokumentation, og hvis man kigger der, så er der et afsnit .
Dette er sådan et yaml-objekt - vi kan oprette det i Kubernetes-klyngen - som styrer sikkerhedsaspekterne i beskrivelsen af pods. Det vil sige, at det faktisk kontrollerer rettighederne til at bruge ethvert værtsnetværk, hostPID, visse volumentyper, der er i pods ved opstart. Ved hjælp af Pod Security Policy kan alt dette beskrives.
Det mest interessante ved Pod-sikkerhedspolitikken er, at i Kubernetes-klyngen er alle PSP-installatører ikke bare ikke beskrevet på nogen måde, de er simpelthen slået fra som standard. Pod Security Policy er aktiveret ved hjælp af adgangsplugin.
Okay, lad os implementere Pod Security Policy til klyngen, lad os sige, at vi har nogle service pods i navnerummet, som kun administratorer har adgang til. Lad os sige, at i alt det andet har pods begrænsede rettigheder. Fordi udviklere højst sandsynligt ikke behøver at køre privilegerede pods på din klynge.
Og vi ser ud til at have det godt. Og vores Kubernetes-klynge kan ikke hackes på to minutter.
Der er et problem. Mest sandsynligt, hvis du har en Kubernetes-klynge, er overvågning installeret i din klynge. Jeg påtager mig endda at forudsige, at hvis din klynge har overvågning, så hedder den Prometheus.
Det, jeg vil fortælle dig nu, vil være gyldigt både for Prometheus-operatøren og for Prometheus leveret i sin rene form. Spørgsmålet er, hvis jeg ikke kan få en admin til klyngen så hurtigt, så betyder det, at jeg skal søge mere. Og jeg kan søge ved hjælp af din overvågning.
Sandsynligvis læser alle de samme artikler om Habré, og overvågning er placeret i overvågningsnavnerummet. Hjelmdiagram kaldes omtrent det samme for alle. Mit gæt er, at hvis du installerer helm stabil/prometheus, bør du ende med nogenlunde de samme navne. Og selv højst sandsynligt behøver jeg ikke gætte DNS-navnet i din klynge. Fordi det er standard.
Dernæst har vi en bestemt dev ns, hvor du kan køre en bestemt pod. Og så fra denne pod er det meget nemt at gøre sådan her:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics er en af de prometheus-eksportører, der indsamler metrics fra selve Kubernetes API. Der er en masse data der, hvad der kører i din klynge, hvad er det, hvilke problemer du har med det.
Som et simpelt eksempel:
kube_pod_container_info{namespace="kube-system",pod="kube-apiserver-k8s-1",container="kube-apiserver",image=
"gcr.io/google-containers/kube-apserver:v1.14.5"
,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1
Ved at lave en simpel krølleanmodning fra en uprivilegeret pod, kan du få information som denne. Hvis du ikke ved, hvilken version af Kubernetes du kører, vil den nemt fortælle dig.
Og det mest interessante er, at udover at du tilgår kube-state-metrics, så kan du lige så godt få direkte adgang til selve Prometheus. Du kan indsamle metrics derfra. Du kan endda bygge metrics derfra. Selv teoretisk kan du bygge sådan en forespørgsel fra en klynge i Prometheus, som simpelthen vil slå den fra. Og din overvågning vil generelt holde op med at virke fra klyngen.
Og her melder spørgsmålet sig allerede, om nogen ekstern overvågning overvåger din overvågning. Jeg har lige fået muligheden for at operere i en Kubernetes-klynge uden konsekvenser for mig selv overhovedet. Du vil ikke engang vide, at jeg arbejder der, da overvågning ikke længere er der.
Ligesom med PSP, føles det som om problemet er, at alle disse smarte teknologier - Kubernetes, Prometheus - de bare ikke virker og er fulde af huller. Ikke rigtig.
Der er sådan noget - .
Hvis du er en normal administrator, så ved du højst sandsynligt om Network Policy, at dette er en anden yaml, som der allerede er dofiga af i klyngen. Og netværkspolitikker er absolut ikke nødvendige. Og selvom du læser, hvad netværkspolitik er, hvad det er en Kubernetes yaml firewall, det giver dig mulighed for at begrænse adgangsrettigheder mellem navneområder, mellem pods, så besluttede du bestemt, at yaml firewallen i Kubernetes er baseret på de næste abstraktioner ... Nej-nej. Det er bestemt ikke nødvendigt.
Selvom dine sikkerhedsspecialister ikke fik at vide, at du ved hjælp af dine Kubernetes kan bygge en meget nem og enkel firewall, og meget detaljeret. Hvis de ikke ved det endnu og ikke trækker dig: "Nå, giv det, giv det ..." Så skal du under alle omstændigheder bruge Network Policy for at blokere adgangen til nogle tjenestesteder, som du kan trække fra din klynge uden nogen autorisation.
Som i eksemplet, jeg gav, kan du trække kube-tilstandsmålinger fra ethvert navneområde i Kubernetes-klyngen uden at have nogen rettigheder til at gøre det. Netværkspolitikker har lukket adgang fra alle andre navneområder til overvågningsnavneområdet og så at sige alt: ingen adgang, ingen problemer. I alle de diagrammer, der findes, både standardprometheus og prometheus, der er i operatøren, er der simpelthen en mulighed i rorets værdier for blot at aktivere netværkspolitikker for dem. Du skal bare tænde den, og de vil virke.
Der er virkelig ét problem her. Som en normal skægget administrator har du højst sandsynligt besluttet, at netværkspolitikker ikke er nødvendige. Og efter at have læst alle mulige artikler om ressourcer som Habr, besluttede du, at flannel, især med host-gateway-tilstanden, er det bedste, du kan vælge.
Hvad skal jeg gøre?
Du kan prøve at ominstallere den netværksløsning, du har i din Kubernetes-klynge, prøv at erstatte den med noget mere funktionelt. På samme Calico f.eks. Men med det samme vil jeg sige, at opgaven med at ændre netværksløsningen i den fungerende Kubernetes-klynge er ret ikke-triviel. Jeg løste det to gange (begge gange dog teoretisk), men vi viste endda, hvordan man gør det på Slurms. For vores studerende viste vi, hvordan man ændrer netværksløsningen i en Kubernetes-klynge. I princippet kan man forsøge at sikre sig, at der ikke er nedetid på produktionsklyngen. Men det lykkes nok ikke.
Og problemet er faktisk løst meget enkelt. Der er certifikater i klyngen, og du ved, at dine certifikater bliver dårlige om et år. Nå, og som regel en normal løsning med certifikater i klyngen - hvorfor skal vi tage et dampbad, vi rejser en ny klynge ved siden af, lader den gå råddent i den gamle, og omplacerer alt. Sandt nok, når det rådner, vil alt ligge ned i en dag, men så en ny klynge.
Når du rejser en ny klynge, skal du samtidig indsætte Calico i stedet for flannel.
Hvad skal du gøre, hvis du har certifikater udstedt i hundrede år, og du ikke har tænkt dig at omplacere klyngen? Der er sådan noget Kube-RBAC-Proxy. Dette er en meget cool udvikling, den giver dig mulighed for at indlejre sig selv som en sidevognsbeholder til enhver pod i en Kubernetes-klynge. Og det tilføjer faktisk autorisation gennem RBAC af Kubernetes selv til denne pod.
Der er et problem. Tidligere var denne Kube-RBAC-Proxy-løsning indbygget i operatørens prometheus. Men så var han væk. Nu er moderne versioner afhængige af, at du har netværkspolitikker og lukker dem med dem. Og så skal du omskrive diagrammet lidt. Faktisk, hvis du går til , der er eksempler på, hvordan man bruger det som sidevogne, og søkortene skal omskrives minimalt.
Der er endnu et lille problem. Ikke kun Prometheus giver sine metrics væk til nogen. I vores tilfælde er alle komponenter i Kubernetes-klyngen også i stand til at give deres metrics.
Men som sagt, hvis du ikke kan få adgang til klyngen og indsamle information, så kan du i det mindste gøre skade.
Så jeg vil hurtigt vise dig to måder, hvorpå en Kubernetes-klynge kan blive syg.
Du vil grine, når jeg fortæller dig, det er to sager fra det virkelige liv.
Metode et. Ressourceudmattelse.
Vi lancerer endnu en speciel pod. Det vil have denne sektion.
resources:
requests:
cpu: 4
memory: 4Gi Som du ved, er anmodninger mængden af CPU og hukommelse, der er reserveret på værten til specifikke anmodningspods. Hvis vi har en fire-core vært i Kubernetes-klyngen, og fire CPU-pods ankommer der med anmodninger, så kan der ikke komme flere pods med anmodninger til denne vært.
Hvis jeg kører sådan en pod, så udsteder jeg kommandoen:
$ kubectl scale special-pod --replicas=...Så vil ingen andre være i stand til at implementere til Kubernetes-klyngen. Fordi alle noder løber tør for anmodninger. Og så vil jeg stoppe din Kubernetes-klynge. Hvis jeg gør dette om aftenen, så kan udsendelserne stoppes i ret lang tid.
Hvis vi igen ser på Kubernetes-dokumentationen, vil vi se sådan noget, der hedder Limit Range. Den indstiller ressourcerne for klyngeobjekterne. Du kan skrive et Limit Range-objekt i yaml, anvende det på bestemte navneområder - og længere inde i dette navneområde kan du sige, at du har ressourcer til standard-, maksimum- og minimum-pods.
Ved hjælp af sådan en ting kan vi begrænse brugere i specifikke teamproduktnavneområder fra muligheden for at angive alle mulige grimme ting på deres pods. Men desværre, selvom du fortæller brugeren, at du ikke kan køre pods med anmodninger om mere end én CPU, er der sådan en vidunderlig skaleringskommando, ja, eller gennem dashboardet kan de skalere.
Og det er her nummer to kommer ind. Løb 11 111 111 111 111 bælg. Det er elleve milliarder. Det er ikke fordi jeg fandt på sådan et nummer, men fordi jeg selv så det.
Rigtig historie. Sidst på aftenen var jeg ved at forlade kontoret. Jeg ser, en gruppe udviklere sidder i hjørnet og laver febrilsk noget med bærbare computere. Jeg går hen til fyrene og spørger: "Hvad skete der med jer?"
Lidt tidligere, klokken ni om aftenen, skulle en af udviklerne hjem. Og jeg besluttede: "Nu vil jeg skalere min ansøgning til en." Jeg trykkede på en, og internettet blev lidt sløvt. Han trykkede på den ene igen, han trykkede på den ene, tryk på Enter. Han stak alt, hvad han kunne. Så kom internettet til live - og alt begyndte at skalere op til denne dato.
Sandt nok fandt denne historie ikke sted på Kubernetes, på det tidspunkt var det Nomad. Det endte med, at efter en times forsøg på at stoppe Nomad fra stædige forsøg på at skalere, svarede Nomad, at han ikke ville stoppe med at skalere og ikke gøre andet. "Jeg er træt, jeg går." Og vendte sig om.
Jeg prøvede naturligvis at gøre det samme på Kubernetes. Elleve milliarder pods Kubernetes ikke behagede, sagde han: "Jeg kan ikke. Overstiger interne hætter. Men 1 bælg kunne.
Som svar på en milliard trak kuben sig ikke ind i sig selv. Han begyndte virkelig at skalere. Jo længere processen gik, jo mere tid tog det at oprette nye pods. Men processen fortsatte alligevel. Det eneste problem er, at hvis jeg kan køre pods i mit navneområde på ubestemt tid, så selv uden anmodninger og begrænsninger, kan jeg køre sådan et antal pods med nogle opgaver, at ved hjælp af disse opgaver vil noderne begynde at lægge sig sammen fra hukommelsen, på CPU'en. Når jeg kører så mange pods, skal informationen fra dem ind i lageret, altså osv. Og når der kommer for meget information ind, begynder lagringen at give tilbage for langsomt – og Kubernetes begynder at blive sløv.
Og endnu et problem ... Som du ved, er Kubernetes kontroller ikke en slags central ting, men flere komponenter. Der er der især en controller manager, skemalægger og så videre. Alle disse fyre vil begynde at lave unødvendigt dumt arbejde på samme tid, som med tiden vil begynde at tage mere og mere tid. Controllermanageren vil oprette nye pods. Scheduler vil forsøge at finde en ny node til dem. Nye noder i din klynge vil højst sandsynligt snart løbe tør. Kubernetes-klyngen vil begynde at køre langsommere og langsommere.
Men jeg besluttede at gå endnu længere. Som du ved, har Kubernetes noget, der hedder en tjeneste. Nå, som standard i dine klynger, fungerer tjenesten højst sandsynligt ved hjælp af IP-tabeller.
Hvis du for eksempel kører en milliard pods og derefter bruger et script til at tvinge Kubernetis til at oprette 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 blive genereret omtrent samtidigt. Desuden vil der blive genereret en milliard iptables-regler for hver tjeneste.
Jeg tjekkede det hele på flere tusinde, op til et dusin. Og problemet er, at det allerede ved denne tærskel er ret problematisk at lave ssh til noden. Fordi pakker, der passerer gennem så mange kæder, begynder at føles ikke særlig godt.
Og det hele er også løst ved hjælp af Kubernetes. Der er sådan et objekt Ressourcekvote. Indstiller antallet af tilgængelige ressourcer og objekter for navneområdet i klyngen. Vi kan oprette et yaml-objekt i hvert Kubernetes-klyngenavneområde. Ved hjælp af dette objekt kan vi sige, at vi har et vist antal anmodninger, begrænsninger tildelt for dette navneområde, og yderligere kan vi sige, at det er muligt at oprette 10 tjenester og 10 pods i dette navneområde. Og en enkelt udvikler kan endda knuse sig selv om aftenen. Kubernetes vil fortælle ham: "Du kan ikke skalere dine pods til et sådant beløb, fordi det overskrider ressourcekvoten." Det er det, problemet løst. .
Et problem opstår i forbindelse hermed. Du mærker, hvor svært det bliver at skabe et navneområde i Kubernetes. For at skabe det skal vi tage højde for en masse ting.
Ressourcekvote + grænseområde + RBAC
• Opret et navneområde
• Opret indvendigt grænseområde
• Opret indvendigt ressourcekvote
• Opret en servicekonto til CI
• Opret rollebinding for CI og brugere
• Start eventuelt de nødvendige servicepods
Derfor, ved at benytte denne lejlighed, vil jeg gerne dele min udvikling. Der er sådan noget, der hedder SDK-operatøren. Dette er måden i Kubernetes-klyngen at skrive udsagn til den. Du kan skrive udsagn med Ansible.
Først skrev vi i Ansible, og så kiggede jeg på, hvad SDK-operatøren var og omskrev Ansible-rollen til en operatør. Denne sætning giver dig mulighed for at oprette et objekt i Kubernetes-klyngen kaldet en kommando. Inde i kommandoen giver den dig mulighed for i yaml at beskrive miljøet for denne kommando. Og inde i teammiljøet giver det os mulighed for at beskrive, at vi allokerer så mange ressourcer.
petite .
Og afslutningsvis. Hvad skal man gøre med alt dette?
Først. Pod Security Policy er god. Og på trods af at ingen af Kubernetes-installatørerne bruger dem den dag i dag, skal du stadig bruge dem i dine klynger.
Netværkspolitik er ikke en anden unødvendig funktion. Det er det, der virkelig er brug for i klyngen.
LimitRange / ResourceQuota - det er tid til at bruge. Vi begyndte at bruge det for længe siden, og jeg var længe sikker på, at alle uden undtagelse bruger det. Det viste sig, at dette er sjældent.
Ud over det, jeg nævnte under rapporten, er der udokumenterede funktioner, der giver dig mulighed for at angribe klyngen. Udgivet for nylig .
Nogle ting er så triste og sårende. For eksempel, under visse forhold, kan cubeletter i en Kubernetes-klynge give indholdet af warlocks-biblioteket og til en uautoriseret bruger.
der er instruktioner om, hvordan man gengiver alt, hvad jeg sagde. Der er filer med produktionseksempler, hvordan ResourceQuota, Pod Security Policy ser ud. Og alt dette kan røres.
Tak til alle.
Kilde: www.habr.com