Pavel Selivanov, arquitecte de solucions de Southbridge i professor de Slurm, va fer una xerrada a DevOpsConf 2019. Aquesta xerrada forma part d'un dels temes del curs Kubernetes avançat Slurm Mega.
tindrà lloc a Moscou del 18 al 20 de novembre.
- Moscou, 22-24 de novembre.
sempre disponible.
Sota el tall - transcripció de l'informe.
Bona tarda, companys i simpatitzants. Avui parlaré de seguretat.
Veig que avui hi ha molta gent de seguretat a la sala. Us demano disculpes per avançat si faig servir termes del món de la seguretat que no siguin com ho feu habitualment.
Va passar que fa uns sis mesos, un clúster públic de Kubernetes va caure a les meves mans. Públic: significa que hi ha enèsimo nombre d'espais de noms, en aquests espais de noms hi ha usuaris aïllats al seu espai de noms. Tots aquests usuaris pertanyen a diferents empreses. Bé, es va suposar que aquest clúster s'havia d'utilitzar com a CDN. És a dir, et donen un clúster, hi donen un usuari, hi vas al teu espai de noms, despleguen els teus fronts.
La meva empresa anterior va intentar vendre aquest servei. I em van demanar que fes el clúster sobre el tema, si aquesta solució és adequada o no.
Vaig arribar a aquest grup. Em van donar drets limitats, espai de noms limitat. Allà, els nois van entendre què és la seguretat. Van llegir què és el control d'accés basat en rols (RBAC) a Kubernetes i el van torçar perquè no pogués executar pods per separat dels desplegaments. No recordo el problema que estava intentant resoldre executant un pod sense desplegament, però realment volia executar només un pod. Vaig decidir per sort per veure quins drets tinc al clúster, què puc fer, què no, què han fotut allà. Al mateix temps, us explicaré què han configurat incorrectament a RBAC.
Va passar que en dos minuts vaig aconseguir un administrador al seu clúster, vaig mirar tots els espais de noms veïns, vaig veure els fronts de producció de les empreses que ja havien comprat el servei i s'hi havien desplegat. Amb prou feines em vaig aturar per no acostar-me a algú del davant i posar unes males a la pàgina principal.
Us explicaré amb exemples com ho vaig fer i com defensar-ho.
Però primer, deixeu-me presentar-me. Em dic Pavel Selivanov. Sóc arquitecte de Southbridge. Entenc Kubernetes, DevOps i tot tipus de coses de luxe. Els enginyers de Southbridge i jo ho estem construint tot i estic consultor.
A més de les nostres activitats principals, recentment hem posat en marxa projectes anomenats Slurms. Estem intentant portar una mica la nostra capacitat de treballar amb Kubernetes a les masses, per ensenyar a altres persones també a treballar amb K8.
De què parlaré avui. El tema de l'informe és obvi: sobre la seguretat del clúster de Kubernetes. Però vull dir de seguida que aquest tema és molt ampli i, per tant, vull especificar de seguida de què definitivament no parlaré. No parlaré de termes trillats que ja s'han utilitzat en excés cent vegades a Internet. Qualsevol RBAC i certificats.
Parlaré del que em fa mal a mi i als meus companys de seguretat en un clúster de Kubernetes. Veiem aquests problemes tant amb els proveïdors que proporcionen clústers de Kubernetes com amb els clients que vénen a nosaltres. I fins i tot per als clients que ens vénen d'altres empreses de consultoria administrativa. És a dir, l'envergadura de la tragèdia és de fet molt gran.
Literalment, tres punts dels quals parlaré avui:
- Drets d'usuari vs drets de pod. Els drets d'usuari i els drets de pod no són el mateix.
- Recollida d'informació sobre el clúster. Us mostraré que podeu recollir tota la informació que necessiteu d'un clúster sense tenir drets especials en aquest clúster.
- Atac DoS al clúster. Si no aconseguim recopilar informació, podrem posar el clúster en qualsevol cas. Parlaré dels atacs DoS als elements de control del clúster.
Una altra cosa general que esmentaré és en què ho vaig provar tot, sobre el qual puc dir amb seguretat que tot funciona.
Com a base, prenem la instal·lació d'un clúster de Kubernetes mitjançant Kubespray. Si algú no ho sap, aquest és en realitat un conjunt de rols per a Ansible. Ho fem servir tot el temps a la feina. El millor és que pots rodar a qualsevol lloc, i pots rodar sobre les peces de ferro i en algun lloc del núvol. Un mètode d'instal·lació és adequat en principi per a tot.
En aquest clúster, tindré Kubernetes v1.14.5. Tot el clúster Cube, que tindrem en compte, està dividit en espais de noms, cada espai de noms pertany a un equip independent, els membres d'aquest equip tenen accés a cada espai de noms. No poden anar a diferents espais de noms, només al seu. Però hi ha un determinat compte d'administrador que té drets sobre tot el clúster.
Vaig prometre que el primer que tindrem és obtenir drets d'administrador del clúster. Necessitem un pod especialment preparat que trencarà el clúster de Kubernetes. Tot el que hem de fer és aplicar-lo al clúster de Kubernetes.
kubectl apply -f pod.yamlAquest pod arribarà a un dels mestres del clúster Kubernetes. I el clúster tornarà feliçment un fitxer anomenat admin.conf després d'això. A Cuba, aquest fitxer emmagatzema tots els certificats d'administració i, al mateix temps, es configura l'API del clúster. Així de fàcil és obtenir accés d'administrador, crec, al 98% dels clústers de Kubernetes.
Un cop més, aquest pod va ser creat per un desenvolupador del vostre clúster, que té accés per desplegar les seves propostes en un espai de noms petit, tot està subjecte per RBAC. No tenia cap dret. Però tanmateix el certificat va tornar.
I ara sobre una llar especialment preparada. Llancem a qualsevol imatge. Prenguem debian:jessie com a exemple.
Tenim una cosa així:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Què és la tolerància? Els mestres d'un clúster de Kubernetes solen estar etiquetats amb una cosa anomenada taint. I l'essència d'aquesta "infecció" és que diu que les beines no es poden assignar als nodes mestres. Però ningú es molesta a indicar en cap beina que és tolerant a la "infecció". La secció Toleració només diu que si NoSchedule està instal·lat en algun node, el nostre pod és tolerant a aquesta infecció i no hi ha problemes.
A més, diem que la nostra beina no només és tolerant, sinó que també vol colpejar el mestre a propòsit. Perquè els mestres tenen el més deliciós que necessitem: tots els certificats. Per tant, diem nodeSelector - i tenim una etiqueta estàndard als mestres, que us permet seleccionar entre tots els nodes del clúster exactament aquells nodes que són mestres.
Amb aquestes dues seccions, sens dubte arribarà al mestre. I se li permetrà viure-hi.
Però amb només venir al mestre no n'hi ha prou. No ens donarà res. Així que a continuació tenim aquestes dues coses:
hostNetwork: true
hostPID: true Especifiquem que el nostre pod que estem executant viurà a l'espai de noms del nucli, l'espai de noms de xarxa i l'espai de noms PID. Un cop s'executa un pod al mestre, podrà veure totes les interfícies reals i en directe d'aquest node, escoltar tot el trànsit i veure els PID de tots els processos.
Després depèn de les petites coses. Agafa etcd i llegeix el que vulguis.
El més interessant és aquesta característica de Kubernetes, que hi és per defecte.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host I la seva essència és que podem, en el pod que llançam, fins i tot sense drets sobre aquest clúster, dir que volem crear un volum del tipus hostPath. Així que agafeu el camí de l'amfitrió en què començarem i preneu-lo com a volum. I llavors li diem nom: host. Muntem tot aquest hostPath dins del pod. En aquest exemple, al directori /host.
Un cop més repetiré. Vam dir al pod que vingués al mestre, que hi anés hostNetwork i hostPID, i muntés tota l'arrel del mestre dins d'aquest pod.
Enteneu que a Debian tenim bash en execució, i aquest bash funciona per a nosaltres com a root. És a dir, acabem d'arrel al mestre, sense tenir cap dret al clúster de Kubernetes.
Aleshores, tota la tasca és anar al directori / host / etc / kubernetes / pki, si no m'equivoco, recollir tots els certificats mestres del clúster allà i, en conseqüència, convertir-se en l'administrador del clúster.
Quan es veuen d'aquesta manera, aquests són alguns dels drets més perillosos dels pods, independentment dels drets que tingui l'usuari:
Si tinc drets per executar un pod en algun espai de noms de clúster, aquest pod té aquests drets per defecte. Puc executar pods amb privilegis, que generalment són tots els drets, pràcticament arrelant un node.
El meu preferit és l'usuari root. I Kubernetes té aquesta opció Executar com a no root. Aquest és un tipus de protecció contra un pirata informàtic. Saps què és el "virus de Moldàvia"? Si de sobte ets un pirata informàtic i has arribat al meu clúster de Kubernetes, aleshores nosaltres, els administradors pobres, et preguntem: "Indiqueu als vostres pods amb què piratejareu el meu clúster, executar-lo com a no root. En cas contrari, resultarà que inicieu el procés al vostre pod sota l'arrel i us serà molt fàcil piratejar-me. Protegiu-vos, si us plau".
Volum del camí de l'amfitrió: al meu entendre, la manera més ràpida d'obtenir el resultat desitjat del clúster de Kubernetes.
Però què fer amb tot això?
Pensaments que haurien de venir a qualsevol administrador normal que es trobi amb Kubernetes: "Sí, us ho vaig dir, Kubernetes no funciona. Té forats. I tot el Cube és una merda". De fet, hi ha documentació, i si hi mires, hi ha una secció .
Aquest és un objecte yaml -el podem crear al clúster Kubernetes- que controla els aspectes de seguretat en la descripció dels pods. És a dir, de fet, controla els drets per utilitzar qualsevol hostNetwork, hostPID, determinats tipus de volum que es troben als pods a l'inici. Amb l'ajuda de la Política de seguretat del pod, es pot descriure tot això.
El més interessant de la política de seguretat del pod és que al clúster de Kubernetes, tots els instal·ladors de PSP no només no es descriuen de cap manera, sinó que simplement estan desactivats per defecte. La política de seguretat del pod s'activa mitjançant el connector d'admissió.
D'acord, implementem la política de seguretat del pod al clúster, diguem que tenim alguns pods de servei a l'espai de noms, als quals només tenen accés els administradors. Diguem que, a la resta, les beines tenen drets limitats. Perquè el més probable és que els desenvolupadors no necessiten executar pods amb privilegis al vostre clúster.
I sembla que estem bé. I el nostre clúster de Kubernetes no es pot piratejar en dos minuts.
Hi ha un problema. Molt probablement, si teniu un clúster de Kubernetes, la supervisió s'instal·la al vostre clúster. Fins i tot em comprometo a predir que si el vostre clúster té monitorització, llavors es diu Prometeu.
El que us explicaré ara serà vàlid tant per a l'operador Prometheus com per a Prometheus lliurat en la seva forma pura. La pregunta és, si no puc aconseguir un administrador al clúster tan ràpidament, això vol dir que necessito cercar més. I puc cercar amb el vostre monitoratge.
Probablement, tothom llegeix els mateixos articles sobre Habré, i el monitoratge es troba al monitoratge de l'espai de noms. El gràfic Helm s'anomena aproximadament el mateix per a tothom. Suposo que si instal·leu stable/prometheus, hauríeu d'acabar amb aproximadament els mateixos noms. I fins i tot el més probable és que no hagi d'endevinar el nom DNS del vostre clúster. Perquè és estàndard.
A continuació, tenim uns determinats desenvolupaments, en els quals podeu executar un pod determinat. I després des d'aquest pod és molt fàcil fer així:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics és un dels exportadors de prometheus que recull mètriques de la mateixa API de Kubernetes. Hi ha moltes dades allà, què s'està executant al vostre clúster, què és, quins problemes teniu amb ell.
Com a exemple senzill:
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
Si feu una simple sol·licitud de curl des d'un pod sense privilegis, podeu obtenir informació com aquesta. Si no sabeu quina versió de Kubernetes esteu executant, us ho dirà fàcilment.
I el més interessant és que, a més del fet d'accedir a kube-state-metrics, també podeu accedir directament a Prometheus. Podeu recollir mètriques a partir d'aquí. Fins i tot podeu crear mètriques a partir d'aquí. Fins i tot teòricament, podeu crear aquesta consulta des d'un clúster a Prometheus, que simplement la desactivarà. I la vostra supervisió generalment deixarà de funcionar des del clúster.
I aquí ja sorgeix la pregunta de si algun monitoratge extern controla el vostre monitoratge. Acabo de tenir l'oportunitat d'operar en un clúster de Kubernetes sense conseqüències per a mi. Ni tan sols sabreu que hi estic treballant, ja que el seguiment ja no hi és.
Igual que amb la PSP, sembla que el problema és que totes aquestes tecnologies de luxe (Kubernetes, Prometheus) simplement no funcionen i estan plenes de forats. No realment.
Hi ha tal cosa - .
Si sou un administrador normal, és molt probable que sàpigues de la política de xarxa que aquest és un altre yaml, del qual ja hi ha dofiga al clúster. I les polítiques de xarxa definitivament no són necessàries. I fins i tot si llegiu què és la política de xarxa, què és un tallafocs yaml de Kubernetes, us permet restringir els drets d'accés entre espais de noms, entre pods, aleshores definitivament heu decidit que el tallafocs yaml de Kubernetes es basa en les properes abstraccions... No, no. Definitivament no és necessari.
Fins i tot si no se'ls va dir als vostres especialistes en seguretat amb l'ajuda del vostre Kubernetes, podeu crear un tallafocs molt fàcil i senzill, i molt granular. Si encara no ho saben i no us treuen: "Bé, doneu-li, doneu-li..." Aleshores, en qualsevol cas, necessiteu la Política de xarxa per bloquejar l'accés a alguns llocs de servei que podeu treure del vostre clúster sense cap autorització.
Com a l'exemple que vaig donar, podeu extreure mètriques d'estat de Kube des de qualsevol espai de noms del clúster de Kubernetes sense tenir cap dret per fer-ho. Les polítiques de xarxa han tancat l'accés des de la resta d'espais de noms a l'espai de noms de supervisió i, per dir-ho, tot: sense accés, sense problemes. En tots els gràfics que existeixen, tant el prometheus estàndard com el prometheus que hi ha a l'operador, simplement hi ha una opció en els valors del timó per habilitar-los simplement polítiques de xarxa. Només cal que l'enceneu i funcionaran.
Realment hi ha un problema aquí. Com que és un administrador barbut normal, probablement hagueu decidit que les polítiques de xarxa no són necessàries. I després de llegir tota mena d'articles sobre recursos com Habr, vau decidir que la franel·la, especialment amb el mode de passarel·la d'amfitrió, és el millor que podeu triar.
Què fer?
Podeu provar de tornar a desplegar la solució de xarxa que teniu al clúster de Kubernetes, provar de substituir-la per alguna cosa més funcional. Al mateix Calico, per exemple. Però de seguida vull dir que la tasca de canviar la solució de xarxa al clúster de Kubernetes en funcionament no és gens trivial. Ho vaig resoldre dues vegades (les dues vegades, però, teòricament), però fins i tot vam mostrar com fer-ho a Slurms. Per als nostres estudiants, vam mostrar com canviar la solució de xarxa en un clúster de Kubernetes. En principi, podeu provar d'assegurar-vos que no hi hagi temps d'inactivitat al clúster de producció. Però probablement no ho aconseguiràs.
I el problema es resol de manera molt senzilla. Hi ha certificats al clúster i sabeu que els vostres certificats aniran malament en un any. Bé, i normalment una solució normal amb certificats al clúster: per què anem a fer un bany de vapor, aixecarem un nou clúster al costat, el deixarem podrit a l'antic i tornarem a desplegar-ho tot. És cert que quan es podreix, tot s'estendrà durant un dia, però després un nou cúmul.
Quan aixequeu un grup nou, introduïu al mateix temps Calico en lloc de franel·la.
Què fer si teniu certificats emesos durant cent anys i no voleu tornar a desplegar el clúster? Hi ha tal cosa Kube-RBAC-Proxy. Aquest és un desenvolupament molt interessant, us permet incrustar-vos com a contenidor sidecar a qualsevol pod d'un clúster de Kubernetes. I en realitat afegeix autorització a través del mateix RBAC de Kubernetes a aquest pod.
Hi ha un problema. Anteriorment, aquesta solució Kube-RBAC-Proxy es va incorporar al prometeu de l'operador. Però després se'n va anar. Ara les versions modernes es basen en el fet que teniu polítiques de xarxa i les tanqueu amb elles. I, per tant, heu de reescriure una mica el gràfic. De fet, si hi vas , hi ha exemples de com utilitzar-lo com a sidecars, i els gràfics s'hauran de reescriure mínimament.
Hi ha un petit problema més. No només Prometeu regala les seves mètriques a qualsevol. En el nostre cas, tots els components del clúster Kubernetes també poden donar les seves mètriques.
Però, com he dit, si no podeu accedir al clúster i recopilar informació, almenys podeu fer mal.
Així que us mostraré ràpidament dues maneres en què un clúster de Kubernetes pot emmalaltir.
Riureu quan et digui, aquests són dos casos de la vida real.
Mètode XNUMX. Esgotament dels recursos.
Estrenem un altre pod especial. Tindrà aquesta secció.
resources:
requests:
cpu: 4
memory: 4Gi Com sabeu, les peticions és la quantitat de CPU i memòria que es reserva a l'amfitrió per a pods de sol·licituds específics. Si tenim un amfitrió de quatre nuclis al clúster de Kubernetes i hi arriben quatre pods de CPU amb sol·licituds, no hi podran arribar més pods amb sol·licituds a aquest amfitrió.
Si executo un pod com aquest, emet l'ordre:
$ kubectl scale special-pod --replicas=...Aleshores, ningú més es podrà implementar al clúster de Kubernetes. Perquè tots els nodes es quedaran sense peticions. I així aturaré el vostre clúster de Kubernetes. Si ho faig al vespre, els desplegaments es poden aturar durant força temps.
Si tornem a mirar la documentació de Kubernetes, veurem una cosa anomenada Limit Range. Estableix els recursos per als objectes del clúster. Podeu escriure un objecte Limit Range a yaml, aplicar-lo a determinats espais de noms, i més enllà en aquest espai de noms podeu dir que teniu recursos per a pods predeterminats, màxims i mínims.
Amb l'ajuda d'aquesta cosa, podem restringir els usuaris d'espais de noms de productes d'equip específics de la capacitat d'indicar tot tipus de coses desagradables als seus pods. Però, malauradament, fins i tot si digueu a l'usuari que no podeu executar pods amb sol·licituds per a més d'una CPU, hi ha una ordre d'escala tan meravellosa, bé, o a través del tauler de comandament poden fer escala.
I aquí és on entra el número dos. Córrer 11 111 111 111 111 beines. Són onze mil milions. Això no és perquè m'hagués inventat un nombre així, sinó perquè l'he vist jo mateix.
Història real. A última hora del vespre estava a punt de sortir de l'oficina. Miro, un grup de desenvolupadors està assegut a la cantonada i fent alguna cosa frenèticament amb els ordinadors portàtils. M'apropo als nois i els pregunto: "Què t'ha passat?"
Una mica abans, a les nou del vespre, un dels promotors anava a casa seva. I vaig decidir: "Ara escalaré la meva aplicació a un". Vaig prémer un i Internet es va fer una mica avorrit. Va tornar a prémer la una, va prémer la una, va prémer Enter. Va picar tot el que va poder. Llavors Internet va cobrar vida i tot va començar a escalar fins a aquesta data.
És cert que aquesta història no va tenir lloc a Kubernetes, en aquell moment era Nomad. Va acabar amb el fet que després d'una hora dels nostres intents d'aturar Nomad dels intents tossuts d'escalar, Nomad va respondre que no deixaria d'escalar i que no faria res més. "Estic cansat, me'n vaig". I es va girar.
Naturalment, vaig intentar fer el mateix a Kubernetes. Onze mil milions de beines Kubernetes no va agradar, va dir: "No puc. Supera els taps interns. Però 1 de beines podrien.
En resposta a mil milions, el Cub no es va retirar en si mateix. Realment va començar a escalar. Com més avançava el procés, més temps es trigava a crear nous pods. Però tot i així el procés va continuar. L'únic problema és que si puc executar pods al meu espai de noms indefinidament, fins i tot sense sol·licituds i límits, puc executar un nombre de pods amb algunes tasques que amb l'ajuda d'aquestes tasques els nodes començaran a sumar des de la memòria, a la CPU. Quan executo tantes beines, la informació d'ells ha d'entrar a l'emmagatzematge, és a dir, etcd. I quan arriba massa informació, l'emmagatzematge comença a retornar massa lentament i Kubernetes comença a ser contundent.
I un problema més... Com sabeu, els controls de Kubernetes no són una mena de cosa central, sinó diversos components. Allà, en particular, hi ha un gestor de controladors, un programador, etc. Tots aquests nois començaran a fer treballs estúpids innecessaris al mateix temps, que amb el temps començaran a prendre més i més temps. El gestor del controlador crearà pods nous. El planificador intentarà trobar un nou node per a ells. És probable que els nous nodes del vostre clúster s'esgotin aviat. El clúster de Kubernetes començarà a funcionar cada cop més lent.
Però vaig decidir anar més enllà. Com sabeu, Kubernetes té una cosa anomenada servei. Bé, de manera predeterminada als vostres clústers, el més probable és que el servei funcioni mitjançant taules IP.
Si executeu mil milions de pods, per exemple, i després feu servir un script per forçar Kubernetis a crear nous serveis:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done A tots els nodes del clúster, es generaran més i més regles iptables noves aproximadament simultàniament. A més, es generaran mil milions de regles iptables per a cada servei.
Vaig comprovar tot això en diversos milers, fins a una dotzena. I el problema és que ja en aquest llindar és bastant problemàtic fer ssh al node. Perquè els paquets, passant per tantes cadenes, comencen a sentir-se poc bé.
I això també es resol amb l'ajuda de Kubernetes. Hi ha un objecte d'aquest tipus Quota de recursos. Estableix el nombre de recursos i objectes disponibles per a l'espai de noms del clúster. Podem crear un objecte yaml a cada espai de noms de clúster de Kubernetes. Amb l'ajuda d'aquest objecte, podem dir que tenim un cert nombre de peticions, límits assignats per a aquest espai de noms i, a més, podem dir que és possible crear 10 serveis i 10 pods en aquest espai de noms. I un sol desenvolupador fins i tot pot aixafar-se a la nit. Kubernetes li dirà: "No podeu escalar els vostres pods a aquesta quantitat, perquè supera la quota de recursos". Això és tot, problema resolt. .
En aquest sentit sorgeix un problema. Sentiu el difícil que es fa crear un espai de noms a Kubernetes. Per crear-lo, hem de tenir en compte un munt de coses.
Quota de recursos + Interval límit + RBAC
• Crear un espai de noms
• Crear dins el rang límit
• Crear una quota de recursos interna
• Creeu un compte de servei per a CI
• Crear enllaços de rols per a CI i usuaris
• Opcionalment, llança els pods de servei necessaris
Per tant, aprofitant aquesta oportunitat, m'agradaria compartir els meus desenvolupaments. Hi ha una cosa que s'anomena operador SDK. Aquesta és la manera al clúster de Kubernetes d'escriure declaracions. Podeu escriure enunciats amb Ansible.
Al principi, vam escriure a Ansible, i després vaig mirar què era l'operador SDK i vaig reescriure el rol d'Ansible en un operador. Aquesta declaració us permet crear un objecte al clúster de Kubernetes anomenat ordre. Dins de l'ordre, us permet descriure en yaml l'entorn d'aquesta comanda. I dins de l'entorn d'equip, ens permet descriure que hi dediquem tants recursos.
Poc .
I en conclusió. Què fer amb tot això?
Primer. La política de seguretat del pod és bona. I malgrat que cap dels instal·ladors de Kubernetes els fa servir fins avui, encara els heu d'utilitzar als vostres clústers.
La política de xarxa no és cap altra característica innecessària. Això és el que realment es necessita al clúster.
LimitRange / ResourceQuota: és hora d'utilitzar-lo. El vam començar a utilitzar fa molt de temps, i durant molt de temps vaig estar segur que tothom, sense excepció, l'utilitza. Va resultar que això és rar.
A més del que he esmentat durant l'informe, hi ha funcions no documentades que us permeten atacar el clúster. Publicat recentment .
Algunes coses són tan tristes i doloroses. Per exemple, en determinades condicions, els cubelets d'un clúster de Kubernetes poden donar el contingut del directori warlocks i a un usuari no autoritzat.
hi ha instruccions sobre com reproduir tot el que he dit. Hi ha fitxers amb exemples de producció, com es veuen ResourceQuota i la política de seguretat del pod. I tot això es pot tocar.
Gràcies a tots.
Font: www.habr.com