{"id":39203,"date":"2019-10-31T22:28:25","date_gmt":"2019-10-31T19:28:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf\/"},"modified":"2019-10-31T22:28:25","modified_gmt":"2019-10-31T19:28:25","slug":"zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","title":{"rendered":"Stiamo riparando le falle nel cluster Kubernetes. Relazione e trascrizione da DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, architetto delle soluzioni Southbridge e docente di Slurm, ha tenuto una relazione al DevOpsConf 2019. Questa relazione fa parte di uno degli argomenti del corso avanzato su Kubernetes \"Slurm Mega\".<\/p>\n

<\/p>\n

Slurm Base: introduzione a Kubernetes<\/a><\/noindex> si svolge a Mosca dal 18 al 20 novembre.
\nSlurm Mega: diamo un'occhiata sotto il cofano di Kubernetes<\/a><\/noindex> \u2014 Mosca, dal 22 al 24 novembre.
\nSlurm Online: entrambi i corsi su Kubernetes<\/a><\/noindex> sono sempre disponibili.<\/p>\n

\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Dopo il salto \u2014 trascrizione della relazione.<\/p>\n

<\/a><\/noindex><\/p>\n

Buongiorno colleghi e simpatizzanti. Oggi parler\u00f2 di sicurezza.<\/p>\n

<\/p>\n

Vedo che oggi in sala ci sono molti esperti di sicurezza. Vi chiedo scusa in anticipo se utilizzer\u00f2 termini dal mondo della sicurezza in modo non convenzionale. <\/p>\n

<\/p>\n

\u00c8 successo che circa sei mesi fa ho avuto accesso a un cluster Kubernetes pubblico. Pubblico significa che ci sono n namespace, in questi namespace ci sono utenti, isolati nel loro namespace. Tutti questi utenti appartengono a diverse aziende. E si prevedeva che questo cluster fosse utilizzato come CDN. Cio\u00e8 ti danno un cluster, ti danno un utente, e tu accedi nel tuo namespace per fare il deploy delle tue interfacce. <\/p>\n

<\/p>\n

Alla mia azienda precedente hanno provato a vendere un servizio simile. E mi \u00e8 stato chiesto di testare il cluster per vedere se una soluzione del genere fosse adatta. <\/p>\n

<\/p>\n

Sono andato in questo cluster. Mi hanno dato diritti limitati e un namespace ristretto. L\u00ec i ragazzi sapevano cosa significasse sicurezza. Avevano studiato cosa fosse il controllo degli accessi basato su ruoli (RBAC) di Kubernetes e l'avevano impostato in modo tale che non potessi avviare pod separatamente dai deployment. Non ricordo il compito che stavo cercando di risolvere avviando un pod senza deployment, ma volevo davvero avviare semplicemente un pod. Ho deciso di controllare un po' quali diritti avevo nel cluster, cosa potevo fare, cosa non potevo fare, quali limitazioni avevano impostato. Inoltre, racconter\u00f2 cosa avevano impostato male in RBAC. <\/p>\n

<\/p>\n

\u00c8 successo che dopo due minuti ho ottenuto i diritti di admin nel loro cluster, ho esaminato tutti i namespace vicini e ho visto che c'erano deployment di interfacce di produzione di aziende che avevano gi\u00e0 acquistato il servizio e si erano gi\u00e0 deployati. Ho faticato a trattenermi dal venire da qualcuno e piazzare una parola volgare sulla loro homepage. <\/p>\n

<\/p>\n

Racconter\u00f2 con esempi come ho fatto e come proteggersi da esso. <\/p>\n

<\/p>\n

Ma per iniziare, mi presento. Mi chiamo Pavel Selivanov. Sono un architetto della Southbridge. Ho esperienza in Kubernetes, DevOps e in varie tecnologie all'avanguardia. Insieme ai miei ingegneri di Southbridge, realizziamo tutto questo e io fornisco consulenza. <\/p>\n

<\/p>\n

Oltre all'attivit\u00e0 principale, recentemente abbiamo lanciato dei progetti chiamati Sl\u0451rmy. Stiamo cercando di portare le nostre competenze su Kubernetes a un pubblico pi\u00f9 ampio, per insegnare ad altre persone a lavorare con K8s. <\/p>\n

<\/p>\n

Di cosa parler\u00f2 oggi. Il tema della mia presentazione \u00e8 chiaro: la sicurezza del cluster Kubernetes. Ma voglio subito dire che questo argomento \u00e8 molto ampio, e quindi voglio chiarire subito cosa non tratter\u00f2. Non parler\u00f2 di termini inflazionati che sono stati gi\u00e0 discussi mille volte su internet. Tipo RBAC e certificati. <\/p>\n

<\/p>\n

Parler\u00f2 di quali siano le problematiche relative alla sicurezza nel cluster Kubernetes che io e i miei colleghi incontriamo. Questi problemi li vediamo sia dai fornitori che forniscono cluster Kubernetes, sia dai clienti che si rivolgono a noi. Anche dai clienti che provengono da altre aziende di consulenza. Quindi, l'entit\u00e0 del problema \u00e8 in realt\u00e0 molto grande. <\/p>\n

<\/p>\n

Tre punti di cui parler\u00f2 oggi: <\/p>\n

<\/p>\n

    \n
  1. Diritti degli utenti vs diritti dei pod. I diritti degli utenti e i diritti dei pod non sono la stessa cosa. <\/li>\n
  2. Raccolta di informazioni sul cluster. Mostrer\u00f2 come sia possibile raccogliere tutte le informazioni necessarie da un cluster, senza avere diritti particolari in quel cluster. <\/li>\n
  3. Attacco DoS al cluster. Se non possiamo raccogliere informazioni, saremo comunque in grado di compromettere il cluster. Parler\u00f2 degli attacchi DoS sugli elementi di gestione del cluster. <\/li>\n<\/ol>\n

    <\/p>\n

    Un'altra cosa generale di cui menzioner\u00f2 \u00e8 su cosa ho effettuato tutti questi test, su cosa posso affermare con certezza che funziona.<\/p>\n

    <\/p>\n

    Come base, prendiamo l'installazione del cluster Kubernetes utilizzando Kubespray. Se qualcuno non lo sa, \u00e8 fondamentalmente un insieme di ruoli per Ansible. Nella nostra attivit\u00e0 lo utilizziamo costantemente. \u00c8 comodo perch\u00e9 pu\u00f2 essere implementato ovunque: lo si pu\u00f2 installare su hardware fisico o in un cloud. Un metodo di installazione si adatta praticamente a tutto. <\/p>\n

    <\/p>\n

    In questo cluster avr\u00f2 Kubernetes v1.14.5. L'intero cluster di Kubernetes che esamineremo \u00e8 suddiviso in namespace, ciascun namespace appartiene a un team separato, e solo i membri di quel team hanno accesso a quel namespace. Non possono accedere ad altri namespace, solo al proprio. Ma c'\u00e8 un account admin che ha diritti su tutto il cluster. <\/p>\n

    <\/p>\n

    \"Stiamo<\/p>\n

    <\/p>\n

    Ho promesso che la prima cosa sar\u00e0 ottenere i diritti admin sul cluster. Abbiamo bisogno di un pod appositamente preparato che romper\u00e0 il cluster Kubernetes. Tutto ci\u00f2 che dobbiamo fare \u00e8 applicarlo nel cluster Kubernetes. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    Questo pod arriver\u00e0 su uno dei nodi master del cluster Kubernetes. E il cluster ci restituir\u00e0 felicemente un file chiamato admin.conf. In questo file di Kubernetes sono presenti tutti i certificati admin, e inoltre \u00e8 configurato l'API del cluster. \u00c8 cos\u00ec semplice ottenere l'accesso admin, penso, per il 98% dei cluster Kubernetes. <\/p>\n
    <\/p>\n
    Ripeto, questo pod \u00e8 stato creato da uno sviluppatore nel tuo cluster, che ha accesso per distribuire le proprie proposte in un piccolo namespace, tutto vincolato da RBAC. Non aveva alcun diritto. Eppure il certificato \u00e8 tornato. <\/p>\n
    <\/p>\n
    Ora parliamo del pod appositamente preparato. Lo avviamo su qualsiasi immagine. Per esempio, prendiamo debian:jessie. <\/p>\n
    <\/p>\n
    Abbiamo questa cosa: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Cos'\u00e8 una toleration? I master nel cluster Kubernetes sono solitamente contrassegnati da una cosa chiamata taint (\"contaminazione\" in inglese). E il punto di questa \"contaminazione\" \u00e8 che sui nodi master non possono essere assegnati pod. Ma nulla impedisce a qualunque pod di dichiarare che \u00e8 tollerante alla \"contaminazione\". La sezione Toleration dice proprio che se su qualche nodo \u00e8 impostato NoSchedule, allora il nostro pod \u00e8 tollerante a tale contaminazione \u2014 e non ci sono problemi. <\/p>\n
    <\/p>\n
    In seguito, diciamo che il nostro pod non \u00e8 solo tollerante, ma vuole anche entrare specificamente nel nodo master. Perch\u00e9 sui master ci sono le risorse pi\u00f9 preziose di cui abbiamo bisogno: tutti i certificati. Quindi diciamo nodeSelector \u2014 e abbiamo un'etichetta standard sui master, che consente di selezionare tra tutti i nodi del cluster solo i nodi che sono master. <\/p>\n
    <\/p>\n
    Con queste due sezioni, il pod arriver\u00e0 sicuramente sul nodo master. E gli sar\u00e0 consentito di risiedere l\u00ec. <\/p>\n
    <\/p>\n
    Ma semplicemente arrivare sul master non \u00e8 sufficiente. Non ci dar\u00e0 nulla. Quindi ora abbiamo queste due cose:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Indichiamo che il nostro pod, che stiamo avviando, vivr\u00e0 nello spazio dei nomi del kernel, nello spazio dei nomi di rete e nello spazio dei nomi PID. Una volta che il pod \u00e8 avviato sul master, potr\u00e0 vedere tutte le interfacce attive e reali di questo nodo, intercettare tutto il traffico e vedere il PID di tutti i processi.<\/p>\n
    <\/p>\n
    Poi, \u00e8 una questione semplice. Prendete etcd e leggete ci\u00f2 che desiderate. <\/p>\n
    <\/p>\n
    La cosa pi\u00f9 interessante \u00e8 questa funzionalit\u00e0 di Kubernetes, che \u00e8 presente di default. <\/p>\n
    <\/p>\n
    volumeMounts:\n- mountPath: \/host \n  name: host \nvolumes:\n- hostPath: \n    path: \/ \n    type: Directory \n  name: host <\/code><\/pre>\n
    <\/p>\n
    E la sostanza di tutto ci\u00f2 \u00e8 che possiamo, nel pod che stiamo lanciando, anche senza diritti su questo cluster, dire che vogliamo creare un volume di tipo hostPath. Questo significa prendere un percorso dall'host su cui siamo in esecuzione e usarlo come volume. E poi lo chiamiamo name: host. Interamente questo hostPath viene montato all'interno del pod. In questo esempio nella directory \/host. <\/p>\n
    <\/p>\n
    Ripeto ancora una volta. Abbiamo detto al pod di venire sul master, ottenere l\u00ec hostNetwork e hostPID, e montare l'intero root del master all'interno di questo pod. <\/p>\n
    <\/p>\n
    Capite che in Debian abbiamo bash in esecuzione, e questa bash lavora come root. Quindi, abbiamo appena ottenuto i diritti di root sul master, senza avere diritti nel cluster Kubernetes.<\/p>\n
    <\/p>\n
    La prossima sfida \u00e8 entrare nel pod nella directory \/host\/etc\/kubernetes\/pki, se non sbaglio, prelevare tutti i certificati master del cluster e, di conseguenza, diventare l'amministratore del cluster. <\/p>\n
    <\/p>\n
    Se ci pensate, questi sono alcuni dei diritti pi\u00f9 pericolosi nei pod - indipendentemente dai diritti che ha l'utente:
    \n\"Stiamo<\/p>\n
    <\/p>\n
    Se ho i diritti di avviare un pod in qualche spazio dei nomi del cluster, allora questo pod ha di default questi diritti. Posso avviare pod privilegiati, e questo significa praticamente tutti i diritti, quasi come root sul nodo. <\/p>\n
    <\/p>\n
    La mia preferita \u00e8 l'Utente root. E Kubernetes ha un'opzione chiamata 'Run As Non-Root'. \u00c8 una forma di protezione contro gli hacker. Sapete cosa \u00e8 il 'virus moldavo'? Se siete hacker e siete entrati nel mio cluster Kubernetes, noi, poveri amministratori, chiediamo: 'Per favore, indicate nei vostri pod, con cui hackererete il mio cluster, run as non-root. Altrimenti succeder\u00e0 che lancerete un processo nel vostro pod come root e sar\u00e0 molto semplice hackerarmi. Proteggetevi, per favore, da voi stessi.' <\/p>\n
    <\/p>\n
    L'host path volume \u00e8, secondo me, il modo pi\u00f9 veloce per ottenere il risultato desiderato dal cluster Kubernetes. <\/p>\n
    <\/p>\n
    Ma cosa fare con tutto questo? <\/p>\n
    <\/p>\n
    Pensieri che dovrebbero venire a qualsiasi amministratore normale che si confronta con Kubernetes: \u00abAha, lo sapevo, Kubernetes non funziona. Ha delle falle. E tutto il resto \u00e8 spazzatura\u00bb. In realt\u00e0, c'\u00e8 qualcosa chiamato documentazione, e se ci si guarda, c'\u00e8 una sezione Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Questo \u00e8 un oggetto yaml \u2013 che possiamo creare nel cluster Kubernetes \u2013 che controlla gli aspetti di sicurezza proprio nella descrizione dei pod. Quindi, di fatto, controlla i permessi per l'uso di vari hostNetwork, hostPID, e determinati tipi di volume che ci sono nei pod al momento del lancio. Con la Pod Security Policy, tutto ci\u00f2 pu\u00f2 essere descritto. <\/p>\n
    <\/p>\n
    La cosa pi\u00f9 interessante della Pod Security Policy \u00e8 che nel cluster Kubernetes, nessun installatore di PSP \u00e8 descritto in alcun modo, sono semplicemente disabilitati per impostazione predefinita. La Pod Security Policy viene attivata tramite un plugin di ammissione.<\/p>\n
    <\/p>\n
    Ok, nel cluster implementiamo la Pod Security Policy, diciamo che abbiamo alcuni pod di servizio nello namespace, a cui hanno accesso solo gli amministratori. Diciamo che negli altri pod i permessi sono limitati. Perch\u00e9 \u00e8 probabile che gli sviluppatori non abbiano bisogno di avviare pod privilegiati nel vostro cluster. <\/p>\n
    <\/p>\n
    E a quanto pare tutto va bene. E il nostro cluster Kubernetes non pu\u00f2 essere compromesso in due minuti. <\/p>\n
    <\/p>\n
    C'\u00e8 un problema. \u00c8 probabile che, se avete un cluster Kubernetes, ci sia un monitoraggio installato. Mi azzardo a prevedere che se nel vostro cluster c'\u00e8 un monitoraggio, si chiama Prometheus. <\/p>\n
    <\/p>\n
    Quello che sto per raccontare sar\u00e0 valido sia per l'operatore Prometheus che per Prometheus installato in modo standard. Il problema \u00e8 che se non riesco a ottenere rapidamente un amministratore nel cluster, significa che devo cercare di pi\u00f9. E posso cercare utilizzando il vostro monitoraggio.<\/p>\n
    <\/p>\n
    Probabilmente, tutti hanno letto gli stessi articoli su Habr, e il monitoraggio si trova nello namespace monitoring. Il chart di Helm per tutti si chiama pi\u00f9 o meno allo stesso modo. Suppongo che se fate helm install stable\/prometheus, otterrete nomi pi\u00f9 o meno identici. E molto probabilmente non dovr\u00f2 neanche indovinare il nome DNS nel vostro cluster. Perch\u00e9 \u00e8 standard. <\/p>\n
    <\/p>\n
    \"Stiamo<\/p>\n
    <\/p>\n
    Poi abbiamo un certo dev ns, in cui \u00e8 possibile avviare un certo pod. E da questo pod \u00e8 molto facile fare cos\u00ec: <\/p>\n
    <\/p>\n
    $ curl http:\/\/prometheus-kube-state-metrics.monitoring <\/code><\/pre>\n
    <\/p>\n
    prometheus-kube-state-metrics \u00e8 uno degli exporter di Prometheus che raccoglie metriche dall'API di Kubernetes stesso. Ci sono molti dati su cosa \u00e8 in esecuzione nel tuo cluster, quali problemi hai con esso. <\/p>\n
    <\/p>\n
    Come semplice esempio: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\"kube-system\",pod=\"kube-apiserver-k8s-1\",container=\"kube-apiserver\",image= <\/p>\n
    <\/p>\n
    \"gcr.io\/google-containers\/kube-apiserver:v1.14.5\" <\/strong><\/p>\n
    <\/p>\n
    ,image_id=\"docker-pullable:\/\/gcr.io\/google-containers\/kube-apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a9638ee634989\",container_id=\"docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2853397d7daf08e72c22d3cf8b\"} 1 <\/p>\n
    <\/p>\n
    Facendo una semplice richiesta curl da un pod non privilegiato, puoi ottenere queste informazioni. Se non sai in quale versione di Kubernetes sei in esecuzione, te lo dir\u00e0 facilmente. <\/p>\n
    <\/p>\n
    E la cosa pi\u00f9 interessante \u00e8 che oltre a contattare kube-state-metrics, puoi contattare direttamente anche Prometheus. Puoi raccogliere metriche da l\u00ec. Puoi anche costruire metriche da l\u00ec. Anche teoricamente, puoi formulare una richiesta dal cluster a Prometheus che lo spegner\u00e0 semplicemente. E la tua monitorizzazione smetter\u00e0 completamente di funzionare nel cluster. <\/p>\n
    <\/p>\n
    E qui sorge la domanda, se qualche monitoraggio esterno stia monitorando il tuo monitoraggio. Ho appena ottenuto la possibilit\u00e0 di agire nel cluster Kubernetes senza alcuna conseguenza per me. Non ti accorgerai nemmeno che sto agendo l\u00ec, poich\u00e9 non c'\u00e8 pi\u00f9 monitoraggio. <\/p>\n
    <\/p>\n
    Proprio come con PSP, c'\u00e8 la sensazione che il problema sia che tutte queste tecnologie alla moda \u2014 Kubernetes, Prometheus \u2014 semplicemente non funzionano e siano piene di falle. In realt\u00e0 non \u00e8 cos\u00ec. <\/p>\n
    <\/p>\n
    Esiste una cosa \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Se sei un admin normale, probabilmente sai che per Network Policy si tratta di un altro yaml, ce ne sono gi\u00e0 tanti nel cluster. E alcune Network Policies non sono affatto necessarie. E anche se hai letto cosa sia una Network Policy, ovvero un firewall yaml di Kubernetes, che consente di limitare i diritti di accesso tra namespace e tra pod, certamente hai gi\u00e0 deciso che un firewall in formato yaml in Kubernetes \u00e8 sull'ennesima astrazione... No, no. Questo non \u00e8 affatto necessario. <\/p>\n
    <\/p>\n
    Anche se ai vostri esperti di sicurezza non \u00e8 stato detto che con il vostro Kubernetes si pu\u00f2 creare un firewall in modo molto semplice e diretto, e se non lo sanno ancora e non vi importunano: \u00abDai, dai...\u00bb. In ogni caso, vi serve una Network Policy per chiudere l'accesso ad alcune aree di servizio che possono essere richiamate dal vostro cluster senza alcuna autorizzazione. <\/p>\n
    <\/p>\n
    Come nell'esempio che ho fornito, \u00e8 possibile richiamare kube state metrics da qualsiasi namespace nel cluster Kubernetes, senza avere alcun permesso. Le politiche di rete hanno bloccato l'accesso da tutti gli altri namespace al namespace di monitoraggio e, in pratica, \u00e8 tutto: nessun accesso, nessun problema. In tutti i chart disponibili, sia del prometeo standard che di quello incluso nell'operatore, c'\u00e8 semplicemente un'opzione in values di helm per abilitare le politiche di rete. Basta attivarle e funzioneranno. <\/p>\n
    <\/p>\n
    C'\u00e8 per\u00f2 un problema. Essendo un normale amministratore con la barba, probabilmente hai pensato che le politiche di rete non siano necessarie. E dopo aver letto vari articoli su risorse come Habr, hai concluso che flannel, soprattutto in modalit\u00e0 host-gateway, sia la migliore opzione che puoi scegliere. <\/p>\n
    <\/p>\n
    Cosa fare? <\/p>\n
    <\/p>\n
    Puoi provare a ridistribuire la soluzione di rete che hai nel tuo cluster Kubernetes, tentando di sostituirla con qualcosa di pi\u00f9 funzionale. Ad esempio, Calico. Ma voglio subito dirti che cambiare la soluzione di rete in un cluster Kubernetes attivo \u00e8 un compito piuttosto non triviale. L'ho affrontato due volte (entrambe le volte, per\u00f2, teoricamente), ma abbiamo anche mostrato su Slurm come farlo. Per i nostri corsisti abbiamo dimostrato come cambiare la soluzione di rete in un cluster Kubernetes. In linea di massima, puoi provare a farlo senza downtime nel cluster di produzione, ma probabilmente non ci riuscirai. <\/p>\n
    <\/p>\n
    E il problema, in realt\u00e0, si risolve molto facilmente. Nel cluster ci sono certificati, e tu sai che questi certificati scadranno dopo un anno. E di solito, la soluzione standard con i certificati in un cluster \u00e8: perch\u00e9 preoccuparsi, alziamo un nuovo cluster accanto, lasciamo scadere il vecchio e ridistribuiamo tutto. A dire il vero, quando scadr\u00e0, il sistema rester\u00e0 inattivo per un giorno, ma avremo un nuovo cluster. <\/p>\n
    <\/p>\n
    Quando alzerai il nuovo cluster, inserisci Calico al posto di flannel. <\/p>\n
    <\/p>\n
    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. \u00c8 uno sviluppo molto interessante, in quanto permette di integrarsi come container sidecar a qualsiasi pod nel cluster Kubernetes. E in effetti aggiunge autorizzazione a questo pod tramite RBAC di Kubernetes stesso. <\/p>\n
    <\/p>\n
    C'\u00e8 un problema per\u00f2. In passato, nella versione dell'operatore Prometheus, questa soluzione Kube-RBAC-Proxy era integrata. Ma poi \u00e8 stata rimossa. Ora le versioni moderne si basano sul fatto che avete una network policy e chiudete l'accesso utilizzando essa. Pertanto, sar\u00e0 necessario riscrivere un po' il chart. In realt\u00e0, se andate a questo repository<\/a><\/noindex>, troverete esempi su come utilizzarlo come sidecars, e sar\u00e0 necessario riscrivere il chart il meno possibile. <\/p>\n
    <\/p>\n
    C'\u00e8 anche un altro piccolo problema. Non solo Prometheus fornisce le sue metriche a chiunque. Anche tutti i componenti del cluster Kubernetes possono fornire le proprie metriche. <\/p>\n
    <\/p>\n
    Ma come ho gi\u00e0 detto, se non puoi accedere al cluster e raccogliere informazioni, puoi comunque causare qualche danno. <\/p>\n
    <\/p>\n
    Quindi vi mostrer\u00f2 rapidamente due modi in cui puoi compromettere la salute di un cluster Kubernetes. <\/p>\n
    <\/p>\n
    Scommetto che riderete quando vi racconter\u00f2 di questo, sono due casi della vita reale. <\/p>\n
    <\/p>\n
    Primo metodo. Esaurimento delle risorse. <\/p>\n
    <\/p>\n
    Avviamo un altro pod speciale. Avr\u00e0 una sezione simile a questa. <\/p>\n
    <\/p>\n
    resources: \n    requests: \n        cpu: 4 \n        memory: 4Gi <\/code><\/pre>\n
    <\/p>\n
    Come sapete, le richieste sono la quantit\u00e0 di CPU e memoria riservata per specifici pod con richieste. Se abbiamo un host quad-core nel cluster Kubernetes, e arriva un pod con una richiesta di quattro CPU, significa che non pu\u00f2 arrivare nessun altro pod con richieste su questo host. <\/p>\n
    <\/p>\n
    Se avviassi un pod di questo tipo, poi eseguirei il comando: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Allora nessun altro potr\u00e0 essere distribuito nel cluster Kubernetes. Perch\u00e9 tutte le nodi esauriranno le richieste. E cos\u00ec facendo fermer\u00f2 il vostro cluster Kubernetes. Se facessi questo la sera, potrei fermare i deploy per un bel po' di tempo. <\/p>\n
    <\/p>\n
    Se diamo un'altra occhiata alla documentazione di Kubernetes, vedremo una cosa chiamata Limit Range. Essa stabilisce le risorse per gli oggetti del cluster. Puoi scrivere un oggetto Limit Range in yaml, applicarlo a specifici namespace \u2014 e poi in quel namespace puoi dire che hai risorse per i pod di tipo predefinito, massimo e minimo.<\/p>\n
    <\/p>\n
    Con questa cosa possiamo limitare gli utenti in specifici namespace di prodotto delle squadre nelle loro possibilit\u00e0 di indicare le loro porcherie nei pod. Ma sfortunatamente, anche se dici all'utente che non pu\u00f2 avviare i pod con richieste superiori a una CPU, esiste un comando meraviglioso chiamato scale, o tramite dashboard possono fare scale.<\/p>\n
    <\/p>\n
    E da qui deriva il secondo modo. Avviamo 11 111 111 111 111 pod. Sono undici miliardi. Non perch\u00e9 io abbia inventato un numero del genere, ma perch\u00e9 l'ho visto io stesso. <\/p>\n
    <\/p>\n
    Una storia reale. Tardi la sera stavo per lasciare l'ufficio. Vedo un gruppo di sviluppatori che sta facendo qualcosa di frenetico con i portatili in un angolo. Mi avvicino ai ragazzi e chiedo: \u00abCosa \u00e8 successo?\u00bb<\/p>\n
    <\/p>\n
    Poco prima, intorno alle nove di sera, uno degli sviluppatori stava per andare a casa. E ha pensato: \u00abAdesso scaler\u00f2 la mia applicazione a uno\u00bb. Ha premuto uno, ma internet ha rallentato un po'. Ha premuto di nuovo su uno, ha schiacciato uno, ha cliccato su Invio. Ha provato a toccare tutto ci\u00f2 che poteva. A quel punto, internet si \u00e8 ripreso \u2014 e tutto ha iniziato a scalare verso quel numero. <\/p>\n
    <\/p>\n
    D'altronde, questa storia non stava accadendo su Kubernetes, in quel momento era Nomad. \u00c8 finita cos\u00ec, che dopo un'ora dei nostri tentativi di fermare Nomad dalle persistenti tentativi di scalare, Nomad ha risposto che non avrebbe smesso di scalare e non avrebbe fatto nient'altro. \u00abSono stanco, me ne vado\u00bb. E si \u00e8 chiuso. <\/p>\n
    <\/p>\n
    Naturalmente ho provato a fare lo stesso su Kubernetes. Undici miliardi di pod non hanno fatto felice Kubernetes, ha detto: \u00abNon posso. Supera i limiti interni\u00bb. Ma 1 000 000 000 pod ce l'ha fatta. <\/p>\n
    <\/p>\n
    In risposta a un miliardo di pod, Kubernetes non \u00e8 andato in crash. Ha davvero iniziato a scalare. Pi\u00f9 il processo avanzava, pi\u00f9 tempo impiegava per creare nuovi pod. Tuttavia, il processo continuava. L'unico problema \u00e8 che, se posso lanciare pod senza limiti nel mio namespace, anche senza richieste e limiti, posso lanciare un numero tale di pod con determinate attivit\u00e0 che le risorse delle nodi iniziano a saturarsi in termini di memoria e CPU. Quando avvio cos\u00ec tanti pod, le informazioni da essi devono arrivare allo storage, ovvero etcd. E quando troppe informazioni arrivano l\u00ec, lo storage inizia a restituire dati troppo lentamente \u2014 e Kubernetes subisce dei rallentamenti. <\/p>\n
    <\/p>\n
    Ma c'\u00e8 un altro problema\u2026 Come sapete, gli elementi di controllo di Kubernetes non sono un'unica entit\u00e0 centrale, ma diversi componenti. Ci sono in particolare il controller manager, lo scheduler e cos\u00ec via. Tutti questi componenti inizieranno a eseguire simultaneamente lavoro inutile e confuso, che col tempo inizier\u00e0 a richiedere sempre pi\u00f9 tempo. Il controller manager creer\u00e0 nuovi pod. Lo scheduler cercher\u00e0 di trovare loro un nuovo nodo. \u00c8 probabile che nuovi nodi nel vostro cluster finiscano presto. Il cluster Kubernetes inizier\u00e0 a funzionare sempre pi\u00f9 lentamente.<\/p>\n
    <\/p>\n
    Ma ho deciso di spingermi oltre. Come sapete, in Kubernetes esiste una cosa chiamata servizio. Beh, di default nei vostri cluster, molto probabilmente, il servizio funziona tramite IP tables. <\/p>\n
    <\/p>\n
    Ad esempio, se lanciate un miliardo di pod, e poi con uno script costringete Kubernetes a creare nuovi servizi: <\/p>\n
    <\/p>\n
    for i in {1..1111111}; do\n    kubectl expose deployment test --port 80  \n        --overrides=\"{\"apiVersion\": \"v1\", \n           \"metadata\": {\"name\": \"nginx$i\"}}\"; \ndone <\/code><\/pre>\n
    <\/p>\n
    Su tutti i nodi del cluster verranno generati tutto il tempo nuovi e nuovi regole iptables. In particolare, per ogni servizio verranno generati un miliardo di regole iptables. <\/p>\n
    <\/p>\n
    Ho testato tutto questo su diverse migliaia, fino a decine. E il problema \u00e8 che gi\u00e0 a questo livello \u00e8 piuttosto problematico fare ssh su un nodo. Perch\u00e9 i pacchetti, passando attraverso cos\u00ec tante catene, iniziano a comportarsi male. <\/p>\n
    <\/p>\n
    E anche questo si risolve grazie a Kubernetes. C'\u00e8 un oggetto chiamato Resource quota. Imposta il numero di risorse e oggetti disponibili per uno specifico namespace nel cluster. Possiamo creare un oggetto yaml in ogni namespace del cluster Kubernetes. Con questo oggetto possiamo indicare che per questo namespace \u00e8 riservata una certa quantit\u00e0 di richieste, limiti, e poi possiamo dire che in questo namespace possono essere creati 10 servizi e 10 pod. E il developer pu\u00f2 divertirsi anche la sera. Kubernetes gli dir\u00e0: \"Non puoi scalare i tuoi pod a quel numero, perch\u00e9 supera la quota delle risorse\". Ecco, il problema \u00e8 risolto. Documentazione qui<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Un problema sorge in relazione a questo. Senti quanto sia difficile creare un namespace in Kubernetes. Per crearlo, dobbiamo considerare un sacco di cose.<\/p>\n
    <\/p>\n
    Resource quota + Limit Range + RBAC
    \n\u2022 Creiamo il namespace
    \n\u2022 Creiamo all'interno limitrange
    \n\u2022 Creiamo all'interno resourcequota
    \n\u2022 Creiamo serviceaccount per CI
    \n\u2022 Creiamo rolebinding per CI e utenti
    \n\u2022 Facoltativamente avviamo i pod di servizio necessari <\/p>\n
    <\/p>\n
    Quindi, cogliendo l'occasione, vorrei condividere le mie realizzazioni. C'\u00e8 una cosa chiamata operatore SDK. \u00c8 un modo per scrivere operatori per Kubernetes all'interno del cluster. Puoi scrivere operatori usando Ansible.<\/p>\n
    <\/p>\n
    Inizialmente avevamo scritto in Ansible, poi ho visto che esisteva l'operatore SDK e ho riscritto il ruolo Ansible in un operatore. Questo operatore consente di creare nel cluster Kubernetes un oggetto chiamato comando. All'interno del comando, permette di descrivere in yaml l'ambiente per questo comando. E all'interno dell'ambiente del comando permette di descrivere che stiamo riservando un certo numero di risorse. <\/p>\n
    <\/p>\n
    Piccola semplificazione di tutto questo processo complesso<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    E in conclusione. Cosa fare con tutto questo?
    \nPrimo. La Pod Security Policy \u00e8 buona. E nonostante nessuno dei fornitori di Kubernetes li utilizzi ancora oggi, \u00e8 comunque necessario usarli nei tuoi cluster. <\/p>\n
    <\/p>\n
    La Network Policy non \u00e8 un'altra funzione superflua. \u00c8 qualcosa di realmente necessario nel cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 \u00e8 tempo di usarli. Abbiamo iniziato a usarli tempo fa, e sono stato a lungo convinto che tutti li adottassero. Si \u00e8 rivelato che \u00e8 raro. <\/p>\n
    <\/p>\n
    Oltre a quanto ho menzionato durante la presentazione, ci sono funzionalit\u00e0 non documentate che consentono di attaccare il cluster. \u00c8 uscito recentemente una grande analisi delle vulnerabilit\u00e0 di Kubernetes<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Alcune cose sono cos\u00ec tristi e fastidiose. Come, ad esempio, in alcune condizioni le kubelet nel cluster Kubernetes possono restituire il contenuto della directory dei warlocks a un utente non autorizzato. <\/p>\n
    <\/p>\n
    Qui<\/a><\/noindex> ci sono istruzioni su come riprodurre tutto ci\u00f2 di cui ho parlato. Ci sono file con esempi di produzione, come appare ResourceQuota, Pod Security Policy. E tutto questo pu\u00f2 essere toccato. <\/p>\n
    <\/p>\n
    Grazie a tutti.<\/p>\n
    Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
    \u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019. \u042d\u0442\u043e\u0442 \u0434\u043e\u043a\u043b\u0430\u0434 \u2014 \u0447\u0430\u0441\u0442\u044c \u043e\u0434\u043d\u043e\u0439 \u0438\u0437 \u0442\u0435\u043c \u0443\u0433\u043b\u0443\u0431\u043b\u0435\u043d\u043d\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u00ab\u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430\u00bb. \u0421\u043b\u0451\u0440\u043c \u0411\u0430\u0437\u043e\u0432\u044b\u0439: \u0432\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 Kubernetes \u043f\u0440\u043e\u0445\u043e\u0434\u0438\u0442 \u0432 \u041c\u043e\u0441\u043a\u0432\u0435 18-20 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041c\u0435\u0433\u0430: \u0437\u0430\u0433\u043b\u044f\u0434\u044b\u0432\u0430\u0435\u043c \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442 Kubernetes \u2014 \u041c\u043e\u0441\u043a\u0432\u0430, 22-24 \u043d\u043e\u044f\u0431\u0440\u044f. \u0421\u043b\u0451\u0440\u043c \u041e\u043d\u043b\u0430\u0439\u043d: \u043e\u0431\u0430 \u043a\u0443\u0440\u0441\u0430 \u043f\u043e Kubernetes \u0434\u043e\u0441\u0442\u0443\u043f\u0435\u043d \u0432\u0441\u0435\u0433\u0434\u0430. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29423,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39203","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Stiamo coprendo le falle nel cluster Kubernetes. Presentazione e trascrizione dal DevOpsConf | ProHoster","description":"Pavel Selivanov, architetto di soluzioni per Southbridge e docente di Sl\u0451rma, ha tenuto una presentazione al DevOpsConf 2019.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0417\u0430\u0434\u0435\u043b\u044b\u0432\u0430\u0435\u043c \u0434\u044b\u0440\u044b \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0414\u043e\u043a\u043b\u0430\u0434 \u0438 \u0440\u0430\u0441\u0448\u0438\u0444\u0440\u043e\u0432\u043a\u0430 \u0441 DevOpsConf | ProHoster","og:description":"\u041f\u0430\u0432\u0435\u043b \u0421\u0435\u043b\u0438\u0432\u0430\u043d\u043e\u0432, \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u043e\u0440 \u0440\u0435\u0448\u0435\u043d\u0438\u0439 Southbridge \u0438 \u043f\u0440\u0435\u043f\u043e\u0434\u0430\u0432\u0430\u0442\u0435\u043b\u044c \u0421\u043b\u0451\u0440\u043c\u0430, \u0432\u044b\u0441\u0442\u0443\u043f\u0438\u043b \u0441 \u0434\u043e\u043a\u043b\u0430\u0434\u043e\u043c \u043d\u0430 DevOpsConf 2019.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/zadelyvaem-dyry-v-klastere-kubernetes-doklad-i-rasshifrovka-s-devopsconf","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:28:25+00:00","article:modified_time":"2019-10-31T19:28:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39203","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 01:15:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:43","updated":"2026-01-24 01:15:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39203"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39203\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29423"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}