{"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":"Riempiamo le lacune nel cluster Kubernetes. Relazione e trascrizione da DevOpsConf","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Pavel Selivanov, architetto di soluzioni per Southbridge e docente di Slyrma, ha presentato una relazione al DevOpsConf 2019. Questa relazione \u00e8 parte di uno dei temi del corso avanzato su Kubernetes \"Slyrma Mega\".<\/p>\n

<\/p>\n

Slyrma Base: introduzione a Kubernetes<\/a><\/noindex> si svolge a Mosca dal 18 al 20 novembre.
\nSlyrma Mega: uno sguardo dentro Kubernetes<\/a><\/noindex> \u2014 Mosca, dal 22 al 24 novembre.
\nSlyrma Online: entrambi i corsi su Kubernetes<\/a><\/noindex> disponibile sempre.<\/p>\n

\n

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

Di seguito \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 in sala ci sono molti esperti di sicurezza. Mi scuso in anticipo se utilizzer\u00f2 termini del mondo della sicurezza in modo non del tutto conforme alle vostre consuetudini. <\/p>\n

<\/p>\n

Circa sei mesi fa, mi \u00e8 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. <\/p>\n

<\/p>\n

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. <\/p>\n

<\/p>\n

Sono arrivato in questo cluster. Mi hanno dato diritti limitati e un namespace limitato. L\u00ec le persone capivano cosa significasse la sicurezza. Leggevano cosa fosse il controllo degli accessi basato sui ruoli (RBAC) in Kubernetes \u2014 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\u00f2 cosa \u00e8 stato configurato in modo errato nel loro RBAC. <\/p>\n

<\/p>\n

Cos\u00ec \u00e8 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\u00e0 acquistato il servizio e si erano deployate. Ho fatto fatica a fermarmi dal non andare da qualcuno e non inserire parolacce nella homepage. <\/p>\n

<\/p>\n

Racconter\u00f2 con esempi come ho fatto e come bisogna difendersi da questo. <\/p>\n

<\/p>\n

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. <\/p>\n

<\/p>\n

Oltre alla nostra attivit\u00e0 principale, di recente abbiamo lanciato un progetto chiamato Sl\u00ebrmy. Cerchiamo di portare le nostre competenze in Kubernetes al grande pubblico, insegnando ad altre persone come lavorare con K8s. <\/p>\n

<\/p>\n

Di cosa parler\u00f2 oggi. Il tema della presentazione \u00e8 chiaro: la sicurezza del cluster Kubernetes. Ma voglio subito sottolineare che questo argomento \u00e8 molto ampio e, quindi, devo specificare che non parler\u00f2 di alcune cose. Non discuter\u00f2 termini abusati, che sono gi\u00e0 stati ripetuti cento volte su Internet, come RBAC e certificati. <\/p>\n

<\/p>\n

Parler\u00f2 di ci\u00f2 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\u00e0, l'ampiezza della tragedia \u00e8 davvero grande. <\/p>\n

<\/p>\n

In effetti, ci sono 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 che dal cluster \u00e8 possibile raccogliere tutte le informazioni necessarie senza avere diritti particolari in esso. <\/li>\n
  3. Attacco DoS al cluster. Se non possiamo raccogliere informazioni, possiamo comunque mettere il cluster fuori uso. Parler\u00f2 degli attacchi DoS agli elementi di gestione del cluster. <\/li>\n<\/ol>\n

    <\/p>\n

    Un'altra cosa comune che menzioner\u00f2 \u00e8 su cosa ho testato tutto ci\u00f2, su cosa posso affermare con certezza che funziona.<\/p>\n

    <\/p>\n

    La base del nostro lavoro \u00e8 l'installazione del cluster Kubernetes tramite Kubespray. Se qualcuno non lo sa, \u00e8 fondamentalmente un insieme di ruoli per Ansible. Lo utilizziamo continuamente. \u00c8 utile perch\u00e9 pu\u00f2 essere applicato ovunque: sia su hardware che nel cloud. Un modo di installazione \u00e8 adatto praticamente per tutto. <\/p>\n

    <\/p>\n

    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. <\/p>\n

    <\/p>\n

    \"Riempiamo<\/p>\n

    <\/p>\n

    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. <\/p>\n

    <\/p>\n

    kubectl apply -f pod.yaml<\/code><\/pre>\n
    <\/p>\n
    This 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. <\/p>\n
    <\/p>\n
    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. <\/p>\n
    <\/p>\n
    Ora parliamo del pod appositamente preparato. Possiamo avviarlo su qualsiasi immagine. Per esempio, prendiamo debian:jessie. <\/p>\n
    <\/p>\n
    Abbiamo una cosa del genere: <\/p>\n
    <\/p>\n
    tolerations:\n-   effect: NoSchedule \n    operator: Exists \nnodeSelector: \n    node-role.kubernetes.io\/master: \"\" <\/code><\/pre>\n
    <\/p>\n
    Che cos'\u00e8 la toleration? I nodi master nel cluster Kubernetes sono solitamente contrassegnati da qualcosa chiamato taint. E la sostanza di questo taint \u00e8 che non \u00e8 possibile assegnare pod ai nodi master. Ma niente vieta di specificare in qualsiasi pod che \u00e8 tollerante a questo taint. La sezione Toleration indica proprio che se un nodo ha NoSchedule, il nostro pod \u00e8 tollerante a quel taint \u2014 e non ci sono problemi. <\/p>\n
    <\/p>\n
    Inoltre, diciamo che il nostro pod non \u00e8 solo tollerante, ma desidera specialmente trovarsi sui master. Perch\u00e9 sui master si trova la cosa pi\u00f9 preziosa di cui abbiamo bisogno: tutti i certificati. Pertanto, specifichiamo nodeSelector \u2014 e abbiamo un'etichetta standard sui master che consente di selezionare i nodi master da tutti i nodi del cluster. <\/p>\n
    <\/p>\n
    Con queste due sezioni, il pod verr\u00e0 sicuramente assegnato al master. E gli sar\u00e0 permesso di viverci. <\/p>\n
    <\/p>\n
    Ma semplicemente venire al master non \u00e8 sufficiente. Non ci dar\u00e0 niente. Quindi abbiamo due elementi da considerare:<\/p>\n
    <\/p>\n
    hostNetwork: true \nhostPID: true <\/code><\/pre>\n
    <\/p>\n
    Indichiamo che il nostro pod, che stiamo eseguendo, operer\u00e0 nello spazio dei nomi del kernel, nello spazio dei nomi di rete e nello spazio dei nomi PID. Una volta che il pod sar\u00e0 avviato sul master, potr\u00e0 vedere tutte le interfacce reali e attive di questo nodo, intercettare tutto il traffico e visualizzare i PID di tutti i processi.<\/p>\n
    <\/p>\n
    Dopo di che, \u00e8 semplice. Prendi etcd e leggi ci\u00f2 che desideri. <\/p>\n
    <\/p>\n
    La cosa pi\u00f9 interessante \u00e8 che questa \u00e8 una possibilit\u00e0 di Kubernetes, che \u00e8 presente per 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 sua essenza \u00e8 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 \u2014 e usarlo come volume. E poi lo chiamiamo name: host. Montiamo tutto questo hostPath all'interno del pod. In questo esempio, nella directory \/host. <\/p>\n
    <\/p>\n
    Ripeto. Abbiamo detto al pod di venire al master, ottenere hostNetwork e hostPID \u2014 e montare l'intero root del master all'interno di questo pod. <\/p>\n
    <\/p>\n
    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.<\/p>\n
    <\/p>\n
    Il compito successivo \u00e8 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. <\/p>\n
    <\/p>\n
    Se ci si pensa, questi sono alcuni dei diritti pi\u00f9 pericolosi all'interno dei pod \u2014 indipendentemente dai diritti dell'utente:
    \n\"Riempiamo<\/p>\n
    <\/p>\n
    Se ho il permesso di lanciare un pod in un certo namespace del cluster, quel pod avr\u00e0 questi permessi per impostazione predefinita. Posso eseguire pod privilegiati, che praticamente equivalgono a diritti di root sulla node. <\/p>\n
    <\/p>\n
    Il mio preferito \u00e8 l'utente Root. Kubernetes ha l'opzione Run As Non-Root. \u00c8 una sorta di protezione contro gli hacker. Sapete cos'\u00e8 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\u00e0 molto facile per te hackare il sistema. Proteggiti, per favore, da te stesso\". <\/p>\n
    <\/p>\n
    Il volume dell'host path \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 normale amministratore che si confronta con Kubernetes: \"Aha, lo sapevo, Kubernetes non funziona. Ha delle falle. E tutto il resto \u00e8 spazzatura\". In realt\u00e0, c'\u00e8 qualcosa chiamato documentazione, e se la si consulta, c'\u00e8 una sezione Pod Security Policy<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    Questo \u00e8 un oggetto yaml \u2014 possiamo crearlo nel cluster di Kubernetes \u2014 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\u00f2 essere descritto. <\/p>\n
    <\/p>\n
    La cosa pi\u00f9 interessante della Pod Security Policy \u00e8 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.<\/p>\n
    <\/p>\n
    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\u00e9 \u00e8 molto probabile che gli sviluppatori non abbiano bisogno di eseguire pod privilegiati nel vostro cluster. <\/p>\n
    <\/p>\n
    E sembra che tutto vada bene. E il nostro cluster Kubernetes non pu\u00f2 essere compromesso in due minuti. <\/p>\n
    <\/p>\n
    C'\u00e8 un problema. \u00c8 molto probabile che, se avete un cluster Kubernetes, abbia un sistema di monitoraggio installato. Mi prendo anche la libert\u00e0 di prevedere che, se nel vostro cluster \u00e8 presente un sistema di monitoraggio, si chiama Prometheus. <\/p>\n
    <\/p>\n
    Quello che sto per raccontare \u00e8 valido sia per l'operatore Prometheus sia per Prometheus installato in modo tradizionale. Il punto \u00e8 che se non riesco a ottenere rapidamente un amministratore nel cluster, significa che devo cercare di pi\u00f9. E posso cercare utilizzando la vostra monitorizzazione.<\/p>\n
    <\/p>\n
    Probabilmente tutti hanno letto gli stessi articoli su Habr\u00e9, 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 \u00e8 probabile che non dovr\u00f2 nemmeno indovinare il nome DNS nel vostro cluster. Perch\u00e9 \u00e8 standard. <\/p>\n
    <\/p>\n
    \"Riempiamo<\/p>\n
    <\/p>\n
    Successivamente, abbiamo un certo dev ns, dove \u00e8 possibile avviare un pod. E poi, da questo pod, \u00e8 molto semplice 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 ci\u00f2 che \u00e8 in esecuzione nel vostro cluster, com'\u00e8, quali problemi avete con esso. <\/p>\n
    <\/p>\n
    Un esempio semplice: <\/p>\n
    <\/p>\n
    kube_pod_container_info{namespace=\u00abkube-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:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker:\/\/7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1 <\/p>\n
    <\/p>\n
    Eseguendo una semplice richiesta curl da un pod non privilegiato, \u00e8 possibile ottenere queste informazioni. Se non sai quale versione di Kubernetes stai utilizzando, te lo dir\u00e0 facilmente. <\/p>\n
    <\/p>\n
    E la cosa pi\u00f9 interessante \u00e8 che, oltre a interagire con kube-state-metrics, puoi altrettanto facilmente rivolgerti direttamente a Prometheus. Puoi raccogliere le metriche da l\u00ec. Puoi persino generare metriche. Teoricamente, puoi costruire una richiesta da un cluster a Prometheus che lo spenga semplicemente. E il tuo monitoraggio smetter\u00e0 di funzionare del tutto. <\/p>\n
    <\/p>\n
    A questo punto sorge la domanda se qualche monitoraggio esterno stia monitorando il tuo monitoraggio. Poco fa ho avuto la possibilit\u00e0 di operare nel cluster Kubernetes senza conseguenze per me. Non scopriresti nemmeno che sto operando l\u00ec, poich\u00e9 il monitoraggio non esiste gi\u00e0 pi\u00f9. <\/p>\n
    <\/p>\n
    Proprio come con il PSP, si ha l'impressione che il problema sia che tutte queste tecnologie moderne \u2014 Kubernetes, Prometheus \u2014 semplicemente non funzionano e sono piene di falle. In realt\u00e0, non \u00e8 cos\u00ec. <\/p>\n
    <\/p>\n
    C'\u00e8 una cosa \u2014 Network Policy<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    Se sei un amministratore normale, probabilmente sai che la Network Policy \u00e8 un altro yaml, di cui ce ne sono gi\u00e0 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 \u00e8 solo un'ulteriore astrazione... No, no. Non \u00e8 affatto necessario. <\/p>\n
    <\/p>\n
    Anche se ai tuoi esperti di sicurezza non \u00e8 stato detto che con il tuo Kubernetes si pu\u00f2 costruire facilmente un firewall, e tra l'altro molto granulare. Se non ne sono ancora a conoscenza e non ti cercano: \u00abDai, dai...\u00bb 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. <\/p>\n
    <\/p>\n
    Come nell'esempio che ho fornito, \u00e8 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\u00ec via: senza accesso, senza problemi. In tutti i chart disponibili, sia quello standard di Prometheus che quello dell'operatore, c'\u00e8 semplicemente l'opzione nel values di Helm per abilitare le politiche di rete. Basta attivarlo e funzioneranno. <\/p>\n
    <\/p>\n
    Qui c'\u00e8 per\u00f2 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\u00e0 host-gateway, sia la scelta migliore che puoi fare. <\/p>\n
    <\/p>\n
    Cosa fare? <\/p>\n
    <\/p>\n
    Puoi provare a ripristinare la soluzione di rete presente nel tuo cluster Kubernetes, sostituendola con qualcosa di pi\u00f9 funzionale, come ad esempio Calico. Tuttavia, voglio dirti subito che cambiare la soluzione di rete in un cluster Kubernetes attivo \u00e8 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. <\/p>\n
    <\/p>\n
    Il problema si risolve in realt\u00e0 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 \u00e8: perch\u00e9 preoccuparsi? Creiamo un nuovo cluster accanto, lasciamo che quello vecchio scada, e poi deploziamo tutto l\u00ec. Certo, quando scadr\u00e0, ci sederemo per un giorno senza nulla, ma avremo comunque un nuovo cluster. <\/p>\n
    <\/p>\n
    Quando avrai avviato 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 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. <\/p>\n
    <\/p>\n
    C'\u00e8 un problema, per\u00f2. In passato, la soluzione Kube-RBAC-Proxy era integrata nell'operatore Prometheus. Ma poi \u00e8 stata rimossa. Le versioni moderne si basano sul fatto che abbiate una policy di rete e le chiudiate tramite essa. Pertanto, sar\u00e0 necessario riscrivere un po' il chart. In realt\u00e0, se andate in questo repository<\/a><\/noindex>, troverete degli esempi su come utilizzarlo come sidecar, e sar\u00e0 necessario riscrivere il chart con il minimo sforzo. <\/p>\n
    <\/p>\n
    C'\u00e8 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. <\/p>\n
    <\/p>\n
    Ma come ho gi\u00e0 detto, se non puoi accedere al cluster e raccogliere informazioni, puoi almeno causare danni. <\/p>\n
    <\/p>\n
    Quindi, vi mostrer\u00f2 rapidamente due modi per compromettere la salute di un cluster Kubernetes. <\/p>\n
    <\/p>\n
    Riderete quando ve lo racconter\u00f2, 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 questa sezione. <\/p>\n
    <\/p>\n
    risorse: \n    richieste: \n        cpu: 4 \n        memoria: 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 a quattro core nel cluster Kubernetes, e arriva un pod con richieste di quattro CPU, allora non potr\u00e0 arrivare nessun altro pod con richieste su questo host. <\/p>\n
    <\/p>\n
    Se avvio un tale pod, poi far\u00f2 il comando: <\/p>\n
    <\/p>\n
    $ kubectl scale special-pod --replicas=...<\/code><\/pre>\n
    <\/p>\n
    Nessun altro potr\u00e0 quindi essere distribuito nel cluster Kubernetes. Perch\u00e9 tutte le nodi finiranno le richieste. In questo modo fermer\u00f2 il vostro cluster Kubernetes. Se lo faccio stasera, potrei fermare i deploy per un bel po' di tempo. <\/p>\n
    <\/p>\n
    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.<\/p>\n
    <\/p>\n
    Con questo strumento possiamo limitare gli utenti in specifici namespace di prodotto riguardo alle possibilit\u00e0 di specificare sui propri pod cose inadeguate. Ma sfortunatamente, anche se dici all'utente che non pu\u00f2 avviare pod con richieste superiori a una CPU, c'\u00e8 un fantastico comando di scale, oppure attraverso il dashboard possono comunque eseguire lo scale.<\/p>\n
    <\/p>\n
    E da qui deriva il secondo metodo. Avviamo 11 111 111 111 111 pod. Sono undici miliardi. Non \u00e8 perch\u00e9 ho inventato questo numero, ma perch\u00e9 l'ho visto io stesso. <\/p>\n
    <\/p>\n
    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 \u00e8 successo?\"<\/p>\n
    <\/p>\n
    Poco prima, intorno alle nove di sera, uno degli sviluppatori stava per andare a casa. Pens\u00f2: \u00abOra scaler\u00f2 la mia applicazione fino a un'unit\u00e0\u00bb. Premette uno, ma Internet rallent\u00f2 un po'. Premette di nuovo uno, schiacci\u00f2 di nuovo uno e clicc\u00f2 su Enter. Provo a premere tutto ci\u00f2 che poteva. Poi, Internet riprese a funzionare \u2014 e tutto inizi\u00f2 a scalare fino a quel numero. <\/p>\n
    <\/p>\n
    In realt\u00e0, questa storia non si svolgeva su Kubernetes, ma su Nomad. Fin\u00ec 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. \u00abSono stanco, me ne vado\u00bb. E si ritir\u00f2. <\/p>\n
    <\/p>\n
    Naturalmente provai a fare lo stesso su Kubernetes. Undici miliardi di pod di Kubernetes non furono d'aiuto, disse: \u00abNon posso. Supera i limiti interni\u00bb. Ma con 1 000 000 000 di pod, ci riusc\u00ec. <\/p>\n
    <\/p>\n
    In risposta a un miliardo, Kubernetes non ha smesso di funzionare. Ha davvero iniziato a scalare. Pi\u00f9 il processo andava avanti, pi\u00f9 tempo richiedeva per creare nuovi pod. Ma il processo continuava comunque. L'unico problema \u00e8 che, se posso avviare pod senza limiti nel mio namespace, anche senza richieste e limiti, posso avviare cos\u00ec tanti pod con alcune attivit\u00e0 che le nodi iniziano a sovraccaricarsi di memoria e CPU. Quando avvio cos\u00ec tanti pod, le informazioni devono essere archiviate, cio\u00e8 in etcd. E quando troppe informazioni arrivano l\u00ec, lo storage inizia a restituire i dati troppo lentamente, e Kubernetes ha dei rallentamenti. <\/p>\n
    <\/p>\n
    E un altro problema... Come sapete, i controllori di Kubernetes non sono un'unica entit\u00e0 centrale, ma diversi componenti. Ci sono, in particolare, un controller manager, uno scheduler e cos\u00ec via. Tutti questi elementi inizieranno a svolgere contemporaneamente compiti inutili e poco efficaci, che nel tempo richiederanno sempre pi\u00f9 tempo. Il controller manager creer\u00e0 nuovi pod. Lo scheduler cercher\u00e0 di trovare un nuovo nodo per loro. Probabilmente, presto avrete esaurito i nuovi nodi nel vostro cluster. Il cluster Kubernetes inizier\u00e0 a funzionare sempre pi\u00f9 lentamente.<\/p>\n
    <\/p>\n
    Ma ho deciso di andare oltre. Come sapete, in Kubernetes c'\u00e8 una cosa chiamata servizio. E, per impostazione predefinita, nei vostri cluster, il servizio funziona probabilmente tramite IP tables. <\/p>\n
    <\/p>\n
    Se si avvia un miliardo di pod, per esempio, e poi si usa uno script per costringere 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 generate quasi simultaneamente nuove regole iptables. Inoltre, per ogni servizio verranno generate un miliardo di regole iptables. <\/p>\n
    <\/p>\n
    Ho testato tutto questo su alcune migliaia, fino a un massimo di dieci. E il problema \u00e8 che gi\u00e0 a questo livello \u00e8 piuttosto complicato fare SSH su un nodo. Perch\u00e9 i pacchetti, passando attraverso un numero cos\u00ec elevato di catene, iniziano a comportarsi in modo non ottimale. <\/p>\n
    <\/p>\n
    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 \u00e8 assegnato un certo numero di richieste e limiti, e poi possiamo dire che in questo spazio dei nomi \u00e8 possibile creare 10 servizi e 10 pod. E lo sviluppatore pu\u00f2 anche lavorare serenamente la sera. Kubernetes gli dir\u00e0: \"Non puoi scalare i tuoi pod a tale quantit\u00e0, perch\u00e9 supera la quota delle risorse.\" Ecco, il problema \u00e8 risolto. Documentazione qui<\/a><\/noindex>.<\/p>\n
    <\/p>\n
    C'\u00e8 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.<\/p>\n
    <\/p>\n
    Quota risorse + Limite di intervallo + RBAC
    \n\u2022 Creiamo un namespace
    \n\u2022 Creiamo un limitrange al suo interno
    \n\u2022 Creiamo una resourcequota al suo interno
    \n\u2022 Creiamo un serviceaccount per CI
    \n\u2022 Creiamo un rolebinding per CI e gli utenti
    \n\u2022 Facoltativamente avviamo i pod di servizio necessari <\/p>\n
    <\/p>\n
    Colgo l'occasione per condividere i miei sviluppi. C'\u00e8 uno strumento chiamato operatore SDK. Questo \u00e8 un modo per scrivere operatori nel cluster Kubernetes. Puoi scrivere operatori usando Ansible.<\/p>\n
    <\/p>\n
    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\u00f2 descrivere in yaml l'ambiente per questo comando. E all'interno dell'ambiente del comando, permette di specificare quali risorse vengono allocate. <\/p>\n
    <\/p>\n
    Piccola semplificazione di tutto questo complicato processo<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    E in conclusione. Cosa fare con tutto questo?
    \nPrimo. La Pod Security Policy \u00e8 utile. E nonostante nessuno degli installatori di Kubernetes le utilizzi ancora, \u00e8 comunque necessario adottarle nei vostri cluster. <\/p>\n
    <\/p>\n
    La Network Policy non \u00e8 un'altra funzionalit\u00e0 superflua. \u00c8 qualcosa di veramente necessario nel cluster. <\/p>\n
    <\/p>\n
    LimitRange\/ResourceQuota \u2014 \u00e8 ora di utilizzarle. Le abbiamo adottate da tempo, e pensavo che fosse una prassi comune. Si \u00e8 rivelato essere piuttosto raro. <\/p>\n
    <\/p>\n
    Oltre a quanto menzionato durante la presentazione, ci sono funzionalit\u00e0 non documentate che consentono di attaccare il cluster. Recentemente \u00e8 stata pubblicata una grande analisi delle vulnerabilit\u00e0 di Kubernetes.<\/a><\/noindex>. <\/p>\n
    <\/p>\n
    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. <\/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 che mostrano come appaiono ResourceQuota e Pod Security Policy. E tutto questo pu\u00f2 essere esplorato. <\/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\udd47Riparare le falle nel cluster Kubernetes. Presentazione e trascrizione da DevOpsConf | ProHoster","description":"Pavel Selivanov, architetto di soluzioni per Southbridge e docente presso Slurm, ha presentato una relazione al DevOpsConf 2019. Questa relazione \u00e8 parte di uno dei temi del corso avanzato su Kubernetes \"Slurm Mega\". Slurm Base: introduzione a Kubernetes si svolge a Mosca dal 18 al 20 novembre. Slurm Mega: un'occhiata sotto il cofano di Kubernetes \u2014 Mosca, dal 22 al 24 novembre. Slurm Online: entrambi i corsi su Kubernetes sono sempre disponibili.","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. \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.","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"},"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}]}}