Pavel Selivanov, Southbridge-lösningsarkitekt och Slurm-lärare, höll en presentation på DevOpsConf 2019. Det här föredraget är en del av ett av ämnena i den fördjupade kursen om Kubernetes ”Slurm Mega”.
äger rum i Moskva den 18-20 november.
— Moskva, 22-24 november.
alltid tillgänglig.
Nedanför klippet finns en utskrift av rapporten.
God eftermiddag, kollegor och de som sympatiserar med dem. Idag ska jag prata om säkerhet.
Jag ser att det är många ordningsvakter i hallen idag. Jag ber dig om ursäkt i förväg om jag använder termer från säkerhetsvärlden inte exakt som är brukligt för dig.
Det hände så att jag för ungefär ett halvår sedan stötte på ett offentligt Kubernetes-kluster. Offentlig betyder att det finns ett n:e antal namnutrymmen, i dessa namnutrymmen finns det användare isolerade i deras namnutrymme. Alla dessa användare tillhör olika företag. Tja, det antogs att detta kluster skulle användas som ett CDN. Det vill säga, de ger dig ett kluster, de ger dig en användare där, du går dit till ditt namnområde, distribuerar dina fronter.
Mitt tidigare företag försökte sälja en sådan tjänst. Och jag blev ombedd att peta i klustret för att se om den här lösningen var lämplig eller inte.
Jag kom till det här klustret. Jag fick begränsade rättigheter, begränsad namnutrymme. Killarna där förstod vad säkerhet var. De läste om rollbaserad åtkomstkontroll (RBAC) i Kubernetes – och de vred på det så att jag inte kunde starta pods separat från implementeringar. Jag kommer inte ihåg problemet jag försökte lösa genom att starta en pod utan distribution, men jag ville verkligen bara starta en pod. För lycka till, bestämde jag mig för att se vilka rättigheter jag har i klustret, vad jag kan göra, vad jag inte kan göra och vad de har skruvat till där. Samtidigt ska jag berätta vad de har konfigurerat fel i RBAC.
Det hände så att jag på två minuter fick en administratör till deras kluster, tittade på alla närliggande namnområden, såg där de löpande produktionsfronterna för företag som redan hade köpt tjänsten och implementerat. Jag kunde knappt stoppa mig själv från att gå till någons front och sätta några svordomar på huvudsidan.
Jag kommer att berätta med exempel hur jag gjorde detta och hur du skyddar dig från detta.
Men först, låt mig presentera mig själv. Jag heter Pavel Selivanov. Jag är arkitekt på Southbridge. Jag förstår Kubernetes, DevOps och alla möjliga tjusiga saker. Southbridge-ingenjörerna och jag bygger allt detta, och jag konsulterar.
Utöver våra huvudaktiviteter har vi nyligen lanserat projekt som kallas Slurms. Vi försöker få ut vår förmåga att arbeta med Kubernetes lite till massorna, för att lära andra människor att också arbeta med K8:or.
Vad ska jag prata om idag? Ämnet för rapporten är uppenbart - om säkerheten för Kubernetes-klustret. Men jag vill genast säga att det här ämnet är väldigt stort - och därför vill jag omedelbart klargöra vad jag definitivt inte kommer att prata om. Jag kommer inte att prata om hackade termer som redan har använts hundra gånger om på Internet. Alla typer av RBAC och certifikat.
Jag kommer att prata om vad som plågar mig och mina kollegor när det gäller säkerhet i ett Kubernetes-kluster. Vi ser dessa problem både bland leverantörer som tillhandahåller Kubernetes-kluster och bland kunder som kommer till oss. Och även från kunder som kommer till oss från andra konsultföretag. Det vill säga omfattningen av tragedin är faktiskt mycket stor.
Det finns bokstavligen tre punkter som jag kommer att prata om idag:
- Användarrättigheter kontra poddrättigheter. Användarrättigheter och poddrättigheter är inte samma sak.
- Samlar information om klustret. Jag ska visa att du kan samla all information du behöver från ett kluster utan att ha särskilda rättigheter i detta kluster.
- DoS-attack på klustret. Om vi inte kan samla in information kommer vi att kunna lägga ett kluster i alla fall. Jag kommer att prata om DoS-attacker på klusterkontrollelement.
En annan allmän sak som jag kommer att nämna är vad jag testade allt detta på, på vilket jag definitivt kan säga att allt fungerar.
Vi utgår från installationen av ett Kubernetes-kluster med Kubespray. Om någon inte vet så är detta faktiskt en uppsättning roller för Ansible. Vi använder det ständigt i vårt arbete. Det som är bra är att du kan rulla den var som helst - du kan rulla den på järnbitar eller till ett moln någonstans. En installationsmetod fungerar i princip för allt.
I detta kluster kommer jag att ha Kubernetes v1.14.5. Hela Cube-klustret, som vi kommer att överväga, är uppdelat i namnutrymmen, varje namnområde tillhör ett separat team och medlemmar i detta team har tillgång till varje namnområde. De kan inte gå till olika namnutrymmen, bara till sina egna. Men det finns ett visst administratörskonto som har rättigheter till hela klustret.
Jag lovade att det första vi kommer att göra är att skaffa administratörsrättigheter till klustret. Vi behöver en speciellt förberedd pod som kommer att bryta Kubernetes-klustret. Allt vi behöver göra är att applicera det på Kubernetes-klustret.
kubectl apply -f pod.yamlDenna pod kommer till en av mästarna i Kubernetes-klustret. Och efter detta kommer klustret gärna att returnera en fil som heter admin.conf till oss. I Cube lagrar den här filen alla administratörscertifikat och konfigurerar samtidigt kluster-API:et. Så enkelt är det att få administratörsåtkomst till, tror jag, 98 % av Kubernetes-klustren.
Jag upprepar, den här podden gjordes av en utvecklare i ditt kluster som har tillgång till att distribuera sina förslag i ett litet namnutrymme, allt är fastspänt av RBAC. Han hade inga rättigheter. Men inte desto mindre returnerades certifikatet.
Och nu om en speciellt förberedd pod. Vi kör det på vilken bild som helst. Låt oss ta debian:jessie som ett exempel.
Vi har den här saken:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Vad är tolerans? Mästare i ett Kubernetes-kluster är vanligtvis markerade med något som kallas taint. Och kärnan i denna "infektion" är att den säger att pods inte kan tilldelas masternoder. Men ingen bryr sig om att ange i någon pod att den är tolerant mot "infektionen". Tolerationssektionen säger bara att om någon nod har NoSchedule, så är vår nod tolerant mot en sådan infektion - och det finns inga problem.
Vidare säger vi att vår under inte bara är tolerant, utan också vill rikta in sig på mästaren. För mästarna har det läckraste vi behöver - alla certifikat. Därför säger vi nodeSelector - och vi har en standardetikett på masters, som låter dig välja från alla noder i klustret exakt de noder som är masters.
Med dessa två avsnitt kommer han definitivt att komma till mästaren. Och han ska få bo där.
Men att bara komma till mästaren räcker inte för oss. Det här ger oss ingenting. Så härnäst har vi dessa två saker:
hostNetwork: true
hostPID: true Vi specificerar att vår pod, som vi lanserar, kommer att finnas i kärnans namnutrymme, i nätverkets namnutrymme och i PID-namnområdet. När podden väl har lanserats på mastern kommer den att kunna se alla verkliga, levande gränssnitt för denna nod, lyssna på all trafik och se PID för alla processer.
Sen handlar det om småsaker. Ta etcd och läs vad du vill.
Det mest intressanta är den här Kubernetes-funktionen, som finns där som standard.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host Och dess kärna är att vi kan säga i podden som vi lanserar, även utan rättigheter till detta kluster, att vi vill skapa en volym av typen hostPath. Detta innebär att vi tar vägen från den värd som vi kommer att lansera på – och tar den som volym. Och då kallar vi det namnet: värd. Vi monterar hela denna hostPath inuti podden. I det här exemplet, till katalogen /host.
Jag ska upprepa det igen. Vi sa åt podden att komma till mastern, hämta hostNetwork och hostPID där - och montera hela roten av mastern inuti denna pod.
Du förstår att i Debian har vi bash igång, och denna bash körs under root. Det vill säga, vi har precis fått root på mastern, utan att ha några rättigheter i Kubernetes-klustret.
Sedan är hela uppgiften att gå till underkatalogen /host /etc/kubernetes/pki, om jag inte har fel, plocka upp alla mastercertifikaten för klustret där och blir följaktligen klusteradministratör.
Om du ser på det så här är det här några av de farligaste rättigheterna i poddar – oavsett vilka rättigheter användaren har:
Om jag har rättigheterna att köra en pod i något namnområde i klustret, så har denna pod dessa rättigheter som standard. Jag kan köra privilegierade pods, och dessa är i allmänhet alla rättigheter, praktiskt taget rot på noden.
Min favorit är root-användare. Och Kubernetes har det här alternativet Kör som icke-rot. Detta är en typ av skydd från en hackare. Vet du vad det "moldaviska viruset" är? Om du plötsligt är en hackare och kommer till mitt Kubernetes-kluster, så frågar vi, stackars administratörer: "Vänligen ange i dina poddar med vilka du ska hacka mitt kluster, kör som icke-root. Annars händer det att du kör processen i din pod under root, och det blir väldigt lätt för dig att hacka mig. Snälla skydda dig från dig själv."
Värdsökvägsvolym är, enligt min mening, det snabbaste sättet att få önskat resultat från ett Kubernetes-kluster.
Men vad ska man göra med allt detta?
Tanken som borde komma till alla normala administratörer som möter Kubernetes är: "Ja, jag sa till dig, Kubernetes fungerar inte. Det finns hål i den. Och hela kuben är skitsnack.” Faktum är att det finns något som heter dokumentation, och tittar man där så finns det ett avsnitt .
Detta är ett yaml-objekt - vi kan skapa det i Kubernetes-klustret - som kontrollerar säkerhetsaspekter specifikt i beskrivningen av poddarna. Det vill säga, i själva verket kontrollerar den rättigheterna att använda alla värdnätverk, värdPID, vissa volymtyper som finns i poddarna vid start. Med hjälp av Pod Security Policy kan allt detta beskrivas.
Det mest intressanta med Pod Security Policy är att i Kubernetes-klustret är alla PSP-installatörer inte bara beskrivna på något sätt, de är helt enkelt inaktiverade som standard. Pod Security Policy är aktiverad med hjälp av admission plugin.
Okej, låt oss distribuera Pod Security Policy i klustret, låt oss säga att vi har några servicepods i namnutrymmet, som endast administratörer har åtkomst till. Låt oss säga att i alla andra fall har poddar begränsade rättigheter. Eftersom utvecklare troligen inte behöver köra privilegierade pods i ditt kluster.
Och allt verkar vara bra med oss. Och vårt Kubernetes-kluster kan inte hackas på två minuter.
Det finns ett problem. Troligtvis, om du har ett Kubernetes-kluster, är övervakning installerad på ditt kluster. Jag skulle till och med gå så långt som att förutsäga att om ditt kluster har övervakning kommer det att heta Prometheus.
Det jag ska berätta för dig kommer att gälla både för Prometheus-operatören och Prometheus levererad i sin rena form. Frågan är att om jag inte kan få in en administratör i klustret så snabbt, så betyder det att jag måste leta mer. Och jag kan söka med hjälp av din övervakning.
Förmodligen läser alla samma artiklar på Habré, och övervakningen finns i övervakningsnamnområdet. Helm chart kallas ungefär lika för alla. Jag gissar att om du gör helminstall stabil/prometheus, kommer du att få ungefär samma namn. Och troligtvis behöver jag inte ens gissa DNS-namnet i ditt kluster. För det är standard.
Därefter har vi en viss dev ns, där du kan köra en viss pod. Och sedan från den här podden är det väldigt lätt att göra något så här:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics är en av Prometheus-exportörerna som samlar in mätvärden från själva Kubernetes API. Det finns mycket data där, vad som körs i ditt kluster, vad det är, vilka problem du har med det.
Som ett enkelt exempel:
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
Genom att göra en enkel curl-förfrågan från en oprivilegierad pod kan du få följande information. Om du inte vet vilken version av Kubernetes du kör, kommer det lätt att berätta för dig.
Och det mest intressanta är att du, förutom att komma åt kube-state-metrics, lika enkelt kan komma åt själva Prometheus direkt. Du kan samla in mätvärden därifrån. Du kan till och med bygga mätvärden därifrån. Även teoretiskt sett kan du bygga en sådan fråga från ett kluster i Prometheus, vilket helt enkelt kommer att stänga av den. Och din övervakning kommer att sluta fungera från klustret helt och hållet.
Och här uppstår frågan om någon extern övervakning övervakar din övervakning. Jag har precis fått möjligheten att verka i ett Kubernetes-kluster utan några konsekvenser för mig själv. Du kommer inte ens veta att jag är verksam där, eftersom det inte längre finns någon övervakning.
Precis som med PSP känns det som att problemet är att alla dessa tjusiga teknologier – Kubernetes, Prometheus – de bara inte fungerar och är fulla av hål. Inte riktigt.
Det finns en sådan sak - .
Om du är en normal administratör, vet du troligen om Network Policy att detta bara är en annan yaml, som det redan finns många av i klustret. Och vissa nätverkspolicyer behövs definitivt inte. Och även om du läser vad nätverkspolicy är, att det är en yaml-brandvägg av Kubernetes, den låter dig begränsa åtkomsträttigheter mellan namnutrymmen, mellan poddar, då har du verkligen bestämt dig för att brandväggen i yaml-format i Kubernetes är baserad på nästa abstraktioner ... Nej nej . Detta är definitivt inte nödvändigt.
Även om du inte har berättat för dina säkerhetsspecialister att med dina Kubernetes kan du bygga en mycket enkel och enkel brandvägg, och en mycket detaljerad. Om de inte vet detta än och inte stör dig: "Ja, ge mig, ge mig..." Då behöver du i alla fall Network Policy för att blockera åtkomst till vissa tjänsteplatser som kan dras från ditt kluster utan tillstånd.
Som i exemplet jag gav kan du hämta kube-tillståndsmått från valfritt namnområde i Kubernetes-klustret utan att ha några rättigheter att göra det. Nätverkspolicyer har stängd åtkomst från alla andra namnområden till övervakningsnamnområdet och det är allt: ingen åtkomst, inga problem. I alla sjökort som finns, både standard Prometheus och Prometheus som finns i operatören, finns det helt enkelt ett alternativ i styrvärdena för att helt enkelt aktivera nätverkspolicyer för dem. Du behöver bara slå på den så fungerar de.
Det finns verkligen ett problem här. Eftersom du är en normal skäggig administratör har du troligen bestämt dig för att nätverkspolicyer inte behövs. Och efter att ha läst alla möjliga artiklar om resurser som Habr, bestämde du dig för att flanell, speciellt med värd-gateway-läge, är det bästa du kan välja.
Vad ska man göra?
Du kan prova att distribuera om nätverkslösningen som du har i ditt Kubernetes-kluster, försök att ersätta den med något mer funktionellt. För samma Calico, till exempel. Men jag vill genast säga att uppgiften att ändra nätverkslösningen i ett Kubernetes-arbetskluster är ganska otrivialt. Jag löste det två gånger (båda gångerna dock teoretiskt), men vi visade till och med hur man gör på Slurms. För våra studenter visade vi hur man ändrar nätverkslösningen i ett Kubernetes-kluster. I princip kan man försöka se till att det inte blir stillestånd på produktionsklustret. Men du kommer förmodligen inte att lyckas.
Och problemet är faktiskt löst väldigt enkelt. Det finns certifikat i klustret, och du vet att dina certifikat kommer att förfalla om ett år. Tja, och vanligtvis en normal lösning med certifikat i klustret - varför är vi oroliga, vi kommer att skapa ett nytt kluster i närheten, låta det gamla bli ruttet och omplacera allt. Det är sant att när det blir ruttet måste vi sitta en dag, men här är ett nytt kluster.
När du höjer ett nytt kluster, sätt samtidigt in Calico istället för flanell.
Vad ska man göra om dina certifikat utfärdas för hundra år och du inte tänker omplacera klustret? Det finns en sådan sak som Kube-RBAC-Proxy. Detta är en väldigt cool utveckling, den låter dig bädda in sig själv som en sidovagnsbehållare i valfri pod i Kubernetes-klustret. Och det lägger faktiskt till auktorisering till denna pod genom RBAC från Kubernetes själv.
Det finns ett problem. Tidigare var denna Kube-RBAC-Proxy-lösning inbyggd i operatörens Prometheus. Men sedan var han borta. Nu förlitar sig moderna versioner på det faktum att du har en nätverkspolicy och stänger den med hjälp av dem. Och därför måste vi skriva om diagrammet lite. Faktum är att om du går till , det finns exempel på hur man använder detta som sidovagnar, och sjökorten kommer att behöva skrivas om minimalt.
Det finns ytterligare ett litet problem. Prometheus är inte den enda som delar ut sin statistik till vem som helst. Alla våra Kubernetes-klusterkomponenter kan också returnera sina egna mätvärden.
Men som jag redan sa, om du inte kan komma åt klustret och samla in information, kan du åtminstone göra lite skada.
Så jag ska snabbt visa två sätt hur ett Kubernetes-kluster kan förstöras.
Du kommer att skratta när jag berättar det här, det här är två fall i verkligheten.
Metod ett. Utarmning av resurser.
Låt oss lansera en annan speciell pod. Det kommer att ha ett avsnitt som detta.
resources:
requests:
cpu: 4
memory: 4Gi Som du vet är förfrågningar mängden CPU och minne som är reserverat på värden för specifika pods med förfrågningar. Om vi har en fyrkärnig värd i ett Kubernetes-kluster, och fyra CPU-poddar kommer dit med förfrågningar, betyder det att inga fler poddar med förfrågningar kommer att kunna komma till den här värden.
Om jag kör en sådan pod kör jag kommandot:
$ kubectl scale special-pod --replicas=...Då kommer ingen annan att kunna distribuera till Kubernetes-klustret. Eftersom alla noder kommer att få slut på förfrågningar. Och därmed kommer jag att stoppa ditt Kubernetes-kluster. Om jag gör detta på kvällen kan jag stoppa utplaceringarna ganska länge.
Om vi tittar igen på Kubernetes-dokumentationen kommer vi att se det här som heter Limit Range. Den ställer in resurser för klusterobjekt. Du kan skriva ett Limit Range-objekt i yaml, applicera det på vissa namnutrymmen - och sedan i det här namnområdet kan du säga att du har standard-, max- och minimumresurser för poddarna.
Med hjälp av en sådan sak kan vi begränsa användare i specifika produktnamnrymder av team i möjligheten att indikera alla möjliga otäcka saker på deras poddar. Men tyvärr, även om du berättar för användaren att de inte kan starta pods med förfrågningar om mer än en CPU, finns det ett så underbart skalningskommando, eller så kan de skala genom instrumentpanelen.
Och det är härifrån metod nummer två kommer. Vi lanserar 11 pods. Det är elva miljarder. Det är inte för att jag kom på ett sådant nummer, utan för att jag såg det själv.
Verklig händelse. Sent på kvällen höll jag på att lämna kontoret. Jag ser en grupp utvecklare som sitter i hörnet och frenetiskt gör något med sina bärbara datorer. Jag går fram till killarna och frågar: "Vad hände med er?"
Lite tidigare, runt nio på kvällen, gjorde en av utvecklarna sig redo att åka hem. Och jag bestämde mig: "Jag ska nu skala ner min ansökan till en." Jag tryckte på en, men internet saktade ner lite. Han tryckte på den ena igen, han tryckte på den och klickade på Enter. Jag petade på allt jag kunde. Sedan vaknade internet till liv – och allt började skala ner till detta antal.
Det är sant att den här historien inte utspelade sig på Kubernetes; på den tiden var det Nomad. Det slutade med att efter en timme av våra försök att stoppa Nomad från ihärdiga försök att skala, svarade Nomad att han inte skulle sluta skala och inte göra något annat. "Jag är trött, jag går." Och han kröp ihop.
Naturligtvis försökte jag göra samma sak på Kubernetes. Kubernetes var inte nöjd med elva miljarder baljor, han sa: "Jag kan inte. Överskrider inre munskydd." Men 1 000 000 000 baljor kunde.
Som svar på en miljard drog sig inte kuben in i sig själv. Han började verkligen skala. Ju längre processen gick, desto mer tid tog det honom att skapa nya baljor. Men processen fortsatte ändå. Det enda problemet är att om jag kan starta poddar obegränsat i mitt namnutrymme, så kan jag även utan förfrågningar och begränsningar starta så många poddar med vissa uppgifter att med hjälp av dessa uppgifter kommer noderna att börja läggas ihop i minnet, i CPU. När jag startar så många poddar ska informationen från dem lagras, det vill säga etcd. Och när det kommer för mycket information dit börjar lagringen komma tillbaka för långsamt – och Kubernetes börjar bli matt.
Och ett problem till... Som ni vet är Kubernetes kontrollelement inte en central sak, utan flera komponenter. I synnerhet finns det en controller manager, schemaläggare och så vidare. Alla dessa killar kommer att börja göra onödigt, dumt arbete samtidigt, som med tiden kommer att börja ta mer och mer tid. Controllerhanteraren kommer att skapa nya pods. Schemaläggaren kommer att försöka hitta en ny nod för dem. Du kommer med största sannolikhet snart att få slut på nya noder i ditt kluster. Kubernetes-klustret kommer att börja arbeta långsammare och långsammare.
Men jag bestämde mig för att gå ännu längre. Som ni vet finns det i Kubernetes något sådant som kallas en tjänst. Tja, som standard i dina kluster, troligen, fungerar tjänsten med IP-tabeller.
Om du till exempel kör en miljard pods och sedan använder ett skript för att tvinga Kubernetis att skapa nya tjänster:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done På alla noder i klustret kommer fler och fler nya iptables-regler att genereras ungefär samtidigt. Dessutom kommer en miljard iptables-regler att genereras för varje tjänst.
Jag kollade hela det här på flera tusen, upp till tio. Och problemet är att det redan vid denna tröskel är ganska problematiskt att göra ssh till noden. Eftersom paket, som går genom så många kedjor, börjar kännas inte särskilt bra.
Och även detta löses allt med hjälp av Kubernetes. Det finns ett sådant Resurskvotobjekt. Ställer in antalet tillgängliga resurser och objekt för namnområdet i klustret. Vi kan skapa ett yaml-objekt i varje namnområde i Kubernetes-klustret. Med hjälp av det här objektet kan vi säga att vi har ett visst antal förfrågningar och gränser tilldelade för detta namnutrymme, och sedan kan vi säga att i detta namnutrymme är det möjligt att skapa 10 tjänster och 10 pods. Och en enda utvecklare kan åtminstone kväva sig själv på kvällarna. Kubernetes kommer att säga till honom: "Du kan inte skala dina poddar till det beloppet, eftersom resursen överskrider kvoten." Det var allt, problemet löst. .
En problematisk punkt uppstår i detta avseende. Du känner hur svårt det blir att skapa ett namnutrymme i Kubernetes. För att skapa det måste vi ta hänsyn till många saker.
Resurskvot + Limit Range + RBAC
• Skapa ett namnområde
• Skapa ett gränsområde inuti
• Skapa inre resurskvot
• Skapa ett servicekonto för CI
• Skapa rollbindning för CI och användare
• Starta eventuellt nödvändiga servicepods
Därför vill jag ta tillfället i akt att dela med mig av min utveckling. Det finns en sådan sak som heter SDK-operatören. Detta är ett sätt för ett Kubernetes-kluster att skriva operatorer för det. Du kan skriva påståenden med Ansible.
Först skrevs det i Ansible, och sedan såg jag att det fanns en SDK-operatör och skrev om Ansible-rollen till en operatör. Denna sats låter dig skapa ett objekt i Kubernetes-klustret som kallas ett kommando. Inuti ett kommando låter det dig beskriva miljön för detta kommando i yaml. Och inom teammiljön låter det oss beskriva att vi allokerar så mycket resurser.
petite .
Och avslutningsvis. Vad ska man göra med allt detta?
Först. Pod Security Policy är bra. Och trots att ingen av Kubernetes-installatörerna använder dem till denna dag, behöver du fortfarande använda dem i dina kluster.
Nätverkspolicy är inte bara en annan onödig funktion. Detta är vad som verkligen behövs i ett kluster.
LimitRange/ResourceQuota - det är dags att använda det. Vi började använda den här för länge sedan, och länge var jag säker på att alla använde den. Det visade sig att detta är sällsynt.
Utöver det jag nämnde under rapporten finns det odokumenterade funktioner som gör att du kan attackera klustret. Släpptes nyligen .
Vissa saker är så sorgliga och sårande. Till exempel, under vissa förhållanden, kan kubletter i ett Kubernetes-kluster ge innehållet i warlocks-katalogen till en obehörig användare.
Det finns instruktioner om hur du ska återskapa allt jag sa till dig. Det finns filer med produktionsexempel på hur ResourceQuota och Pod Security Policy ser ut. Och du kan röra allt detta.
Tack till alla.
Källa: will.com