Pavel Selivanov, Southbridge-oplossingsargitek en Slurm-onderwyser, het 'n praatjie gelewer by DevOpsConf 2019. Hierdie praatjie is deel van een van die onderwerpe van die Slurm Mega-gevorderde Kubernetes-kursus.
vind plaas in Moskou op 18-20 November.
- Moskou, 22-24 November.
altyd beskikbaar.
Onder die snit - transkripsie van die verslag.
Goeiemiddag, kollegas en simpatiseerders. Vandag sal ek oor sekuriteit praat.
Ek sien daar is vandag baie sekuriteitsmense in die saal. Ek vra jou by voorbaat om verskoning as ek terme uit die wêreld van sekuriteit gebruik nie heeltemal soos jy gewoonlik doen nie.
Dit het so gebeur dat ongeveer ses maande gelede een publieke Kubernetes-kluster in my hande geval het. Publiek - beteken dat daar n-de aantal naamruimtes is, in hierdie naamruimtes is daar gebruikers wat in hul naamruimte geïsoleer is. Al hierdie gebruikers behoort aan verskillende maatskappye. Wel, daar is aanvaar dat hierdie groep as 'n CDN gebruik moet word. Dit wil sê, hulle gee jou 'n cluster, gee 'n gebruiker daar, jy gaan daarheen in jou naamruimte, ontplooi jou fronte.
My vorige maatskappy het probeer om so 'n diens te verkoop. En ek is gevra om die cluster oor die onderwerp te steek - of so 'n oplossing geskik is of nie.
Ek het by hierdie cluster gekom. Ek het beperkte regte, beperkte naamruimte gekry. Daar het die ouens verstaan wat sekuriteit is. Hulle het gelees wat Rolgebaseerde toegangsbeheer (RBAC) in Kubernetes is – en hulle het dit so verdraai dat ek nie peule apart van ontplooiings kon laat loop nie. Ek onthou nie die probleem wat ek probeer oplos het deur 'n peul sonder ontplooiing te laat loop nie, maar ek wou regtig net 'n peul hardloop. Ek het vir geluk besluit om te sien watter regte ek in die cluster het, wat ek kan, wat ek nie kan nie, wat hulle daar opgefok het. Terselfdertyd sal ek jou vertel wat hulle verkeerd opgestel het in RBAC.
Dit het so gebeur dat ek binne twee minute 'n admin by hul cluster gekry het, na al die naburige naamruimtes gekyk het, die produksiefronte gesien het van maatskappye wat reeds die diens gekoop het en daar ontplooi het. Ek het skaars myself gestop om nie na iemand voor te kom en 'n paar vloekwoorde op die hoofblad te sit nie.
Ek sal jou met voorbeelde vertel hoe ek dit gedoen het en hoe om daarteen te verdedig.
Maar eers, laat ek myself voorstel. My naam is Pavel Selivanov. Ek is 'n argitek vir Southbridge. Ek verstaan Kubernetes, DevOps en allerhande fancy goed. Ek en die Southbridge-ingenieurs bou dit alles, en ek konsulteer.
Benewens ons hoofaktiwiteite, het ons onlangs projekte genaamd Slurms van stapel gestuur. Ons probeer om ons vermoë om met Kubernetes te werk 'n bietjie na die massas te bring, om ander mense ook te leer hoe om met K8's te werk.
Waaroor sal ek vandag praat. Die onderwerp van die verslag is voor die hand liggend - oor die veiligheid van die Kubernetes-kluster. Maar ek wil dadelik sê dat hierdie onderwerp baie groot is – en daarom wil ek dadelik spesifiseer waaroor ek beslis nie sal praat nie. Ek sal nie praat oor afgesaagde terme wat al honderd keer op die internet oorgebruik is nie. Enige RBAC en sertifikate.
Ek sal praat oor wat my en my kollegas seermaak van sekuriteit in 'n Kubernetes-kluster. Ons sien hierdie probleme by verskaffers wat Kubernetes-klusters verskaf en by kliënte wat na ons toe kom. En selfs vir kliënte wat na ons toe kom van ander raadgewende administrasiemaatskappye. Dit wil sê, die omvang van die tragedie is in werklikheid baie groot.
Letterlik drie punte waaroor ek vandag sal praat:
- Gebruikersregte vs podregte. Gebruikersregte en podregte is nie dieselfde ding nie.
- Insameling van inligting oor die groepering. Ek sal wys dat jy al die inligting wat jy nodig het van 'n groepering kan versamel sonder om spesiale regte in hierdie groepie te hê.
- DoS-aanval op die cluster. As ons versuim om inligting in te samel, sal ons in elk geval die cluster kan plaas. Ek sal praat oor DoS-aanvalle op groepbeheerelemente.
Nog 'n algemene ding wat ek sal noem, is waarop ek dit alles getoets het, waarop ek met sekerheid kan sê dat dit alles werk.
As basis neem ons die installering van 'n Kubernetes-kluster met behulp van Kubespray. As iemand nie weet nie, is dit eintlik 'n stel rolle vir Ansible. Ons gebruik dit heeltyd by die werk. Die goeie ding is dat jy enige plek kan rol – en jy kan op die stukke yster rol, en iewers in die wolk. Een installasiemetode is in beginsel geskik vir alles.
In hierdie groep sal ek Kubernetes v1.14.5 hê. Die hele Cube-kluster, wat ons sal oorweeg, is in naamruimtes verdeel, elke naamruimte behoort aan 'n aparte span, lede van hierdie span het toegang tot elke naamruimte. Hulle kan nie na verskillende naamruimtes gaan nie, net na hul eie. Maar daar is 'n sekere admin-rekening wat regte op die hele groepering het.
Ek het belowe dat die eerste ding wat ons sal hê, is om admin regte vir die groep te verkry. Ons benodig 'n spesiaal voorbereide peul wat die Kubernetes-kluster sal breek. Al wat ons hoef te doen is om dit op die Kubernetes-kluster toe te pas.
kubectl apply -f pod.yamlHierdie peul sal na een van die meesters van die Kubernetes-kluster kom. En die cluster sal gelukkig daarna 'n lêer genaamd admin.conf terugstuur. In Kuba stoor hierdie lêer alle administrateursertifikate, en terselfdertyd word die groep-API opgestel. Dit is hoe maklik dit is om admin-toegang te kry, dink ek, tot 98% van Kubernetes-klusters.
Weereens, hierdie peul is gemaak deur een ontwikkelaar in jou groepering, wat toegang het om hul voorstelle in een klein naamruimte te ontplooi, hy is almal vasgeklem deur RBAC. Hy het geen regte gehad nie. Maar nietemin het die sertifikaat teruggekeer.
En nou oor 'n spesiaal voorbereide vuurherd. Ons begin op enige beeld. Kom ons neem debian:jessie as 'n voorbeeld.
Ons het so iets:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Wat is verdraagsaamheid? Meesters in 'n Kubernetes-kluster word gewoonlik gemerk met 'n ding wat taint genoem word. En die kern van hierdie "infeksie" is dat dit sê dat peule nie aan meesterknope toegewys kan word nie. Maar niemand doen die moeite om in enige peul aan te dui dat dit die "infeksie" verdraagsaam is nie. Die Tolerasie afdeling sê net dat as NoSchedule op een of ander nodus geïnstalleer is, dan is ons peul verdraagsaam vir so 'n infeksie - en daar is geen probleme nie.
Verder sê ons dat ons peul nie net verdraagsaam is nie, maar ook doelbewus die meester wil slaan. Want die meesters het die lekkerste ding wat ons nodig het - al die sertifikate. Daarom sê ons nodeSelector - en ons het 'n standaard etiket op die meesters, wat jou toelaat om uit al die nodusse van die cluster presies daardie nodusse wat meesters is te kies.
Met hierdie twee afdelings sal dit beslis na die meester kom. En hy sal toegelaat word om daar te woon.
Maar om net na die meester te kom is nie vir ons genoeg nie. Dit sal ons niks gee nie. So volgende het ons hierdie twee dinge:
hostNetwork: true
hostPID: true Ons spesifiseer dat ons pod wat ons bedryf in die kernnaamruimte, die netwerknaamruimte en die PID-naamruimte sal woon. Sodra 'n peul op die meester loop, sal dit al die regte, lewendige koppelvlakke van daardie nodus kan sien, na alle verkeer kan luister en die PID's van alle prosesse kan sien.
Dan is dit aan die klein dingetjies. Neem ens en lees wat jy wil.
Die interessantste ding is hierdie Kubernetes-funksie, wat by verstek daar is.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host En die essensie daarvan is dat ons in die pod wat ons bekendstel, selfs sonder regte op hierdie cluster, kan sê dat ons 'n volume van die hostPath-tipe wil skep. Neem dus die pad vanaf die gasheer waarop ons sal begin - en neem dit as volume. En dan noem ons dit die naam: gasheer. Ons monteer al hierdie hostPath in die peul. In hierdie voorbeeld, na die /host-gids.
Weereens sal ek herhaal. Ons het die peul aangesê om na die meester te kom, hostNetwork en hostPID daar te kry - en die hele wortel van die meester in hierdie peul te monteer.
Jy verstaan dat ons in debian bash loop, en hierdie bash werk vir ons as root. Dit wil sê, ons het pas wortel geskiet op die meester, terwyl ons geen regte in die Kubernetes-kluster gehad het nie.
Dan is die hele taak om in die gids / host / etc / kubernetes / pki in te gaan, as ek my nie misgis nie, haal al die cluster se meestersertifikate daar op en word dienooreenkomstig die cluster admin.
As dit op hierdie manier beskou word, is dit van die gevaarlikste regte in peule, ongeag watter regte die gebruiker het:
As ek regte het om 'n pod in een of ander groepnaamruimte te laat loop, dan het hierdie pod by verstek hierdie regte. Ek kan bevoorregte peule bestuur, wat oor die algemeen alle regte is, en feitlik 'n nodus wortel.
My gunsteling is Root gebruiker. En Kubernetes het hierdie Run As Non-Root opsie. Dit is 'n tipe beskerming teen 'n hacker. Weet jy wat die "Moldowiese virus" is? As jy skielik 'n hacker is en na my Kubernetes-kluster toe gekom het, dan vra ons, arme administrateurs: “Dui asseblief in jou pods aan waarmee jy my cluster sal hack, hardloop as nie-wortel. Andersins sal dit blyk dat jy die proses in jou peul onder die wortel begin, en dit sal vir jou baie maklik wees om my te hack. Beskerm jouself asseblief.”
Gasheerpadvolume - na my mening die vinnigste manier om die gewenste resultaat uit die Kubernetes-groepering te kry.
Maar wat om met dit alles te doen?
Gedagtes wat by enige normale administrateur wat Kubernetes teëkom, moet opkom: “Ja, ek het jou gesê, Kubernetes werk nie. Dit het gate in. En die hele Cube is snert.” Trouens, daar is iets soos dokumentasie, en as jy daar kyk, dan is daar 'n afdeling .
Dit is so 'n yaml-voorwerp - ons kan dit in die Kubernetes-groepering skep - wat die sekuriteitsaspekte in die beskrywing van die peule beheer. Dit wil sê, dit beheer die regte om enige gasheernetwerk, gasheerPID, sekere volumetipes wat in die peule is by opstart te gebruik. Met die hulp van Pod Security Policy kan dit alles beskryf word.
Die interessantste ding van die Pod-sekuriteitsbeleid is dat alle PSP-installeerders in die Kubernetes-kluster nie net nie op enige manier beskryf word nie, hulle is eenvoudig by verstek afgeskakel. Pod-sekuriteitsbeleid word geaktiveer met die toegang-inprop.
Goed, kom ons ontplooi Pod-sekuriteitsbeleid na die groepering, kom ons sê dat ons 'n paar dienspeule in die naamruimte het, waartoe slegs admins toegang het. Kom ons sê, in al die res het peule beperkte regte. Omdat ontwikkelaars waarskynlik nie bevoorregte peule op jou groep hoef te laat loop nie.
En dit lyk of ons goed gaan. En ons Kubernetes-kluster kan nie binne twee minute gekap word nie.
Daar is 'n probleem. Waarskynlik, as u 'n Kubernetes-groepering het, is monitering in u groepering geïnstalleer. Ek onderneem selfs om te voorspel dat as jou groep monitering het, dit Prometheus genoem word.
Wat ek jou nou gaan vertel, sal geldig wees vir beide die Prometheus-operateur en vir Prometheus wat in sy suiwer vorm afgelewer word. Die vraag is, as ek nie so vinnig 'n admin by die cluster kan kry nie, beteken dit dat ek meer moet soek. En ek kan soek met jou monitering.
Waarskynlik lees almal dieselfde artikels oor Habré, en monitering is in die moniteringsnaamruimte geleë. Roerkaart word vir almal ongeveer dieselfde genoem. My raaiskoot is dat as jy roer installeer stal/prometheus jy met min of meer dieselfde name behoort te eindig. En selfs heel waarskynlik sal ek nie die DNS-naam in jou groep hoef te raai nie. Want dit is standaard.
Vervolgens het ons 'n sekere dev ns, waarin jy 'n sekere peul kan laat loop. En dan vanaf hierdie peul is dit baie maklik om so te doen:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics is een van die prometheus-uitvoerders wat statistieke van die Kubernetes API self versamel. Daar is baie data daar, wat loop in jou cluster, wat dit is, watter probleme jy daarmee het.
As 'n eenvoudige voorbeeld:
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
Deur 'n eenvoudige krulversoek van 'n onbevoorregte peul te maak, kan jy inligting soos hierdie kry. As jy nie weet watter weergawe van Kubernetes jy gebruik nie, sal dit jou maklik vertel.
En die interessantste is dat jy, benewens die feit dat jy toegang tot kube-staat-metrieke het, net sowel direk toegang tot Prometheus self kan verkry. Jy kan metrieke van daar af insamel. Jy kan selfs metrieke van daar af bou. Selfs teoreties kan jy so 'n navraag uit 'n cluster in Prometheus bou, wat dit eenvoudig sal afskakel. En jou monitering sal oor die algemeen ophou werk vanaf die groepering.
En hier ontstaan die vraag reeds of enige eksterne monitering jou monitering monitor. Ek het sopas die geleentheid gekry om in 'n Kubernetes-kluster te werk sonder enige gevolge vir myself. Jy sal nie eers weet dat ek daar werk nie, aangesien monitering nie meer daar is nie.
Net soos met die PSP, voel dit of die probleem is dat al hierdie fancy tegnologieë – Kubernetes, Prometheus – hulle net nie werk nie en vol gate is. Nie regtig nie.
Daar is so iets - .
As jy 'n normale administrateur is, weet jy heel waarskynlik van Network Policy dat dit 'n ander yaml is, waarvan daar reeds dofiga in die cluster is. En netwerkbeleide is beslis nie nodig nie. En selfs as jy lees wat Netwerkbeleid is, wat is 'n Kubernetes yaml firewall, dit laat jou toe om toegangsregte tussen naamruimtes, tussen peule te beperk, dan het jy beslis besluit dat die yaml firewall in Kubernetes gebaseer is op die volgende abstraksies ... Nee -nee. Dis beslis nie nodig nie.
Selfs as jou sekuriteitspesialiste nie meegedeel is dat jy met die hulp van jou Kubernetes 'n baie maklike en eenvoudige firewall kan bou, en baie korrelig. As hulle dit nog nie weet nie en jou nie trek nie: “Wel, gee dit, gee dit ...” Dan het jy in elk geval Network Policy nodig om toegang te blokkeer tot sommige diensplekke wat jy uit jou cluster kan trek sonder enige magtiging.
Soos in die voorbeeld wat ek gegee het, kan jy kube-staatstatistieke uit enige naamruimte in die Kubernetes-groepering trek sonder om enige regte te hê om dit te doen. Netwerkbeleide het toegang van alle ander naamruimtes tot die moniteringsnaamruimte gesluit en as't ware alles: geen toegang, geen probleme nie. In al die kaarte wat bestaan, beide die standaard prometheus en die prometheus wat in die operateur is, is daar bloot 'n opsie in die waardes van die roer om bloot netwerkbeleide vir hulle te aktiveer. Jy hoef dit net aan te skakel en hulle sal werk.
Hier is regtig een probleem. Omdat jy 'n normale bebaarde administrateur is, het jy heel waarskynlik besluit dat netwerkbeleide nie nodig is nie. En nadat jy allerhande artikels oor hulpbronne soos Habr gelees het, het jy besluit dat flennie, veral met die gasheerpoortmodus, die beste ding is wat jy kan kies.
Wat om te doen?
Jy kan probeer om die netwerkoplossing wat jy in jou Kubernetes-kluster het, te herontplooi, probeer om dit te vervang met iets meer funksioneel. Op dieselfde Calico, byvoorbeeld. Maar dadelik wil ek sê dat die taak om die netwerkoplossing in die werkende Kubernetes-kluster te verander, redelik nie-triviaal is. Ek het dit twee keer opgelos (albei kere egter teoreties), maar ons het selfs gewys hoe om dit te doen by Slurms. Vir ons studente het ons gewys hoe om die netwerkoplossing in 'n Kubernetes-kluster te verander. In beginsel kan jy probeer om seker te maak dat daar geen stilstand op die produksiekluster is nie. Maar jy sal waarskynlik nie slaag nie.
En die probleem word eintlik baie eenvoudig opgelos. Daar is sertifikate in die cluster, en jy weet dat jou sertifikate oor 'n jaar sleg gaan. Wel, en gewoonlik 'n normale oplossing met sertifikate in die cluster - hoekom gaan ons 'n stoombad vat, ons sal 'n nuwe cluster langsaan oprig, dit laat vrot in die ou een, en alles herontplooi. Weliswaar, wanneer dit vrot, sal alles vir 'n dag lê, maar dan 'n nuwe tros.
Wanneer jy 'n nuwe cluster oprig, plaas terselfdertyd Calico in plaas van flennie.
Wat om te doen as jy sertifikate het wat vir honderd jaar uitgereik is en jy gaan nie die groep herontplooi nie? Daar is so iets Kube-RBAC-Proxy. Dit is 'n baie oulike ontwikkeling, dit laat jou toe om homself as 'n syspanhouer by enige peul in 'n Kubernetes-groep in te sluit. En dit voeg eintlik magtiging deur die RBAC van Kubernetes self by hierdie pod.
Daar is een probleem. Voorheen is hierdie Kube-RBAC-Proxy-oplossing in die operateur se prometheus ingebou. Maar toe was hy weg. Nou maak moderne weergawes staat op die feit dat jy netwerkbeleide het en dit daarmee sluit. En dus moet jy die grafiek 'n bietjie herskryf. Trouens, as jy gaan na , is daar voorbeelde van hoe om dit as syspan te gebruik, en die kaarte sal minimaal herskryf moet word.
Daar is nog een klein probleempie. Nie net Prometheus gee sy statistieke aan enigiemand weg nie. In ons geval kan alle komponente van die Kubernetes-groepering ook hul statistieke gee.
Maar soos ek gesê het, as jy nie toegang tot die cluster kan kry en inligting kan versamel nie, dan kan jy ten minste skade aanrig.
Ek sal dus vinnig vir jou twee maniere wys waarop 'n Kubernetes-kluster siek kan word.
Jy sal lag as ek vir jou sê, hierdie is twee werklike gevalle.
Metode een. Hulpbronuitputting.
Ons stel nog 'n spesiale peul bekend. Dit sal hierdie afdeling hê.
resources:
requests:
cpu: 4
memory: 4Gi Soos u weet, is versoeke die hoeveelheid SVE en geheue wat op die gasheer gereserveer is vir spesifieke versoekpeule. As ons 'n vierkerngasheer in die Kubernetes-groepering het, en vier SVE-peule kom daar aan met versoeke, dan kan nie meer peule met versoeke na hierdie gasheer kom nie.
As ek so 'n pod laat loop, gee ek die opdrag:
$ kubectl scale special-pod --replicas=...Dan sal niemand anders na die Kubernetes-kluster kan ontplooi nie. Omdat alle nodusse nie meer versoeke het nie. En so sal ek jou Kubernetes-kluster stop. As ek dit in die aand doen, kan die ontplooiings nogal lank gestaak word.
As ons weer na die Kubernetes-dokumentasie kyk, sal ons so iets genaamd Limit Range sien. Dit stel die hulpbronne vir die groepvoorwerpe. Jy kan 'n Limit Range-objek in yaml skryf, dit op sekere naamruimtes toepas - en verder in hierdie naamruimte kan jy sê dat jy hulpbronne het vir verstek-, maksimum- en minimum-peule.
Met behulp van so iets kan ons gebruikers in spesifieke spanproduknaamruimtes beperk van die vermoë om allerhande nare dinge op hul peule aan te dui. Maar ongelukkig, selfs as jy vir die gebruiker sê dat jy nie peule met versoeke vir meer as een SVE kan laat loop nie, is daar so 'n wonderlike skaalopdrag, wel, of deur die dashboard kan hulle skaal doen.
En dit is waar nommer twee inkom. Loop 11 111 111 111 111 peule. Dit is elf biljoen. Dit is nie omdat ek met so 'n nommer vorendag gekom het nie, maar omdat ek dit self gesien het.
Regte storie. Laataand was ek op die punt om die kantoor te verlaat. Ek kyk, 'n groep ontwikkelaars sit in die hoek en doen verwoed iets met skootrekenaars. Ek gaan na die ouens toe en vra: “Wat het met julle gebeur?”
’n Bietjie vroeër, nege-uur die aand, het een van die ontwikkelaars huis toe gegaan. En ek het besluit: "Nou sal ek my aansoek na een skaal." Ek het een gedruk, en die internet het 'n bietjie dof geword. Hy het weer die een gedruk, hy het die een gedruk, Enter gedruk. Hy het alles gesteek wat hy kon. Toe het die internet lewe gekry - en alles het begin skaal tot op hierdie datum.
Dit is waar, hierdie storie het nie op Kubernetes plaasgevind nie, op daardie stadium was dit Nomad. Dit het geëindig met die feit dat Nomad na 'n uur van ons pogings om Nomad van hardnekkige pogings om te skaal te keer, geantwoord het dat hy nie sal ophou skaal nie en niks anders sal doen nie. "Ek is moeg, ek gaan." En omgedraai.
Ek het natuurlik probeer om dieselfde op Kubernetes te doen. Elf miljard peule Kubernetes het nie behaag nie, hy het gesê: "Ek kan nie. Oorskry interne pette. Maar 1 000 000 000 peule kan.
In reaksie op een miljard het die Kubus nie in homself onttrek nie. Hy het regtig begin skaal. Hoe verder die proses gegaan het, hoe meer tyd het dit geneem om nuwe peule te skep. Maar steeds het die proses aangegaan. Die enigste probleem is dat as ek pods onbepaald in my naamruimte kan laat loop, dan selfs sonder versoeke en limiete, kan ek so 'n aantal peule met sommige take laat loop dat met behulp van hierdie take die nodes uit die geheue sal begin optel, op die SVE. Wanneer ek soveel peule laat loop, moet die inligting van hulle in die stoor kom, dit wil sê, ens. En wanneer te veel inligting inkom, begin die berging te stadig teruggee – en Kubernetes begin stomp raak.
En nog 'n probleem ... Soos u weet, is Kubernetes-kontroles nie 'n soort sentrale ding nie, maar verskeie komponente. Daar is veral 'n beheerderbestuurder, skeduleerder en so meer. Al hierdie ouens sal terselfdertyd onnodige dom werk begin doen, wat mettertyd al hoe meer tyd sal begin neem. Die beheerderbestuurder sal nuwe peule skep. Skeduleerder sal probeer om 'n nuwe nodus vir hulle te vind. Nuwe nodusse in jou cluster sal heel waarskynlik binnekort opraak. Die Kubernetes-kluster sal stadiger en stadiger begin loop.
Maar ek het besluit om nog verder te gaan. Soos u weet, het Kubernetes iets wat 'n diens genoem word. Wel, by verstek werk die diens waarskynlik in u groepe met behulp van IP-tabelle.
As jy byvoorbeeld een miljard peule bestuur en dan 'n skrif gebruik om Kubernetis te dwing om nuwe dienste te skep:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Op alle nodusse van die groepering sal meer en meer nuwe iptables-reëls ongeveer gelyktydig gegenereer word. Boonop sal een miljard iptables-reëls vir elke diens gegenereer word.
Ek het hierdie hele ding nagegaan op 'n paar duisend, tot 'n dosyn. En die probleem is dat dit reeds by hierdie drumpel nogal problematies is om ssh na die nodus te maak. Omdat pakkies, wat deur soveel kettings gaan, nie baie goed begin voel nie.
En dit word ook alles opgelos met behulp van Kubernetes. Daar is so 'n voorwerp Hulpbronkwota. Stel die aantal beskikbare hulpbronne en voorwerpe vir die naamruimte in die groepering. Ons kan 'n yaml-voorwerp in elke Kubernetes-klusternaamruimte skep. Met die hulp van hierdie objek kan ons sê dat ons 'n sekere aantal versoeke het, limiete wat vir hierdie naamruimte toegeken is, en verder kan ons sê dat dit moontlik is om 10 dienste en 10 peule in hierdie naamruimte te skep. En 'n enkele ontwikkelaar kan homself selfs in die aande verpletter. Kubernetes sal vir hom sê: "Jy kan nie jou peule tot so 'n hoeveelheid skaal nie, want dit oorskry die hulpbronkwota." Dit is dit, probleem opgelos. .
Een probleem ontstaan in verband hiermee. Jy voel hoe moeilik dit word om 'n naamruimte in Kubernetes te skep. Om dit te skep, moet ons 'n klomp dinge in ag neem.
Hulpbronkwota + Limietreeks + RBAC
• Skep 'n naamruimte
• Skep binne limietreeks
• Skep binnehulpbronkwota
• Skep 'n diensrekening vir CI
• Skep rolbinding vir CI en gebruikers
• Begin opsioneel die nodige dienspeule
Daarom, deur hierdie geleentheid te gebruik, wil ek graag my verwikkelinge deel. Daar is so iets wat die SDK-operateur genoem word. Dit is die manier in die Kubernetes-kluster om stellings daarvoor te skryf. Jy kan stellings met Ansible skryf.
Aanvanklik het ons in Ansible geskryf, en toe het ek gekyk na wat die SDK-operateur was en die Ansible-rol in 'n operateur herskryf. Hierdie stelling laat jou toe om 'n voorwerp in die Kubernetes-kluster te skep wat 'n opdrag genoem word. Binne die opdrag laat dit jou toe om die omgewing vir hierdie opdrag in yaml te beskryf. En binne die spanomgewing laat dit ons toe om te beskryf dat ons soveel hulpbronne toewys.
Petite .
En ten slotte. Wat om met dit alles te doen?
Eerstens. Pod-sekuriteitsbeleid is goed. En ten spyte van die feit dat nie een van die Kubernetes-installeerders dit tot vandag toe gebruik nie, moet jy dit steeds in jou groepe gebruik.
Netwerkbeleid is nie 'n ander onnodige kenmerk nie. Dit is wat regtig nodig is in die cluster.
LimitRange / ResourceQuota - dit is tyd om te gebruik. Ons het dit lank gelede begin gebruik, en ek was lankal seker dat almal dit sonder uitsondering gebruik. Dit het geblyk dat dit skaars is.
Benewens wat ek tydens die verslag genoem het, is daar ongedokumenteerde kenmerke wat jou toelaat om die groep aan te val. Onlangs vrygestel .
Sommige dinge is so hartseer en seer. Byvoorbeeld, onder sekere omstandighede, kan blokkies in 'n Kubernetes-groepering die inhoud van die warlocks-gids gee, en aan 'n ongemagtigde gebruiker.
daar is instruksies oor hoe om alles wat ek gesê het weer te gee. Daar is lêers met produksievoorbeelde, hoe ResourceQuota, Pod Security Policy lyk. En dit alles kan aangeraak word.
Dankie aan almal.
Bron: will.com