{"id":32641,"date":"2019-10-31T21:48:11","date_gmt":"2019-10-31T18:48:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\/"},"modified":"2019-10-31T21:48:11","modified_gmt":"2019-10-31T18:48:11","slug":"vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota del traduttore.<\/b>: L'autore dell'articolo, Reuven Harrison, ha oltre 20 anni di esperienza nello sviluppo software ed \u00e8 attualmente il CTO e cofondatore di Tufin, un'azienda specializzata in soluzioni per la gestione delle politiche di sicurezza. Considerando le politiche di rete di Kubernetes come uno strumento potente per la segmentazione della rete all'interno di un cluster, ritiene per\u00f2 che non siano cos\u00ec semplici da applicare nella pratica. Questo materiale (abbastanza corposo) \u00e8 destinato a migliorare la consapevolezza dei professionisti su questo argomento e ad aiutarli nella creazione delle configurazioni necessarie.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Oggi molte aziende scelgono sempre pi\u00f9 spesso Kubernetes per eseguire le proprie applicazioni. L'interesse per questo software \u00e8 cos\u00ec elevato che alcuni lo definiscono 'il nuovo sistema operativo per i data center'. Gradualmente, Kubernetes (o k8s) viene percepito come una parte fondamentale del business, richiedendo l'organizzazione di processi aziendali maturi, compresa la sicurezza di rete.<\/p>\n<p>Per i professionisti della sicurezza che sono stati sfidati dalla gestione di Kubernetes, una vera scoperta pu\u00f2 essere la politica di default di questa piattaforma: consentire tutto.<\/p>\n<p>Questa guida aiuter\u00e0 a comprendere il funzionamento delle politiche di rete; a capire come si differenziano dalle regole dei normali firewall. Saranno inoltre evidenziate alcune insidie e fornite raccomandazioni per proteggere le applicazioni in Kubernetes.<\/p>\n<h2>Politiche di rete Kubernetes<\/h2>\n<p>\nIl meccanismo delle politiche di rete Kubernetes consente di gestire le interazioni delle applicazioni distribuite sulla piattaforma a livello di rete (terzo livello nel modello OSI). Le politiche di rete non dispongono di alcune delle funzionalit\u00e0 avanzate dei moderni firewall, come il controllo al settimo livello OSI e la rilevazione delle minacce, ma forniscono un livello base di sicurezza di rete, che rappresenta un buon punto di partenza.<\/p>\n<h2>Le politiche di rete controllano le comunicazioni tra i pod.<\/h2>\n<p>\nI carichi di lavoro in Kubernetes sono distribuiti su pod, che consistono in uno o pi\u00f9 contenitori implementati insieme. Kubernetes assegna a ciascun pod un indirizzo IP, accessibile da altri pod. Le politiche di rete Kubernetes definiscono i diritti di accesso per gruppi di pod, in modo simile a come i gruppi di sicurezza nel cloud vengono utilizzati per gestire l'accesso alle istanze delle macchine virtuali.<\/p>\n<h2>Definizione delle politiche di rete<\/h2>\n<p>\nCome le altre risorse di Kubernetes, le politiche di rete sono definite nel linguaggio YAML. Nell'esempio seguente, all'applicazione <code>balance<\/code> viene concesso accesso a <code>postgres<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: balance\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Nota del traduttore.<\/b>: questo screenshot, come tutti i successivi analoghi, \u00e8 stato creato non con i mezzi nativi di Kubernetes, ma utilizzando lo strumento Tufin Orca, sviluppato dall'azienda dell'autore dell'articolo originale e menzionato alla fine del materiale.)<\/i><\/p>\n<p>Per definire una propria politica di rete, \u00e8 necessaria una conoscenza di base di YAML. Questo linguaggio si basa su rientri (definiti da spazi, non da tabulazioni). Un elemento con rientro appartiene all'elemento con rientro pi\u00f9 vicino sopra di esso. Un nuovo elemento della lista inizia con un trattino, mentre tutti gli altri elementi hanno la forma <i>chiave-valore<\/i>.<\/p>\n<p>Dopo aver descritto la politica in YAML, utilizza <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, per crearla nel cluster:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Specifiche della politica di rete<\/h2>\n<p>\nLe specifiche della politica di rete Kubernetes comprendono quattro elementi:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definisce i pod colpiti da questa politica (obiettivo) - obbligatorio;<\/li>\n<li> <code>policyTypes<\/code>: indica quali tipi di politiche sono inclusi: ingress e\/o egress \u2014 facoltativo, ma raccomando di specificarlo esplicitamente in tutti i casi;<\/li>\n<li> <code>ingress<\/code>: definisce il traffico <b>in entrata<\/b> il traffico verso i pod obiettivo - opzionale;<\/li>\n<li> <code>egress<\/code>: definisce il traffico <b>traffico in uscita<\/b> il traffico dai pod obiettivo - opzionale.<\/li>\n<\/ol>\n<p>\nUn esempio preso dal sito di Kubernetes (ho sostituito <code>role<\/code> con <code>app<\/code>), mostra come vengono utilizzati tutti e quattro gli elementi:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # &lt;&lt;&lt;&lt;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &lt;&lt;&lt;&lt;\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:         # &lt;&lt;&lt;&lt;\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi prega di notare che non \u00e8 necessario includere tutti e quattro gli elementi. Solo <code>podSelector<\/code>\u00e8 obbligatorio, gli altri parametri possono essere utilizzati a piacere.<\/p>\n<p>Se si omette <code>policyTypes<\/code>, la politica sar\u00e0 interpretata nel seguente modo:<\/p>\n<ul>\n<li> Per impostazione predefinita, si presume che definisca il lato ingress. Se non ci sono indicazioni esplicite in merito nella politica, il sistema considerer\u00e0 che tutto il traffico \u00e8 vietato.<\/li>\n<li> Il comportamento sul lato egress sar\u00e0 determinato dalla presenza o assenza del corrispondente parametro egress.<\/li>\n<\/ul>\n<p>\nPer evitare errori, consiglio di <b>specificare sempre in modo esplicito <code>policyTypes<\/code><\/b>.<\/p>\n<p>In conformit\u00e0 con la logica sopra riportata, se i parametri <code>ingress<\/code> e\/o <code>egress<\/code> sono omessi, la politica vieter\u00e0 tutto il traffico (vedere \"Regola di pulizia\" qui sotto).<\/p>\n<h2>Politica predefinita \u2014 consentire<\/h2>\n<p>\nSe non sono definite politiche, Kubernetes consente per impostazione predefinita tutto il traffico. Tutti i pod possono scambiarsi informazioni liberamente. Da un punto di vista della sicurezza, questo pu\u00f2 sembrare illogico, ma ricordiamo che Kubernetes \u00e8 stato originariamente creato dagli sviluppatori per garantire l'interazione delle applicazioni. Le politiche di rete sono state aggiunte in seguito.<\/p>\n<h2>Spazi dei nomi<\/h2>\n<p>\nGli spazi dei nomi (Namespaces) sono un meccanismo di collaborazione in Kubernetes. Sono progettati per isolare ambienti logici tra loro, consentendo per impostazione predefinita lo scambio di dati tra gli spazi.<\/p>\n<p>Come la maggior parte dei componenti di Kubernetes, le politiche di rete risiedono in uno specifico spazio dei nomi. Nel blocco <code>metadata<\/code> \u00e8 possibile specificare a quale spazio appartiene la politica:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: my-namespace  # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p>\nSe lo spazio dei nomi nei metadati non \u00e8 esplicitamente definito, il sistema utilizzer\u00e0 lo namespace specificato in kubectl (per impostazione predefinita <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nTi consiglio di <b>specificare esplicitamente lo namespace<\/b>, a meno che tu non stia scrivendo una policy destinata a pi\u00f9 spazi dei nomi.<\/p>\n<p><b>Principale<\/b> elemento <code>podSelector<\/code> nella politica verranno selezionati i pod dallo spazio dei nomi a cui appartiene la politica (non ha accesso ai pod di un altro spazio dei nomi).<\/p>\n<p>Allo stesso modo, i selettori di pod <b>nei blocchi ingress e egress<\/b> possono selezionare i pod solo dal proprio spazio dei nomi, a meno che tu non li combini tramite <code>namespaceSelector<\/code> (di cui parleremo nella sezione \"Filtro per spazi dei nomi e pod\").<\/p>\n<h2>Regole di denominazione delle policy<\/h2>\n<p>\nI nomi delle policy devono essere unici all'interno di uno spazio dei nomi. Non possono esserci due policy con lo stesso nome all'interno di uno spazio, ma possono esserci policy con nomi identici in spazi diversi. Questo \u00e8 utile quando desideri riutilizzare la stessa policy in pi\u00f9 spazi.<\/p>\n<p>Mi piace particolarmente uno dei modi di denominare. Consiste nell'unire il nome dello spazio dei nomi ai pod destinati. Ad esempio:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres  # &lt;&lt;&lt;\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etichette<\/h2>\n<p>\n\u00c8 possibile allegare etichette personalizzate a oggetti Kubernetes come pod e spazi dei nomi. Le etichette (<i>etichette<\/i> \u2014 sono l'equivalente dei tag nel cloud. Le politiche di rete di Kubernetes utilizzano le etichette per selezionare <b>pod<\/b>, a cui si applicano:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 oppure <b>spazi dei nomi<\/b>, ai quali si applicano. In questo esempio, vengono selezionati tutti i pod negli spazi dei nomi con etichette corrispondenti:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nUna avvertenza: quando si utilizza <code>namespaceSelector<\/code> <b>assicurati che gli spazi dei nomi selezionati contengano l'etichetta desiderata<\/b>. Tieni presente che gli spazi dei nomi incorporati, come <code>default<\/code> e <code>kubectl -n kube-system edit cm kubelet-config-1.16<\/code>, di default non contengono etichette.<\/p>\n<p>Puoi aggiungere un'etichetta a uno spazio dei nomi nel seguente modo:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nIn questo caso, lo spazio dei nomi nella sezione <code>metadata<\/code> deve far riferimento al nome reale dello spazio e non all'etichetta:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default   # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p><\/p>\n<h2>Fonte e destinatario<\/h2>\n<p>\nLe politiche per i firewall consistono in regole con fonti e destinazioni. Le politiche di rete Kubernetes sono definite per un obiettivo - un insieme di pod ai quali si applicano, e poi stabiliscono regole per il traffico in entrata (ingress) e\/o in uscita (egress). Nel nostro esempio, l'obiettivo della politica saranno tutti i pod nello spazio dei nomi <code>default<\/code> con etichetta con chiave <code>app<\/code> e valore <code>db<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: db   # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSezione <code>ingress<\/code> in questa politica apre il traffico in ingresso ai pod target. In altre parole, ingress funge da fonte, mentre l'obiettivo \u00e8 il corrispondente destinatario. Allo stesso modo, egress \u00e8 il destinatario, mentre l'obiettivo \u00e8 la sua fonte.<\/p>\n<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Questo \u00e8 equivalente a due regole per il firewall: Ingress \u2192 Obiettivo; Obiettivo \u2192 Egress.<\/i><\/p>\n<h2>Egress e DNS (importante!)<\/h2>\n<p>\nLimitando il traffico in uscita, <b>fai particolare attenzione a DNS<\/b> \u2014 Kubernetes utilizza questo servizio per associare i servizi agli indirizzi IP. Ad esempio, la seguente policy non funzioner\u00e0 poich\u00e9 non hai consentito all'applicazione <code>balance<\/code> di accedere al DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPuoi correggerlo consentendo l'accesso al servizio DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:               # &lt;&lt;&lt;\n    ports:            # &lt;&lt;&lt;\n    - protocol: UDP   # &lt;&lt;&lt;\n      port: 53        # &lt;&lt;&lt;\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUltimo elemento <code>to<\/code> \u2014 vuoto, e quindi seleziona indirettamente <b>tutti i pod in tutti gli spazi dei nomi<\/b>, consentendo <code>balance<\/code> di inviare richieste DNS al corrispondente servizio Kubernetes (di solito funziona nello spazio <code>kubectl -n kube-system edit cm kubelet-config-1.16<\/code>).<\/p>\n<p>Questo approccio funziona, ma <b>\u00e8 eccessivamente permissivo e insicuro<\/b>, poich\u00e9 consente di indirizzare le richieste DNS al di fuori del cluster.<\/p>\n<p>Pu\u00f2 essere migliorato in tre passaggi consecutivi.<\/p>\n<p>1. Consentire le richieste DNS solo <b>all'interno<\/b> al cluster, aggiungendo <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector: {} # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Consentire le richieste DNS solo nello spazio dei nomi <code>kubectl -n kube-system edit cm kubelet-config-1.16<\/code>.<\/p>\n<p>Per questo \u00e8 necessario aggiungere un'etichetta allo spazio dei nomi <code>kubectl -n kube-system edit cm kubelet-config-1.16<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 e specificarla nella policy usando <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector:         # &lt;&lt;&lt;\n        matchLabels:             # &lt;&lt;&lt;\n          namespace: kube-system # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. I paranoici possono andare oltre e limitare le richieste DNS a un determinato servizio DNS in <code>kubectl -n kube-system edit cm kubelet-config-1.16<\/code>. Nella sezione \"Filtro per spazi dei nomi e pod\" spiegheremo come raggiungere questo obiettivo.<\/p>\n<p>Un'altra opzione \u00e8 consentire DNS a livello di spazio dei nomi. In questo caso, non sar\u00e0 necessario aprirlo per ogni servizio:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.dns\n  namespace: default\nspec:\n  podSelector: {} # &lt;&lt;&lt;\n  egress:\n  - to:\n    - namespaceSelector: {}\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\nVuoto <code>podSelector<\/code> seleziona tutti i pod nel namespace.<\/p>\n<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Primo corrispondenza e ordine delle regole<\/h2>\n<p>\nNei normali firewall, l'azione (\u00abConsenti\u00bb o \u00abNega\u00bb) riguardante un pacchetto \u00e8 determinata dalla prima regola che soddisfa. <b>In Kubernetes, l'ordine delle politiche non ha alcun significato.<\/b><\/p>\n<p>Per impostazione predefinita, quando non sono impostate politiche, le comunicazioni tra i pod sono permesse e possono scambiarsi informazioni liberamente. Non appena inizi a definire politiche, ogni pod colpito da almeno una di esse diventa isolato in base all'unione (OR logico) di tutte le politiche che lo selezionano. I pod non colpiti da alcuna politica rimangono aperti.<\/p>\n<p>\u00c8 possibile modificare questo comportamento tramite una regola di pulizia.<\/p>\n<h2>Regola di pulizia (\u00abNega\u00bb)<\/h2>\n<p>\nLe politiche firewall normalmente negano qualsiasi traffico esplicitamente non consentito.<\/p>\n<p><b>In Kubernetes non c'\u00e8 un'azione di \u00abnegare\u00bb (deny)<\/b>, tuttavia un effetto simile pu\u00f2 essere ottenuto con una politica normale (permettente), selezionando un gruppo vuoto di pod sorgenti (ingress):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQuesta politica seleziona tutti i pod nello spazio dei nomi e lascia l'ingress non definito, vietando tutto il traffico in ingresso.<\/p>\n<p>Allo stesso modo, \u00e8 possibile limitare tutto il traffico in uscita dallo spazio dei nomi:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all-egress\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi noti che <b>qualunque politica aggiuntiva che consenta il traffico ai pod nello spazio dei nomi avr\u00e0 la priorit\u00e0 su questa regola<\/b> (similmente all'aggiunta di una regola di autorizzazione prima di una di blocco nella configurazione del firewall).<\/p>\n<h2>Consenti tutto (Any-Any-Any-Allow)<\/h2>\n<p>\nPer creare una politica di \"Consenti tutto\", \u00e8 necessario complementare la politica di blocco sopra con un elemento vuoto <code>ingress<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\n  namespace: default\nspec:\n  podSelector: {}\n  ingress: # &lt;&lt;&lt;\n  - {}     # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEssa consente l'accesso da <b>di tutti i pod in tutti gli spazi dei nomi (e di tutti gli IP) a qualunque pod nello spazio dei nomi <code>default<\/code><\/b>. Questo comportamento \u00e8 abilitato per impostazione predefinita, quindi generalmente non \u00e8 necessario definirlo ulteriormente. Tuttavia, a volte potrebbe essere necessario disabilitare temporaneamente alcune autorizzazioni specifiche per diagnosticare un problema.<\/p>\n<p>La regola pu\u00f2 essere ristretta e l'accesso consentito solo a <b>a un insieme specifico di pod<\/b> (<code>app:balance<\/code>) nello spazio dei nomi <code>default<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all-to-balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  ingress: \n  - {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa seguente policy consente tutto il traffico in ingresso (ingress) e in uscita (egress), incluso l'accesso a qualsiasi IP al di fuori del cluster:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\nspec:\n  podSelector: {}\n  ingress:\n  - {}\n  egress:\n  - {}\n  policyTypes:\n  - Ingress\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Combinazione di pi\u00f9 politiche<\/h2>\n<p>\nLe politiche si combinano utilizzando l'OR logico su tre livelli; le autorizzazioni di ogni pod sono stabilite in base all'unione di tutte le politiche che lo colpiscono:<\/p>\n<p>1. Nei campi <code>from<\/code> e <code>to<\/code> possono essere definiti tre tipi di elementi (tutti combinati tramite OR):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 seleziona interamente lo spazio dei nomi;<\/li>\n<li> <code>podSelector<\/code> \u2014 seleziona i pod;<\/li>\n<li> <code>ipBlock<\/code> \u2014 seleziona una sottorete.<\/li>\n<\/ul>\n<p>\nInoltre, il numero di elementi (anche identici) nei sottogruppi <code>from<\/code>\/<code>to<\/code> non \u00e8 limitato. Tutti saranno combinati logico OR.<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. All'interno della policy, <code>ingress<\/code> pu\u00f2 avere molti elementi <code>from<\/code> (uniti da un'operazione logica OR). Analogamente, la sezione <code>egress<\/code> pu\u00f2 includere molti elementi <code>to<\/code> (anch'essi uniti tramite disgiunzione):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Diverse policies sono unite anche tramite un'operazione logica OR<\/p>\n<p>Ma nella loro combinazione c'\u00e8 una restrizione da considerare, su cui <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">ha indicato<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: Kubernetes pu\u00f2 combinare solo policies con diversi <code>policyTypes<\/code> (<code>Ingress<\/code> o <code>Egress<\/code>). Le policies che definiscono l'ingress (o egress) si sovrascriveranno.<\/p>\n<h2>Relazione tra i namespace<\/h2>\n<p>\nPer impostazione predefinita, la comunicazione tra i namespace \u00e8 consentita. Questo pu\u00f2 essere modificato tramite una policy restrittiva, che limiter\u00e0 il traffico in uscita e\/o in entrata verso il namespace (vedi \"Regola di pulizia\" sopra).<\/p>\n<p>Bloccando l'accesso allo spazio dei nomi (vedi \u00abRegola di pulizia\u00bb sopra), puoi apportare delle eccezioni alla politica restrittiva, consentendo le connessioni da uno specifico spazio dei nomi con <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: # &lt;&lt;&lt;\n        matchLabels:\n          namespace: default\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDi conseguenza, tutti i pod nello spazio dei nomi <code>default<\/code> avr\u00e0 accesso ai pod <code>postgres<\/code> nello spazio dei nomi <code>database<\/code>. Ma cosa succede se vuoi aprire l'accesso a <code>postgres<\/code> solo a pod specifici nello spazio dei nomi <code>default<\/code>?<\/p>\n<h2>Filtro per spazi dei nomi e pod<\/h2>\n<p>\nKubernetes versione 1.11 e superiori consente di combinare operatori <code>namespaceSelector<\/code> e <code>podSelector<\/code> utilizzando l'operatore logico E. Questo appare nel seguente modo:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector:\n        matchLabels:\n          namespace: default\n      podSelector: # &lt;&lt;&lt;\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPerch\u00e9 questo viene interpretato come E invece del consueto O?<\/p>\n<p>Nota che <code>podSelector<\/code> non inizia con un trattino. In YAML questo significa che <code>podSelector<\/code> e quello che lo precede <code>namespaceSelector<\/code> appartengono allo stesso elemento della lista. Quindi vengono uniti logicamente con E.<\/p>\n<p>Aggiungere un trattino prima di <code>podSelector<\/code> porter\u00e0 alla creazione di un nuovo elemento della lista, che sar\u00e0 combinato con il precedente <code>namespaceSelector<\/code> utilizzando l'operatore logico O.<\/p>\n<p>Per selezionare pod con un'etichetta specifica <b>in tutti gli spazi dei nomi<\/b>, digita vuoto <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: {}\n      podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Le etichette multiple vengono unite con E<\/h2>\n<p>\nLe regole del firewall con pi\u00f9 oggetti (host, reti, gruppi) sono combinate usando l'operatore logico O. La seguente regola si attiver\u00e0 se la fonte del pacchetto corrisponde a <code>Host_1<\/code> OPPURE <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Fonte | Destinazione | Servizio | Azione |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Consenti  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nAl contrario, in Kubernetes le diverse etichette in <code>podSelector<\/code> o <code>namespaceSelector<\/code> sono unite logicamente con E. Ad esempio, la seguente regola selezioner\u00e0 i pod che hanno entrambe le etichette, <code>role=db<\/code> E <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nLa stessa logica si applica a tutti i tipi di operatori: selettori di obiettivi di politica, selettori di pod e selettori di spazi dei nomi.<\/p>\n<h2>Sottogruppi e indirizzi IP (IPBlocks)<\/h2>\n<p>\nPer segmentare la rete, i firewall utilizzano VLAN, indirizzi IP e sottogruppi.<\/p>\n<p>In Kubernetes, gli indirizzi IP vengono assegnati automaticamente ai pod e possono cambiare frequentemente, quindi per selezionare pod e spazi dei nomi nelle politiche di rete si utilizzano le etichette.<\/p>\n<p>Sottogruppi (<code>ipBlocks<\/code>) sono utilizzati nella gestione delle connessioni esterne (North-South) in ingresso (ingress) o in uscita (egress). Ad esempio, questa politica apre a tutti i pod dello spazio dei nomi <code>default<\/code> di accedere al servizio DNS di Google:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-dns\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 8.8.8.8\/32\n    ports:\n    - protocol: UDP\n      port: 53<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn selettore di pod vuoto in questo esempio significa \"seleziona tutti i pod nello spazio dei nomi\".<\/p>\n<p>Questa politica consente l'accesso solo a 8.8.8.8; l'accesso a qualsiasi altro IP \u00e8 vietato. Quindi, fondamentalmente, hai bloccato l'accesso al servizio DNS interno di Kubernetes. Se desideri comunque aprirlo, specifica esplicitamente.<\/p>\n<p>Di solito <code>ipBlocks<\/code> e <code>podSelectors<\/code> sono mutuamente esclusivi, poich\u00e9 gli indirizzi IP interni dei pod non sono usati in <code>ipBlocks<\/code>. Specificando <b>IP interni dei pod<\/b>, in realt\u00e0, consentirete connessioni a\/da pod con questi indirizzi. Nella pratica, non saprete quale indirizzo IP utilizzare, ecco perch\u00e9 non dovrebbero essere utilizzati per selezionare pod.<\/p>\n<p>Come controesempio, la seguente politica include tutti gli IP e quindi consente l'accesso a tutti gli altri pod:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi pu\u00f2 consentire l'accesso solo agli IP esterni, escludendo gli indirizzi IP interni dei pod. Ad esempio, se la subnet del tuo pod \u00e8 10.16.0.0\/14:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n        except:\n        - 10.16.0.0\/14<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Porte e protocolli<\/h2>\n<p>\nDi solito, i pod ascoltano una sola porta. Ci\u00f2 significa che \u00e8 possibile semplicemente non specificare i numeri di porta nelle politiche e lasciare tutto predefinito. Tuttavia, \u00e8 consigliato rendere le politiche il pi\u00f9 restrittive possibile, quindi in alcuni casi \u00e8 comunque possibile specificare le porte:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:\n      - port: 443\n        protocol: TCP\n      - port: 80\n        protocol: TCP\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi noti che il selettore <code>ports<\/code> si applica a tutti gli elementi nel blocco <code>to<\/code> o <code>from<\/code>, in cui \u00e8 contenuto. Per specificare porte diverse per diversi set di elementi, suddividi <code>ingress<\/code> o <code>egress<\/code> in pi\u00f9 sezioni con <code>to<\/code> o <code>from<\/code> e in ciascuna specifica le tue porte:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    ports:\n     - port: 443\n       protocol: TCP\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:\n     - port: 80\n       protocol: TCP\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFunzionamento delle porte predefinite:<\/p>\n<ul>\n<li> Se salti completamente la definizione delle porte (<code>ports<\/code>), ci\u00f2 significa tutti i protocolli e tutte le porte;<\/li>\n<li> Se salti la definizione del protocollo (<code>protocol<\/code>), ci\u00f2 significa TCP;<\/li>\n<li> Se salti la definizione della porta (<code>porto<\/code>), ci\u00f2 significa tutte le porte.<\/li>\n<\/ul>\n<p>\nPratica migliore: non fare affidamento sui valori predefiniti, specifica chiaramente ci\u00f2 di cui hai bisogno.<\/p>\n<p>Si prega di notare che \u00e8 necessario utilizzare le porte dei pod e non dei servizi (maggiori dettagli nel paragrafo seguente).<\/p>\n<h2>Le politiche sono definite per i pod o per i servizi?<\/h2>\n<p>\nDi solito, i pod in Kubernetes comunicano tra loro tramite un servizio: un bilanciatore di carico virtuale che reindirizza il traffico ai pod che implementano il servizio. Si potrebbe pensare che le politiche di rete controllino l'accesso ai servizi, ma non \u00e8 cos\u00ec. <b>Le politiche di rete di Kubernetes lavorano con le porte dei pod, e non dei servizi.<\/b><\/p>\n<p>Ad esempio, se un servizio ascolta sulla porta 80, ma reindirizza il traffico alla porta 8080 dei suoi pod, nella politica di rete \u00e8 necessario specificare proprio la 8080.<\/p>\n<p>Un meccanismo simile deve essere considerato subottimale: al variare della configurazione interna del servizio (le porte a cui ascoltano i pod) sar\u00e0 necessario aggiornare le politiche di rete.<\/p>\n<p>Un nuovo approccio architetturale utilizzando il Service Mesh <i>(ad esempio, vedi Istio qui sotto \u2014 nota del traduttore)<\/i> pu\u00f2 affrontare questo problema.<\/p>\n<h2>\u00c8 necessario specificare sia Ingress che Egress?<\/h2>\n<p>\nLa risposta breve \u00e8 s\u00ec: affinch\u00e9 il pod A possa comunicare con il pod B, \u00e8 necessario consentirgli di stabilire una connessione in uscita (per questo bisogna configurare la policy di egress), e il pod B deve poter accettare una connessione in entrata (per questo \u00e8 necessaria una policy di ingress).<\/p>\n<p>Tuttavia, nella pratica si pu\u00f2 fare affidamento sulla policy predefinita che consente connessioni in una o entrambe le direzioni.<\/p>\n<p>Se un certo pod<b>fonte<\/b> viene selezionato da una o pi\u00f9 <b>egress<\/b>-policy, i vincoli applicabili saranno definiti dalla loro disgiunzione. In questo caso, sar\u00e0 necessario autorizzare esplicitamente la connessione al pod<b>destinatario<\/b>. Se un pod non \u00e8 selezionato da alcuna policy, il suo traffico in uscita (egress) \u00e8 autorizzato per impostazione predefinita.<\/p>\n<p>Analogamente, il destino del pod sar\u00e0 determinato dalla disgiunzione delle politiche. In tal caso, sar\u00e0 necessario esplicitamente consentire di ricevere traffico dal pod sorgente. Se il pod non \u00e8 scelto da alcuna politica, tutto il traffico in ingresso (ingress) per esso \u00e8 consentito per impostazione predefinita.<b>destinatario<\/b>, selezionato da una o pi\u00f9 <b>ingress<\/b>Esempi di politiche di rete, preparati da Ahmet Alp Balkan di GKE.<\/p>\n<p>Vedi la sezione \"Stateful o Stateless\" qui sotto.<\/p>\n<h2>Log<\/h2>\n<p>\nLe policy di rete di Kubernetes non registrano il traffico. Ci\u00f2 rende difficile determinare se la policy funzioni correttamente e complica notevolmente l'analisi della sicurezza.<\/p>\n<h2>Monitoraggio del traffico verso i servizi esterni<\/h2>\n<p>\nLe policy di rete di Kubernetes non consentono di specificare un nome di dominio completo (DNS) nelle sezioni egress. Questo comporta notevoli disagi nel tentativo di limitare il traffico verso indirizzi esterni privi di un IP fisso (come aws.com).<\/p>\n<h2>Verifica della policy<\/h2>\n<p>\nI firewall ti avviseranno o potrebbero persino rifiutarsi di accettare una policy errata. Anche Kubernetes compie alcune verifiche. Quando si imposta una policy di rete tramite kubectl, Kubernetes pu\u00f2 dichiarare che \u00e8 errata e rifiutarsi di accettarla. In altri casi, Kubernetes accetter\u00e0 la policy e la completer\u00e0 con dettagli mancanti. Questi possono essere visualizzati con il comando:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nTieni presente che il sistema di verifica di Kubernetes non \u00e8 infallibile e potrebbe trascurare alcuni tipi di errori.<\/p>\n<h2>Esecuzione<\/h2>\n<p>\nKubernetes non gestisce autonomamente l'implementazione delle politiche di rete, fungendo invece da gateway API, trasferendo il compito oneroso di controllo al sistema sottostante noto come Container Networking Interface (CNI). Impostare politiche all'interno di un cluster Kubernetes senza assegnare il corrispondente CNI \u00e8 paragonabile a creare politiche su un server di gestione del firewall senza successivamente applicarle ai firewall. Devi assicurarti di avere un CNI adeguato o, nel caso delle piattaforme Kubernetes ospitate nel cloud <i>(puoi trovare l'elenco dei fornitori <noindex>qui<\/noindex> \u2014 nota del traduttore)<\/i>, implementare politiche di rete che installeranno il CNI per te.<\/p>\n<p>Si prega di notare che Kubernetes non ti avviser\u00e0 se imposti una politica di rete senza un adeguato CNI ausiliario.<\/p>\n<h3>Stateful o Stateless?<\/h3>\n<p>\nTutti i CNI di Kubernetes che ho incontrato gestiscono stati (ad esempio, Calico utilizza Linux conntrack). Questo consente al pod di ricevere risposte per una connessione TCP che ha avviato senza doverla stabilire nuovamente. Tuttavia, non sono a conoscenza di uno standard Kubernetes che garantisca la gestione dello stato (statefulness).<\/p>\n<h2>Gestione avanzata della sicurezza<\/h2>\n<p>\nEcco alcuni modi per migliorare l'efficacia della politica di sicurezza in Kubernetes:<\/p>\n<ol>\n<li> Il pattern architettonico Service Mesh utilizza contenitori sidecar per garantire telemetria dettagliata e controllo del traffico a livello di servizi. Un esempio \u00e8 <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Alcuni fornitori di CNI hanno ampliato i loro strumenti per andare oltre le politiche di rete di Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> fornisce trasparenza e automazione delle politiche di rete di Kubernetes.<\/li>\n<\/ol>\n<p>\nIl pacchetto Tufin Orca gestisce le politiche di rete di Kubernetes (e funge da fonte per gli screenshot sopra).<\/p>\n<h2>Informazioni aggiuntive<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Esempi di politiche di rete preparati da Ahmet Alp Balkan di GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documentazione dal sito ufficiale di Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Guida al modello di rete di Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script per verificare le politiche di rete<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusione<\/h2>\n<p>\nLe politiche di rete di Kubernetes offrono una buona gamma di strumenti per la segmentazione dei cluster, ma risultano spesso poco intuitive e presentano molte complessit\u00e0. Credo che a causa di questa difficolt\u00e0, molte politiche dei cluster esistenti siano errate. Le possibili soluzioni a questo problema includono l'automazione delle definizioni delle politiche o l'uso di altri strumenti di segmentazione.<\/p>\n<p>Spero che questa guida possa chiarire alcuni dubbi e risolvere i problemi che potresti incontrare.<\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggete anche nel nostro blog:<\/p>\n<ul>\n<li> \u00abTornare ai microservizi con Istio\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">parte 1 (introduzione alle funzionalit\u00e0 principali)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">parte 2 (routing, gestione del traffico)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">parte 3 (sicurezza)<\/a><\/noindex>;<\/li>\n<li> \u00abGuida illustrata alla rete in Kubernetes\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">parti 1 e 2 (modello di rete, reti overlay)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">parte 3 (servizi e gestione del traffico)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker e Kubernetes in ambienti ad alta sicurezza<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 migliori pratiche per garantire la sicurezza in Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 modi per (non) diventare vittime di hacking in Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443190\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0410\u0432\u0442\u043e\u0440 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 Reuven Harrison \u2014 \u0438\u043c\u0435\u0435\u0442 \u0431\u043e\u043b\u0435\u0435 20 \u043b\u0435\u0442 \u043e\u043f\u044b\u0442\u0430 \u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, \u0430 \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u043e\u043c \u0438 \u0441\u043e\u0443\u0447\u0440\u0435\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Tufin, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0435\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u043b\u044f \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0430\u043c\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043c\u043e\u0449\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0441\u0435\u0442\u0438 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435, \u043e\u043d \u0432 \u0442\u043e \u0436\u0435 \u0432\u0440\u0435\u043c\u044f \u0441\u0447\u0438\u0442\u0430\u0435\u0442, \u0447\u0442\u043e \u043e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24432,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32641","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 Introduzione alle politiche di rete di Kubernetes per esperti di sicurezza | ProHoster","description":"Nota","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","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\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","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-31T18:48:11+00:00","article:modified_time":"2019-10-31T18:48:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32641","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-21 11:53:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:55:23","updated":"2026-01-21 11:53: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\/32641","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=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}