Pavel Selivanov, architetto di soluzioni per Southbridge e docente di Slyrma, ha presentato una relazione al DevOpsConf 2019. Questa relazione è parte di uno dei temi del corso avanzato su Kubernetes "Slyrma Mega".
si svolge a Mosca dal 18 al 20 novembre.
— Mosca, dal 22 al 24 novembre.
disponibile sempre.
Di seguito — trascrizione della relazione.
Buongiorno, colleghi e simpatizzanti. Oggi parlerò di sicurezza.
Vedo che in sala ci sono molti esperti di sicurezza. Mi scuso in anticipo se utilizzerò termini del mondo della sicurezza in modo non del tutto conforme alle vostre consuetudini.
Circa sei mesi fa, mi è capitato di utilizzare un cluster Kubernetes pubblico. Pubblico significa che ci sono diversi namespaces, in cui ci sono utenti isolati nel proprio namespace. Tutti questi utenti appartengono a diverse aziende. L'idea era di utilizzare questo cluster come CDN. Quindi, ti danno un cluster, ti assegnano un utente e tu accedi al tuo namespace per distribuire le tue applicazioni front-end.
La mia precedente azienda ha cercato di vendere un servizio simile. Mi hanno chiesto di esplorare il cluster per valutare se una soluzione del genere fosse appropriata o meno.
Sono arrivato in questo cluster. Mi hanno dato diritti limitati e un namespace limitato. Lì le persone capivano cosa significasse la sicurezza. Leggevano cosa fosse il controllo degli accessi basato sui ruoli (RBAC) in Kubernetes — e lo hanno impostato in modo che non potessi eseguire i pod separatamente dai deployment. Non ricordo quale compito stessi cercando di risolvere lanciando un pod senza deployment, ma desideravo davvero avviare semplicemente un pod. Ho deciso di dare un'occhiata, per pura fortuna, a quali diritti avessi nel cluster, cosa potessi e cosa non potessi fare, e cosa avessero combinato. Inoltre, racconterò cosa è stato configurato in modo errato nel loro RBAC.
Così è successo che dopo due minuti ho ottenuto l'accesso da amministratore al loro cluster, ho guardato tutti i namespace circostanti e ho visto che c'erano in esecuzione i front-end di produzione di aziende che avevano già acquistato il servizio e si erano deployate. Ho fatto fatica a fermarmi dal non andare da qualcuno e non inserire parolacce nella homepage.
Racconterò con esempi come ho fatto e come bisogna difendersi da questo.
Ma prima di tutto, permettetemi di presentarmi. Mi chiamo Pavel Selivanov e sono l'architetto dell'azienda Southbridge. Ho esperienza in Kubernetes, DevOps e varie tecnologie all'avanguardia. Costruiamo tutto questo con gli ingegneri di Southbridge e io fornisco consulenze.
Oltre alla nostra attività principale, di recente abbiamo lanciato un progetto chiamato Slërmy. Cerchiamo di portare le nostre competenze in Kubernetes al grande pubblico, insegnando ad altre persone come lavorare con K8s.
Di cosa parlerò oggi. Il tema della presentazione è chiaro: la sicurezza del cluster Kubernetes. Ma voglio subito sottolineare che questo argomento è molto ampio e, quindi, devo specificare che non parlerò di alcune cose. Non discuterò termini abusati, che sono già stati ripetuti cento volte su Internet, come RBAC e certificati.
Parlerò di ciò che preoccupa me e i miei colleghi riguardo alla sicurezza nel cluster Kubernetes. Vediamo questi problemi sia presso i fornitori che offrono cluster Kubernetes, sia presso i clienti che si rivolgono a noi. Anche i clienti che arrivano da altre aziende di consulenza e amministrazione. Quindi, in realtà, l'ampiezza della tragedia è davvero grande.
In effetti, ci sono tre punti di cui parlerò oggi:
- Diritti degli utenti vs diritti dei pod. I diritti degli utenti e i diritti dei pod non sono la stessa cosa.
- Raccolta di informazioni sul cluster. Mostrerò che dal cluster è possibile raccogliere tutte le informazioni necessarie senza avere diritti particolari in esso.
- Attacco DoS al cluster. Se non possiamo raccogliere informazioni, possiamo comunque mettere il cluster fuori uso. Parlerò degli attacchi DoS agli elementi di gestione del cluster.
Un'altra cosa comune che menzionerò è su cosa ho testato tutto ciò, su cosa posso affermare con certezza che funziona.
La base del nostro lavoro è l'installazione del cluster Kubernetes tramite Kubespray. Se qualcuno non lo sa, è fondamentalmente un insieme di ruoli per Ansible. Lo utilizziamo continuamente. È utile perché può essere applicato ovunque: sia su hardware che nel cloud. Un modo di installazione è adatto praticamente per tutto.
In this cluster, I will have Kubernetes v1.14.5. The entire Kubernetes cluster we are going to examine is divided into namespaces, each belonging to a different team, with access to each namespace for its team members only. They cannot access different namespaces, only their own. However, there is an admin account that has rights over the entire cluster.
I promised that the first thing we would do is obtain admin rights for the cluster. We need a specially prepared pod that will compromise the Kubernetes cluster. All we need to do is apply it to the Kubernetes cluster.
kubectl apply -f pod.yamlThis pod will be scheduled on one of the masters of the Kubernetes cluster. After that, the cluster will joyfully return to us a file named admin.conf. This file contains all the admin certificates and is also set up with the cluster's API. That's how easily admin access can be obtained, I believe, for 98% of Kubernetes clusters.
To reiterate, this pod was created by a developer in your cluster who has the ability to deploy their proposals in a small namespace, strictly confined by RBAC. They had no rights whatsoever. Nevertheless, the certificate was returned.
Ora parliamo del pod appositamente preparato. Possiamo avviarlo su qualsiasi immagine. Per esempio, prendiamo debian:jessie.
Abbiamo una cosa del genere:
tolerations:
- effect: NoSchedule
operator: Exists
nodeSelector:
node-role.kubernetes.io/master: "" Che cos'è la toleration? I nodi master nel cluster Kubernetes sono solitamente contrassegnati da qualcosa chiamato taint. E la sostanza di questo taint è che non è possibile assegnare pod ai nodi master. Ma niente vieta di specificare in qualsiasi pod che è tollerante a questo taint. La sezione Toleration indica proprio che se un nodo ha NoSchedule, il nostro pod è tollerante a quel taint — e non ci sono problemi.
Inoltre, diciamo che il nostro pod non è solo tollerante, ma desidera specialmente trovarsi sui master. Perché sui master si trova la cosa più preziosa di cui abbiamo bisogno: tutti i certificati. Pertanto, specifichiamo nodeSelector — e abbiamo un'etichetta standard sui master che consente di selezionare i nodi master da tutti i nodi del cluster.
Con queste due sezioni, il pod verrà sicuramente assegnato al master. E gli sarà permesso di viverci.
Ma semplicemente venire al master non è sufficiente. Non ci darà niente. Quindi abbiamo due elementi da considerare:
hostNetwork: true
hostPID: true Indichiamo che il nostro pod, che stiamo eseguendo, opererà nello spazio dei nomi del kernel, nello spazio dei nomi di rete e nello spazio dei nomi PID. Una volta che il pod sarà avviato sul master, potrà vedere tutte le interfacce reali e attive di questo nodo, intercettare tutto il traffico e visualizzare i PID di tutti i processi.
Dopo di che, è semplice. Prendi etcd e leggi ciò che desideri.
La cosa più interessante è che questa è una possibilità di Kubernetes, che è presente per default.
volumeMounts:
- mountPath: /host
name: host
volumes:
- hostPath:
path: /
type: Directory
name: host E la sua essenza è che possiamo nel pod che stiamo avviando, anche senza i diritti su questo cluster, dire che vogliamo creare un volume di tipo hostPath. Questo significa prendere il percorso dall'host su cui stiamo avviando — e usarlo come volume. E poi lo chiamiamo name: host. Montiamo tutto questo hostPath all'interno del pod. In questo esempio, nella directory /host.
Ripeto. Abbiamo detto al pod di venire al master, ottenere hostNetwork e hostPID — e montare l'intero root del master all'interno di questo pod.
Capite che su Debian stiamo eseguendo bash, e questa bash lavora con i privilegi di root. In altre parole, abbiamo appena acquisito i diritti di root sul master, pur non avendo alcun permesso nel cluster Kubernetes.
Il compito successivo è accedere al pod nella directory /host/etc/kubernetes/pki, se non erro, per prelevare tutti i certificati master del cluster e, di conseguenza, diventare admin del cluster.
Se ci si pensa, questi sono alcuni dei diritti più pericolosi all'interno dei pod — indipendentemente dai diritti dell'utente:
Se ho il permesso di lanciare un pod in un certo namespace del cluster, quel pod avrà questi permessi per impostazione predefinita. Posso eseguire pod privilegiati, che praticamente equivalgono a diritti di root sulla node.
Il mio preferito è l'utente Root. Kubernetes ha l'opzione Run As Non-Root. È una sorta di protezione contro gli hacker. Sapete cos'è il "virus moldavo"? Se sei un hacker e entri nel mio cluster Kubernetes, noi, poveri amministratori, chiediamo: "Per favore, specifica nei tuoi pod, attraverso i quali intendi hackerare il mio cluster, di eseguire run as non-root. Altrimenti, finirai per avviare un processo nel tuo pod come root, e sarà molto facile per te hackare il sistema. Proteggiti, per favore, da te stesso".
Il volume dell'host path è, secondo me, il modo più veloce per ottenere il risultato desiderato dal cluster Kubernetes.
Ma cosa fare con tutto questo?
Pensieri che dovrebbero venire a qualsiasi normale amministratore che si confronta con Kubernetes: "Aha, lo sapevo, Kubernetes non funziona. Ha delle falle. E tutto il resto è spazzatura". In realtà, c'è qualcosa chiamato documentazione, e se la si consulta, c'è una sezione .
Questo è un oggetto yaml — possiamo crearlo nel cluster di Kubernetes — che controlla gli aspetti di sicurezza specifici nella descrizione dei pod. In sostanza, controlla i diritti sull'uso di vari hostNetwork, hostPID, e di determinati tipi di volume disponibili nei pod al momento del lancio. Con la Pod Security Policy, tutto questo può essere descritto.
La cosa più interessante della Pod Security Policy è che nel cluster di Kubernetes, tutte le installazioni di PSP non sono semplicemente descritte in alcun modo; sono semplicemente disattivate di default. La Pod Security Policy viene attivata tramite un plugin di ammissione.
Ok, distribuiamo la Pod Security Policy nel cluster, diciamo che abbiamo alcuni pod di servizio in un namespace a cui hanno accesso solo gli amministratori. Diciamo che negli altri pod i diritti sono limitati. Perché è molto probabile che gli sviluppatori non abbiano bisogno di eseguire pod privilegiati nel vostro cluster.
E sembra che tutto vada bene. E il nostro cluster Kubernetes non può essere compromesso in due minuti.
C'è un problema. È molto probabile che, se avete un cluster Kubernetes, abbia un sistema di monitoraggio installato. Mi prendo anche la libertà di prevedere che, se nel vostro cluster è presente un sistema di monitoraggio, si chiama Prometheus.
Quello che sto per raccontare è valido sia per l'operatore Prometheus sia per Prometheus installato in modo tradizionale. Il punto è che se non riesco a ottenere rapidamente un amministratore nel cluster, significa che devo cercare di più. E posso cercare utilizzando la vostra monitorizzazione.
Probabilmente tutti hanno letto gli stessi articoli su Habré, e la monitorizzazione si trova nello namespace monitoring. Il chart di Helm ha un nome piuttosto simile per tutti. Suppongo che se eseguite helm install stable/prometheus, otterrete nomi abbastanza simili. Ed è probabile che non dovrò nemmeno indovinare il nome DNS nel vostro cluster. Perché è standard.
Successivamente, abbiamo un certo dev ns, dove è possibile avviare un pod. E poi, da questo pod, è molto semplice fare così:
$ curl http://prometheus-kube-state-metrics.monitoring prometheus-kube-state-metrics è uno degli exporter di Prometheus che raccoglie metriche dall'API di Kubernetes stesso. Ci sono molti dati su ciò che è in esecuzione nel vostro cluster, com'è, quali problemi avete con esso.
Un esempio semplice:
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:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b»} 1
Eseguendo una semplice richiesta curl da un pod non privilegiato, è possibile ottenere queste informazioni. Se non sai quale versione di Kubernetes stai utilizzando, te lo dirà facilmente.
E la cosa più interessante è che, oltre a interagire con kube-state-metrics, puoi altrettanto facilmente rivolgerti direttamente a Prometheus. Puoi raccogliere le metriche da lì. Puoi persino generare metriche. Teoricamente, puoi costruire una richiesta da un cluster a Prometheus che lo spenga semplicemente. E il tuo monitoraggio smetterà di funzionare del tutto.
A questo punto sorge la domanda se qualche monitoraggio esterno stia monitorando il tuo monitoraggio. Poco fa ho avuto la possibilità di operare nel cluster Kubernetes senza conseguenze per me. Non scopriresti nemmeno che sto operando lì, poiché il monitoraggio non esiste già più.
Proprio come con il PSP, si ha l'impressione che il problema sia che tutte queste tecnologie moderne — Kubernetes, Prometheus — semplicemente non funzionano e sono piene di falle. In realtà, non è così.
C'è una cosa — .
Se sei un amministratore normale, probabilmente sai che la Network Policy è un altro yaml, di cui ce ne sono già troppi nel cluster. E alcune Network Policies sono sicuramente superflue. Anche se hai letto cosa sia la Network Policy, ovvero un firewall in formato yaml per Kubernetes che permette di limitare i diritti di accesso tra i namespace e tra i pod, sicuramente avrai pensato che un firewall in formato yaml in Kubernetes è solo un'ulteriore astrazione... No, no. Non è affatto necessario.
Anche se ai tuoi esperti di sicurezza non è stato detto che con il tuo Kubernetes si può costruire facilmente un firewall, e tra l'altro molto granulare. Se non ne sono ancora a conoscenza e non ti cercano: «Dai, dai...» In ogni caso, hai bisogno della Network Policy per chiudere l'accesso a determinati posti di servizio, che possono essere interrogati dal tuo cluster senza alcuna autorizzazione.
Come nell'esempio che ho fornito, è possibile estrarre kube state metrics da qualsiasi namespace nel cluster Kubernetes, senza avere alcun permesso. Le politiche di rete hanno chiuso l'accesso da tutti gli altri namespace al namespace di monitoraggio e così via: senza accesso, senza problemi. In tutti i chart disponibili, sia quello standard di Prometheus che quello dell'operatore, c'è semplicemente l'opzione nel values di Helm per abilitare le politiche di rete. Basta attivarlo e funzioneranno.
Qui c'è però un problema. Essendo un normale amministratore con la barba, probabilmente hai deciso che le politiche di rete non fossero necessarie. E leggendo vari articoli su risorse come Habr, hai pensato che flannel, specialmente in modalità host-gateway, sia la scelta migliore che puoi fare.
Cosa fare?
Puoi provare a ripristinare la soluzione di rete presente nel tuo cluster Kubernetes, sostituendola con qualcosa di più funzionale, come ad esempio Calico. Tuttavia, voglio dirti subito che cambiare la soluzione di rete in un cluster Kubernetes attivo è un compito piuttosto complesso. Io ho affrontato questa questione due volte (entrambe le volte, in effetti, in modo teorico), ma abbiamo persino mostrato come farlo durante i nostri meeting. Per i nostri corsisti, abbiamo mostrato come cambiare la soluzione di rete in un cluster Kubernetes. Fondamentalmente, puoi provare a farlo senza downtime nel cluster di produzione. Ma probabilmente non avrai successo.
Il problema si risolve in realtà in modo molto semplice. Nel cluster ci sono certificati, e sai che i certificati scadranno dopo un anno. Di solito, una soluzione normale per i certificati nel cluster è: perché preoccuparsi? Creiamo un nuovo cluster accanto, lasciamo che quello vecchio scada, e poi deploziamo tutto lì. Certo, quando scadrà, ci sederemo per un giorno senza nulla, ma avremo comunque un nuovo cluster.
Quando avrai avviato il nuovo cluster, inserisci Calico al posto di flannel.
Cosa fare se i vostri certificati sono emessi per cento anni e non avete intenzione di ridistribuire il cluster? Esiste uno strumento chiamato Kube-RBAC-Proxy. È un'ottima soluzione che permette di integrarsi come sidecar container a qualsiasi pod nel cluster Kubernetes. Di fatto, aggiunge a quel pod l'autenticazione tramite RBAC di Kubernetes stesso.
C'è un problema, però. In passato, la soluzione Kube-RBAC-Proxy era integrata nell'operatore Prometheus. Ma poi è stata rimossa. Le versioni moderne si basano sul fatto che abbiate una policy di rete e le chiudiate tramite essa. Pertanto, sarà necessario riscrivere un po' il chart. In realtà, se andate in , troverete degli esempi su come utilizzarlo come sidecar, e sarà necessario riscrivere il chart con il minimo sforzo.
C'è anche un altro piccolo problema. Non solo Prometheus fornisce le proprie metriche a chiunque. Anche tutti i componenti del cluster Kubernetes sono in grado di esporre le loro metriche.
Ma come ho già detto, se non puoi accedere al cluster e raccogliere informazioni, puoi almeno causare danni.
Quindi, vi mostrerò rapidamente due modi per compromettere la salute di un cluster Kubernetes.
Riderete quando ve lo racconterò, sono due casi della vita reale.
Primo metodo. Esaurimento delle risorse.
Avviamo un altro pod speciale. Avrà questa sezione.
risorse:
richieste:
cpu: 4
memoria: 4Gi Come sapete, le richieste sono la quantità di CPU e memoria riservata per specifici pod con richieste. Se abbiamo un host a quattro core nel cluster Kubernetes, e arriva un pod con richieste di quattro CPU, allora non potrà arrivare nessun altro pod con richieste su questo host.
Se avvio un tale pod, poi farò il comando:
$ kubectl scale special-pod --replicas=...Nessun altro potrà quindi essere distribuito nel cluster Kubernetes. Perché tutte le nodi finiranno le richieste. In questo modo fermerò il vostro cluster Kubernetes. Se lo faccio stasera, potrei fermare i deploy per un bel po' di tempo.
Se diamo un'occhiata alla documentazione di Kubernetes, possiamo vedere una cosa chiamata Limit Range. Questo stabilisce le risorse per gli oggetti del cluster. Puoi scrivere in formato yaml un oggetto Limit Range, applicarlo a determinati namespace e poi in quel namespace puoi dire che hai risorse per i pod con impostazioni predefinite, massime e minime.
Con questo strumento possiamo limitare gli utenti in specifici namespace di prodotto riguardo alle possibilità di specificare sui propri pod cose inadeguate. Ma sfortunatamente, anche se dici all'utente che non può avviare pod con richieste superiori a una CPU, c'è un fantastico comando di scale, oppure attraverso il dashboard possono comunque eseguire lo scale.
E da qui deriva il secondo metodo. Avviamo 11 111 111 111 111 pod. Sono undici miliardi. Non è perché ho inventato questo numero, ma perché l'ho visto io stesso.
Storia reale. Una sera tardi stavo per lasciare l'ufficio. Vedo un gruppo di sviluppatori seduto in un angolo che fa qualcosa di frenetico con i portatili. Mi avvicino a loro e chiedo: "Cosa è successo?"
Poco prima, intorno alle nove di sera, uno degli sviluppatori stava per andare a casa. Pensò: «Ora scalerò la mia applicazione fino a un'unità». Premette uno, ma Internet rallentò un po'. Premette di nuovo uno, schiacciò di nuovo uno e cliccò su Enter. Provo a premere tutto ciò che poteva. Poi, Internet riprese a funzionare — e tutto iniziò a scalare fino a quel numero.
In realtà, questa storia non si svolgeva su Kubernetes, ma su Nomad. Finì che, dopo un'ora dei nostri sforzi per fermare Nomad dalle sue persistentisimi tentativi di scalare, Nomad rispose che non avrebbe smesso di scalare e non si sarebbe dedicato a nient'altro. «Sono stanco, me ne vado». E si ritirò.
Naturalmente provai a fare lo stesso su Kubernetes. Undici miliardi di pod di Kubernetes non furono d'aiuto, disse: «Non posso. Supera i limiti interni». Ma con 1 000 000 000 di pod, ci riuscì.
In risposta a un miliardo, Kubernetes non ha smesso di funzionare. Ha davvero iniziato a scalare. Più il processo andava avanti, più tempo richiedeva per creare nuovi pod. Ma il processo continuava comunque. L'unico problema è che, se posso avviare pod senza limiti nel mio namespace, anche senza richieste e limiti, posso avviare così tanti pod con alcune attività che le nodi iniziano a sovraccaricarsi di memoria e CPU. Quando avvio così tanti pod, le informazioni devono essere archiviate, cioè in etcd. E quando troppe informazioni arrivano lì, lo storage inizia a restituire i dati troppo lentamente, e Kubernetes ha dei rallentamenti.
E un altro problema... Come sapete, i controllori di Kubernetes non sono un'unica entità centrale, ma diversi componenti. Ci sono, in particolare, un controller manager, uno scheduler e così via. Tutti questi elementi inizieranno a svolgere contemporaneamente compiti inutili e poco efficaci, che nel tempo richiederanno sempre più tempo. Il controller manager creerà nuovi pod. Lo scheduler cercherà di trovare un nuovo nodo per loro. Probabilmente, presto avrete esaurito i nuovi nodi nel vostro cluster. Il cluster Kubernetes inizierà a funzionare sempre più lentamente.
Ma ho deciso di andare oltre. Come sapete, in Kubernetes c'è una cosa chiamata servizio. E, per impostazione predefinita, nei vostri cluster, il servizio funziona probabilmente tramite IP tables.
Se si avvia un miliardo di pod, per esempio, e poi si usa uno script per costringere Kubernetes a creare nuovi servizi:
for i in {1..1111111}; do
kubectl expose deployment test --port 80
--overrides="{"apiVersion": "v1",
"metadata": {"name": "nginx$i"}}";
done Su tutti i nodi del cluster verranno generate quasi simultaneamente nuove regole iptables. Inoltre, per ogni servizio verranno generate un miliardo di regole iptables.
Ho testato tutto questo su alcune migliaia, fino a un massimo di dieci. E il problema è che già a questo livello è piuttosto complicato fare SSH su un nodo. Perché i pacchetti, passando attraverso un numero così elevato di catene, iniziano a comportarsi in modo non ottimale.
E tutto questo si risolve anche grazie a Kubernetes. Esiste un oggetto chiamato Resource quota. Imposta il numero di risorse e oggetti disponibili per uno spazio dei nomi nel cluster. Possiamo creare un oggetto yaml in ogni spazio dei nomi del cluster Kubernetes. Con questo oggetto possiamo specificare che per questo spazio dei nomi è assegnato un certo numero di richieste e limiti, e poi possiamo dire che in questo spazio dei nomi è possibile creare 10 servizi e 10 pod. E lo sviluppatore può anche lavorare serenamente la sera. Kubernetes gli dirà: "Non puoi scalare i tuoi pod a tale quantità, perché supera la quota delle risorse." Ecco, il problema è risolto. .
C'è un problema che sorge in merito a questo. Ti rendi conto di quanto sia complicato creare un namespace in Kubernetes. Per farlo, occorre considerare molteplici aspetti.
Quota risorse + Limite di intervallo + RBAC
• Creiamo un namespace
• Creiamo un limitrange al suo interno
• Creiamo una resourcequota al suo interno
• Creiamo un serviceaccount per CI
• Creiamo un rolebinding per CI e gli utenti
• Facoltativamente avviamo i pod di servizio necessari
Colgo l'occasione per condividere i miei sviluppi. C'è uno strumento chiamato operatore SDK. Questo è un modo per scrivere operatori nel cluster Kubernetes. Puoi scrivere operatori usando Ansible.
Inizialmente era scritto in Ansible, poi ho notato l'esistenza dell'operatore SDK e ho riscritto il ruolo Ansible come operatore. Questo operatore consente di creare un oggetto nel cluster Kubernetes chiamato 'comando'. All'interno del comando, si può descrivere in yaml l'ambiente per questo comando. E all'interno dell'ambiente del comando, permette di specificare quali risorse vengono allocate.
Piccola .
E in conclusione. Cosa fare con tutto questo?
Primo. La Pod Security Policy è utile. E nonostante nessuno degli installatori di Kubernetes le utilizzi ancora, è comunque necessario adottarle nei vostri cluster.
La Network Policy non è un'altra funzionalità superflua. È qualcosa di veramente necessario nel cluster.
LimitRange/ResourceQuota — è ora di utilizzarle. Le abbiamo adottate da tempo, e pensavo che fosse una prassi comune. Si è rivelato essere piuttosto raro.
Oltre a quanto menzionato durante la presentazione, ci sono funzionalità non documentate che consentono di attaccare il cluster. Recentemente è stata pubblicata .
Alcuni aspetti sono davvero preoccupanti e sconfortanti. Ad esempio, in alcune condizioni, i kubelet nel cluster Kubernetes possono esporre il contenuto della directory warlocks a un utente non autorizzato.
ci sono istruzioni su come riprodurre tutto ciò di cui ho parlato. Ci sono file con esempi di produzione che mostrano come appaiono ResourceQuota e Pod Security Policy. E tutto questo può essere esplorato.
Grazie a tutti.
Fonte: habr.com
