{"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 specialisti della sicurezza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota di traduzione.<\/b>: L'autore dell'articolo, Reuven Harrison, ha oltre 20 anni di esperienza nello sviluppo di software ed \u00e8 attualmente il direttore tecnico e cofondatore di Tufin, che crea soluzioni per la gestione delle politiche di sicurezza. Considerando le politiche di rete di Kubernetes come uno strumento piuttosto potente per la segmentazione della rete nel cluster, crede anche che non siano cos\u00ec facili da implementare nella pratica. Questo materiale (piuttosto voluminoso) \u00e8 progettato per migliorare la consapevolezza dei professionisti su questo tema e 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 l'esecuzione delle proprie applicazioni. L'interesse per questo software \u00e8 cos\u00ec alto che alcuni lo definiscono \"il nuovo sistema operativo per i data center\". Gradualmente, Kubernetes (o k8s) inizia a essere percepito come una parte critica del business, che richiede l'organizzazione di processi aziendali maturi, incluso il mantenimento della sicurezza di rete.<\/p>\n<p>Per i professionisti della sicurezza, che sono stati messi in difficolt\u00e0 dal lavoro con Kubernetes, potrebbe essere una vera e propria scoperta la politica predefinita di questa piattaforma: consentire tutto.<\/p>\n<p>Questa guida aiuter\u00e0 a comprendere il funzionamento interno delle politiche di rete e a capire come si differenziano dalle regole per i normali firewall. Saranno anche menzionate alcune insidie e fornite raccomandazioni che aiuteranno a proteggere le applicazioni su Kubernetes.<\/p>\n<h2>Politiche di rete di Kubernetes<\/h2>\n<p>\nIl meccanismo delle politiche di rete di Kubernetes consente di gestire l'interazione delle applicazioni distribuite sulla piattaforma a livello di rete (il terzo nella modellazione OSI). Le politiche di rete mancano di alcune funzionalit\u00e0 avanzate dei firewall moderni, come il controllo di livello 7 OSI e la rilevazione delle minacce, tuttavia 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 container distribuiti insieme. Kubernetes assegna a ogni pod un indirizzo IP accessibile da altri pod. Le politiche di rete di Kubernetes definiscono i diritti di accesso per gruppi di pod proprio come i gruppi di sicurezza nel cloud vengono utilizzati per gestire l'accesso alle istanze di macchine virtuali.<\/p>\n<h2>Definizione delle politiche di rete<\/h2>\n<p>\nCome tutte le altre risorse di Kubernetes, le politiche di rete sono definite in YAML. Nel seguente esempio, all'applicazione <code>balance<\/code> viene concesso l'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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Nota di traduzione.<\/b>: questo screenshot, come tutti i successivi simili, \u00e8 stato creato non con gli strumenti nativi di Kubernetes, ma attraverso lo strumento Tufin Orca, il cui sviluppo \u00e8 sostenuto dalla societ\u00e0 dell'autore dell'articolo originale e che viene menzionato alla fine del materiale.)<\/i><\/p>\n<p>Per definire una propria politica di rete saranno richieste conoscenze di base di YAML. Questo linguaggio si basa su indentazioni (definite da spazi, non tabulazioni). Un elemento con indentazione appartiene all'elemento con indentazione pi\u00f9 vicino sopra di esso. Un nuovo elemento di lista inizia con un trattino, mentre gli altri elementi appaiono come <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 di Kubernetes comprendono quattro elementi:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: definisce i pod interessati da questa politica (obiettivi) \u2014 obbligatorio;<\/li>\n<li> <code>policyTypes<\/code>: specifica quali tipi di politiche sono incluse: ingress e\/o egress \u2014 non obbligatorio, ma consiglio di definirlo esplicitamente in tutti i casi;<\/li>\n<li> <code>ingress<\/code>: definisce il traffico <b>ingress<\/b> il traffico verso i pod target \u2014 facoltativo;<\/li>\n<li> <code>egress<\/code>: definisce il traffico <b>traffico in uscita dai pod di destinazione \u2014 non obbligatorio.<\/b> il traffico dai pod target \u2014 facoltativo.<\/li>\n<\/ol>\n<p>\nrole <code>), mostra come vengono utilizzati tutti e quattro gli elementi:<\/code> in <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;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &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;\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 specialisti della 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi prega di notare che tutti e quattro gli elementi non sono obbligatori. Solo <code>podSelector<\/code>l'elemento obbligatorio pu\u00f2 essere utilizzato come desiderato.<\/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 al riguardo 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 dall'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 base alla logica sopra esposta, nel caso in cui i parametri <code>ingress<\/code> e\/o <code>egress<\/code> siano omessi, la politica vieta tutto il traffico (vedere \"Regola di pulizia\" qui sotto).<\/p>\n<h2>La politica predefinita \u00e8 consentita<\/h2>\n<p>\nSe non sono definite politiche, Kubernetes per impostazione predefinita consente tutto il traffico. Tutti i pod possono scambiarsi liberamente informazioni tra loro. Da un punto di vista della sicurezza questo pu\u00f2 sembrare illogico, ma ricorda che Kubernetes \u00e8 stato originariamente creato dagli sviluppatori per favorire 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 gli ambienti logici l'uno dall'altro, mentre lo scambio di dati tra gli spazi \u00e8 consentito per impostazione predefinita.<\/p>\n<p>Come la maggior parte dei componenti di Kubernetes, le politiche di rete esistono in uno spazio dei nomi specifico. Nel blocco <code>metadati<\/code> puoi 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 specificato esplicitamente, il sistema utilizzer\u00e0 lo spazio dei nomi 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>\nConsiglio di <b>specificare esplicitamente lo spazio dei nomi<\/b>, a meno che tu non stia scrivendo una politica destinata a pi\u00f9 namespace simultaneamente.<\/p>\n<p><b>Principale<\/b> elemento <code>podSelector<\/code> nella politica verranno selezionati 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 podSelector <b>nei blocchi ingress ed egress<\/b> possono selezionare pod solo dal proprio namespace, a meno che non vengano uniti tramite <code>namespaceSelector<\/code> (di cui si parler\u00e0 nella sezione \"Filtra per spazi dei nomi e pod\").<\/p>\n<h2>Regole di denominazione delle politiche<\/h2>\n<p>\nI nomi delle politiche sono unici all'interno di un singolo namespace. Non possono esserci due politiche con lo stesso nome nello stesso namespace, ma possono esserci politiche con nomi identici in namespace diversi. Questo \u00e8 utile quando si desidera riapplicare la stessa politica su pi\u00f9 namespace.<\/p>\n<p>Mi piace particolarmente un modo di denominazione. Consiste nel collegare il nome del namespace ai pod target. 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etichette<\/h2>\n<p>\nSi possono assegnare etichette personalizzate a oggetti Kubernetes, come pod e namespace. Le etichette (<i>labels<\/i> \u2014 sono etichette) sono l'equivalente dei tag nel cloud. Le politiche di rete 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 o <b>namespace<\/b>, a cui si applicano. In questo esempio verranno 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 usa <code>namespaceSelector<\/code> <b>assicurati che i namespace selezionati contengano l'etichetta necessaria<\/b>. Tieni presente che i namespace predefiniti, come <code>default<\/code> e <code>kube-system<\/code>, di default non contengono etichette.<\/p>\n<p>Per aggiungere un'etichetta a un namespace, puoi procedere nel seguente modo:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nIn questo caso, il namespace nella sezione <code>metadati<\/code> deve fare riferimento al nome reale del namespace, 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 destinatari. Le politiche di rete di Kubernetes sono definite per l'obiettivo \u2014 un insieme di pod a cui si applicano, e quindi 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 un'etichetta con chiave <code>app<\/code> e il 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 specialisti della 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSottosezione <code>ingress<\/code> in questa politica apre il traffico in ingresso ai pod di destinazione. In altre parole, ingress funge da fonte, mentre l'obiettivo \u00e8 il destinatario corrispondente. Analogamente, egress \u00e8 il destinatario, e l'obiettivo \u00e8 la sua fonte.<\/p>\n<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per specialisti della 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>prestare particolare attenzione a DNS<\/b> \u2014 Kubernetes utilizza questo servizio per mappare i servizi agli indirizzi IP. Ad esempio, la seguente politica non funzioner\u00e0 poich\u00e9 non hai consentito all'applicazione <code>balance<\/code> di accedere a 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPu\u00f2 essere risolta aprendo 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nElemento finale <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 servizio Kubernetes corrispondente (di solito opera nello spazio <code>kube-system<\/code>).<\/p>\n<p>Questo approccio funziona, tuttavia \u00e8 <b>eccessivamente permissivo e non sicuro<\/b>, poich\u00e9 consente di inoltrare richieste DNS al di fuori del cluster.<\/p>\n<p>Pu\u00f2 essere migliorato in tre passi 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Consentire le query DNS solo nello spazio dei nomi <code>kube-system<\/code>.<\/p>\n<p>Per fare ci\u00f2, \u00e8 necessario aggiungere un'etichetta allo spazio dei nomi <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 e definirla nella politica utilizzando <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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. I paranoici possono spingersi ulteriormente e limitare le query DNS a un determinato servizio DNS in <code>kube-system<\/code>. Nella sezione \"Filtra per spazi dei nomi e pod\" verr\u00e0 spiegato come ottenere ci\u00f2.<\/p>\n<p>Un'altra opzione \u00e8 consentire DNS a livello dello 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 nello spazio dei nomi.<\/p>\n<p><img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>La prima corrispondenza e l'ordine delle regole<\/h2>\n<p>\nNei normali firewall, l'azione (\"Consenti\" o \"Negare\") per un pacchetto \u00e8 determinata dalla prima regola che soddisfa. <b>In Kubernetes, l'ordine delle politiche non ha importanza.<\/b><\/p>\n<p>Per impostazione predefinita, quando non sono definite politiche, le comunicazioni tra i pod sono consentite e possono scambiarsi liberamente informazioni. Non appena inizi a formulare politiche, ogni pod interessato da almeno una di esse diventa isolato secondo la disgiunzione (logico OR) di tutte le politiche che lo selezionano. I pod non interessati da alcuna politica rimangono aperti.<\/p>\n<p>Puoi modificare questo comportamento con una regola di pulizia.<\/p>\n<h2>Regola di pulizia (\"Negare\")<\/h2>\n<p>\nLe politiche firewall di solito negano qualsiasi traffico non esplicitamente autorizzato.<\/p>\n<p><b>In Kubernetes non esiste un'azione \"negare\" (deny)<\/b>, tuttavia, un effetto simile pu\u00f2 essere ottenuto con una politica normale (permissiva), selezionando un gruppo vuoto di pod sorgente (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 specialisti della 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 entrata.<\/p>\n<p>Analogamente, \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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi prega di notare che <b>qualsiasi politica aggiuntiva che consenta il traffico ai pod nello spazio dei nomi avr\u00e0 la priorit\u00e0 su questa regola<\/b> (analogamente all'aggiunta di una regola permissiva prima di una proibitiva nella configurazione del firewall).<\/p>\n<h2>Consentire tutto (Any-Any-Any-Allow)<\/h2>\n<p>\nPer creare una politica \"Consentire tutto\", \u00e8 necessario completare la suddetta politica proibitiva 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;&lt;\n  - {}     # &lt;&lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introduzione alle politiche di rete di Kubernetes per specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEssa consente l'accesso da <b>tutti i pod in tutti gli spazi dei nomi (e tutti gli IP) a qualsiasi pod nello spazio dei nomi <code>default<\/code><\/b>. Un comportamento simile \u00e8 abilitato per impostazione predefinita, quindi di solito non \u00e8 necessario definirlo ulteriormente. Tuttavia, pu\u00f2 essere necessario disattivare temporaneamente alcune autorizzazioni specifiche per diagnosticare un problema.<\/p>\n<p>La regola pu\u00f2 essere ristretta e consentire l'accesso 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa seguente politica consente tutto il traffico in entrata (ingress) e in uscita (egress), compreso 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 specialisti della 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Unire pi\u00f9 politiche<\/h2>\n<p>\nLe politiche si combinano mediante l'operatore logico OR a tre livelli; le autorizzazioni di ogni pod sono stabilite in base alla disgiunzione di tutte le politiche che lo riguardano:<\/p>\n<p>1. Nei campi <code>da<\/code> e <code>to<\/code> \u00e8 possibile definire tre tipi di elementi (tutti combinati tramite OR):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 seleziona l'intero 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>\nIn questo caso, il numero di elementi (anche identici) nelle sottosezioni <code>da<\/code>\/<code>to<\/code> non \u00e8 limitato. Tutti saranno uniti tramite l'operatore 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 specialisti della 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 contenere molti elementi <code>da<\/code> (combinati con un logico O). Analogamente, la sezione <code>egress<\/code> pu\u00f2 includere molti elementi <code>to<\/code> (anch'essi combinati 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Diverse policy vengono anch'esse aggregate con un logico O<\/p>\n<p>Ma durante la loro aggregazione esiste una limitazione, alla quale <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 policy solo con diverse <code>policyTypes<\/code> (<code>Ingress<\/code> o <code>Egress<\/code>). Le policy che definiscono ingress (o egress) si sovrascriveranno a vicenda.<\/p>\n<h2>Collegamento tra spazi dei nomi<\/h2>\n<p>\nPer impostazione predefinita, lo scambio di informazioni tra spazi dei nomi \u00e8 consentito. \u00c8 possibile modificare ci\u00f2 tramite una policy restrittiva che limiter\u00e0 il traffico in uscita e\/o in entrata in uno spazio dei nomi (vedi \"Regola di pulizia\" sopra).<\/p>\n<p>Bloccando l'accesso a uno spazio dei nomi (vedi \"Regola di pulizia\" sopra), \u00e8 possibile fare delle eccezioni nella policy restrittiva, consentendo connessioni da uno spazio dei nomi specifico 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 specialisti della 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> accederanno ai pod <code>postgres<\/code> nello spazio dei nomi <code>database<\/code>. Ma cosa succede se si desidera aprire l'accesso a <code>postgres<\/code> solo ai pod specifici nello spazio dei nomi <code>default<\/code>?<\/p>\n<h2>Filtraggio per spazi dei nomi e pod<\/h2>\n<p>\nKubernetes versione 1.11 e successivi permette di combinare operatori <code>namespaceSelector<\/code> e <code>podSelector<\/code> utilizzando un logico E. Si presenta come segue:<\/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 specialisti della 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>Si prega di notare che <code>podSelector<\/code> non inizia con un trattino. In YAML, ci\u00f2 significa che <code>podSelector<\/code> e quello davanti ad esso <code>namespaceSelector<\/code> appartengono allo stesso elemento della lista. Pertanto, sono combinati con un logico E.<\/p>\n<p>Aggiungere un trattino davanti <code>podSelector<\/code> porter\u00e0 alla creazione di un nuovo elemento della lista, che sar\u00e0 combinato con quello precedente <code>namespaceSelector<\/code> utilizzando l'operatore logico O.<\/p>\n<p>Per selezionare i pod con un'etichetta specifica <b>in tutti gli spazi dei nomi<\/b>, inserisci 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Etichette multiple vengono unite con E<\/h2>\n<p>\nLe regole del firewall con pi\u00f9 oggetti (host, reti, gruppi) vengono combinate usando l'operatore logico O. La seguente regola si attiver\u00e0 se la fonte del pacchetto corrisponde a <code>Host_1<\/code> O <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Sorgente | 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> vengono combinate con E logico. Ad esempio, la seguente regola selezioner\u00e0 i pod che possiedono 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 della politica, selettori di pod e selettori di spazi dei nomi.<\/p>\n<h2>Sottoreti e indirizzi IP (IPBlocks)<\/h2>\n<p>\nPer segmentare la rete, i firewall utilizzano VLAN, indirizzi IP e sottoreti.<\/p>\n<p>In Kubernetes, gli indirizzi IP sono assegnati automaticamente ai pod e possono cambiare frequentemente, quindi per selezionare pod e spazi dei nomi nelle politiche di rete vengono utilizzate le etichette.<\/p>\n<p>Sottoreti (<code>ipBlocks<\/code>) sono utilizzati nella gestione delle connessioni in ingresso (ingress) o in uscita (egress) esterne (North-South). Ad esempio, questa politica apre a tutti i pod dallo spazio dei nomi <code>default<\/code> l'accesso 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn selettore vuoto di pod in questo esempio significa 'seleziona tutti i pod nello spazio dei nomi'.<\/p>\n<p>Questa policy consente solo l'accesso a 8.8.8.8; l'accesso a qualsiasi altro IP \u00e8 vietato. Fondamentalmente, hai bloccato l'accesso al servizio DNS interno di Kubernetes. Se desideri comunque consentirlo, 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 vengono utilizzati in <code>ipBlocks<\/code>. Specificando <b>gli IP interni dei pod<\/b>, effettivamente consentirete connessioni a\/dai pod con questi indirizzi. Nella pratica, non saprete quale indirizzo IP utilizzare, ecco perch\u00e9 non dovrebbero essere utilizzati per selezionare i 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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n\u00c8 possibile aprire l'accesso solo agli IP esterni, escludendo gli indirizzi IP interni dei pod. Ad esempio, se la subnet del vostro 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 specialisti della 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. Questo significa che si pu\u00f2 semplicemente non specificare i numeri di porta nelle politiche e lasciare tutto di default. Tuttavia, \u00e8 consigliabile 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:             # &lt;&lt;&lt;\n      - port: 443      # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\n      - port: 80       # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNota che il selettore <code>ports<\/code> si applica a tutti gli elementi del blocco <code>to<\/code> o <code>da<\/code>, in cui \u00e8 contenuto. Per specificare porte diverse per diversi insiemi di elementi, suddividi <code>ingress<\/code> o <code>egress<\/code> in pi\u00f9 sotto-sezioni con <code>to<\/code> o <code>da<\/code> e in ognuna 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:             # &lt;&lt;&lt;\n     - port: 443       # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;\n     - port: 80        # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\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 specialisti della sicurezza\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFunzionamento delle porte di default:<\/p>\n<ul>\n<li> Se ometti completamente la definizione delle porte (<code>ports<\/code>), significa tutti i protocolli e tutte le porte;<\/li>\n<li> Se ometti la definizione del protocollo (<code>protocollo<\/code>), questo significa TCP;<\/li>\n<li> Se ometti la definizione della porta (<code>port<\/code>), questo significa tutte le porte.<\/li>\n<\/ul>\n<p>\nMigliore prassi: non affidarti ai valori di default, specifica esplicitamente 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 (maggiore chiarezza nel paragrafo successivo).<\/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 servizi \u2014 bilanciatori di carico virtuali che reindirizzano 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 funzionano 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, \u00e8 necessario specificare esattamente la porta 8080 nella politica di rete.<\/p>\n<p>Un meccanismo del genere dovrebbe essere considerato subottimale: se la configurazione interna del servizio cambia (le porte ascoltate dai pod), le politiche di rete dovranno essere aggiornate.<\/p>\n<p>Un nuovo approccio architetturale con l'uso di Service Mesh <i>(ad esempio, vedi Istio qui sotto \u2014 nota del traduttore.)<\/i> affronta 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 consentire a esso di stabilire una connessione in uscita (per questo \u00e8 necessario configurare la politica egress), e il pod B deve avere la possibilit\u00e0 di accettare una connessione in ingresso (a questo scopo, serve una politica ingress).<\/p>\n<p>Tuttavia, nella pratica si pu\u00f2 fare affidamento sulla politica predefinita che consente connessioni in una o entrambe le direzioni.<\/p>\n<p>Se un certo pod-<b>fonte<\/b> \u00e8 selezionato da una o pi\u00f9 <b>egress<\/b>-politiche, le restrizioni imposte su di esso saranno definite dalla loro disgiunzione. In questo caso, sar\u00e0 necessario consentire esplicitamente la connessione al pod-<b>destinatario<\/b>. Se il pod non \u00e8 selezionato da alcuna politica, il suo traffico in uscita (egress) \u00e8 consentito per impostazione predefinita.<\/p>\n<p>Allo stesso modo la sorte del pod-<b>destinatario<\/b>, selezionato da una o pi\u00f9 <b>ingress<\/b>-sar\u00e0 determinata dalla loro disgiunzione. In questo caso, \u00e8 necessario consentire esplicitamente di ricevere traffico da un pod sorgente. Se un pod non \u00e8 selezionato da alcuna politica, tutto il traffico in ingresso \u00e8 per lui consentito per impostazione predefinita.<\/p>\n<p>Vedi il punto \"Stateful o Stateless\" qui sotto.<\/p>\n<h2>Log<\/h2>\n<p>\nLe politiche di rete di Kubernetes non sono in grado di registrare il traffico. Questo rende difficile determinare se la politica funzioni correttamente e complica notevolmente l'analisi della sicurezza.<\/p>\n<h2>Controllo del traffico verso servizi esterni<\/h2>\n<p>\nLe politiche di rete di Kubernetes non consentono di specificare un nome di dominio completo (DNS) nelle sezioni egress. Questo fatto provoca un notevole inconveniente nel tentativo di limitare il traffico verso destinatari esterni privi di un indirizzo IP fisso (come aws.com).<\/p>\n<h2>Verifica della politica<\/h2>\n<p>\nI firewall ti avviseranno o persino rifiuteranno di accettare una politica errata. Anche Kubernetes esegue una certa verifica. Quando imposti una politica di rete tramite kubectl, Kubernetes pu\u00f2 affermare che \u00e8 errata e rifiutarsi di accettarla. In altri casi, Kubernetes accetter\u00e0 la politica e la completer\u00e0 con i dettagli mancanti. Puoi visualizzarli utilizzando 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 pu\u00f2 lasciar passare alcuni tipi di errori.<\/p>\n<h2>Esecuzione<\/h2>\n<p>\nKubernetes non implementa le politiche di rete da solo, ma \u00e8 solo un gateway API che pone il gravoso compito di controllo sul sistema sottostante, chiamato Container Networking Interface (CNI). Impostare politiche in un cluster Kubernetes senza assegnare un CNI corrispondente \u00e8 come creare politiche su un server di gestione del firewall senza poi installarle nei firewall. Devi assicurarti di avere un CNI adeguato o, nel caso delle piattaforme Kubernetes ospitate nel cloud, <i>(puoi consultare l'elenco dei provider <noindex>qui<\/noindex> \u2014 nota del traduttore)<\/i>, attivare politiche di rete che installeranno il CNI per te.<\/p>\n<p>Nota che Kubernetes non ti avviser\u00e0 se imposti una politica di rete senza il corrispondente CNI ausiliario.<\/p>\n<h3>Stateful o Stateless?<\/h3>\n<p>\nTutti i CNI Kubernetes che ho incontrato mantengono lo stato (ad esempio, Calico utilizza Linux conntrack). Questo consente al pod di ricevere risposte su una connessione TCP da lui avviata senza doverla ristabilire. Tuttavia, non sono a conoscenza di alcuno standard di Kubernetes che garantisca la conservazione dello stato (statefulness).<\/p>\n<h2>Gestione avanzata delle politiche di sicurezza<\/h2>\n<p>\nEcco alcuni modi per migliorare l'efficacia di esecuzione delle politiche di sicurezza in Kubernetes:<\/p>\n<ol>\n<li> Il pattern architettonico Service Mesh utilizza contenitori sidecar per fornire telemetria dettagliata e controllo del traffico a livello di servizi. Ad esempio, puoi considerare <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Alcuni fornitori di CNI hanno arricchito i loro strumenti affinch\u00e9 superassero i limiti delle 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 riportati).<\/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 la verifica delle politiche di rete<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusione<\/h2>\n<p>\nLe politiche di rete di Kubernetes offrono un buon insieme di strumenti per la segmentazione dei cluster; tuttavia, risultano poco intuitive e presentano molte complessit\u00e0. Credo che, a causa di questa difficolt\u00e0, le politiche di molti cluster esistenti contengano errori. 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 alcune questioni e risolvere problemi con cui potresti avere a che fare.<\/p>\n<h2>P.S. dal traduttore<\/h2>\n<p>\nLeggi 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 configurazione della 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 sensibili alla 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 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 (non) per diventare vittima di un attacco 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.1.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.1.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\udd47Introduzione 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}]}}