I pod Kubernetes possono comunicare liberamente tra loro per impostazione predefinita. Ciò rappresenta un rischio per la sicurezza quando il tuo cluster viene utilizzato per più applicazioni o team. Comportamenti errati o accessi dannosi in un pod potrebbero indirizzare il traffico verso gli altri pod nel tuo cluster.
Questo articolo ti insegnerà come evitare questo scenario impostando i criteri di rete. Queste regole ti consentono di controllare i flussi di traffico da pod a pod a livello di indirizzo IP (livello OSI 3 o 4). Puoi definire con precisione le origini in ingresso e in uscita consentite per ciascun pod.
Creazione di un criterio di rete
I criteri di rete vengono creati aggiungendo NetworkPolicy oggetti al tuo cluster. Ogni policy definisce i pod a cui si applica e una o più regole di ingresso e uscita. Ecco un manifesto della politica di base:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadati: nome: network-policy namespace: app spec: podSelector: matchLabels: componente: database policyTypes: – Ingresso – Uscita ingresso: – da: – podSelector: matchLabels: componente: api uscita: – a: – podSelector: matchLabels: component: api
Questo criterio di rete si applica a qualsiasi pod con un'etichetta component: database nello spazio dei nomi dell'app. Afferma che il traffico in entrata (in entrata) e in uscita (in uscita) è consentito solo da e verso i pod con un componente: api label. Tutte le richieste provenienti da altri pod, ad esempio component: web-frontend, verranno bloccate.
I criteri di rete possono essere applicati come qualsiasi altro oggetto utilizzando Kubectl. Avranno effetto immediatamente dopo la loro creazione. Puoi aggiungere il criterio di rete prima di avviare i pod selezionati.
$ kubectl apply -f policy.yaml networkingpolicy.networking.k8s.io/network-policy created
Come funzionano i criteri di rete
I criteri di rete sono implementati dal plug-in di rete attivo del tuo cluster. I tuoi criteri non avranno alcun effetto se il tuo plug-in non supporta la funzione. Le opzioni più popolari come Calico e Cilium vengono fornite con il supporto dei criteri di rete abilitato.
Quando un criterio di rete si applica a un pod, il plug-in ne esaminerà il traffico per verificare che sia conforme al criterio’ ;s requisiti. Tutte le connessioni che non soddisfano i criteri non saranno consentite. Il pod che ha tentato di avviare la connessione rileverà che l'host remoto non è raggiungibile perché stava tentando di accedere a una risorsa bloccata da una regola di uscita o perché un pod remoto ha negato la connessione in entrata utilizzando una regola di ingresso.
Una connessione riuscita tra due pod può essere stabilita solo quando i criteri di rete su entrambi lo consentono. La connessione potrebbe essere vietata da una regola di uscita del pod di avvio o da una regola di ingresso sulla destinazione.
I criteri di rete sono sempre di natura additiva. Quando più criteri selezionano lo stesso pod, l'elenco delle origini in entrata e in uscita consentite sarà la combinazione di tutti i criteri.
Esempio di criteri di rete
I criteri di rete supportano molte opzioni diverse per personalizzare i pod a cui sono destinati e i tipi di connessione consentiti. I seguenti esempi mostrano diversi casi d'uso comuni.
Applica una policy a ogni pod nello spazio dei nomi, consentendo solo il traffico in entrata da un blocco di indirizzi IP specifico
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadati: name: network-policy namespace: < /strong>app spec: podSelector: {} tipi di policy: – Ingresso Ingresso: – Da: – ipBlock: cidr: 172.17.0.0/16
Il blocco podSelector vuoto indica tutti i I pod dello spazio dei nomi sono presi di mira dalla policy. La regola ipBlock limita il traffico in entrata ai pod con un indirizzo IP compreso nell'intervallo specificato. Il traffico in uscita non è bloccato.
Consenti il traffico in entrata da un blocco di indirizzi IP, ma escludi alcuni IP specifici
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadati: nome: network-policy namespace: appspec: podSelector: {} tipi di policy: – Ingresso ingresso: – da: – ipBlock: cidr< strong class="sy2">: 172.17.0.0/16 tranne: – 172.17.0.1/24 – 172.17.0.2/24 – 172.17.0.3/24
Le regole ipBlock supportano un campoexcept per escludere il traffico proveniente da o indirizzato a IP specifici.
Consenti il traffico in entrata da tutti i pod nello spazio dei nomi, ma solo da una porta specifica
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadati: nome: network-policy namespace: app spec: podSelector: {} policyTypes: – Ingresso ingresso: – da: – podSelector: {} porte: – protocollo< /strong>: porta TCP: 443Il campo delle porte è disponibile nelle regole di ingresso e uscita. Definisce le porte da cui il traffico può essere ricevuto e inviato. Facoltativamente, puoi specificare un intervallo di porte, ad esempio 3000 – 3500, impostando il campo endPort (3500) oltre alla porta (3000).
Consenti il traffico dai pod con un'etichetta specifica che esiste in uno spazio dei nomi diverso
apiVersion: networking.k8s.io/v1 kind: NetworkPolicymetadata: name: network-policy namespace: database spec: podSelector: {} policyTypes: – Ingresso ingresso: – da: – namespaceSelector: matchLabels: applicazione: demo-app podSelector: matchLabels: componente : database
La policy afferma che qualsiasi componente con etichetta Pod: database può raggiungere tutti i pod nello spazio dei nomi del database, se il proprio spazio dei nomi è etichettato demo-app.
Puoi consentire il traffico da tutti i pod in uno spazio dei nomi esterno creando una regola che includa solo un campo namespaceSelector.
Consenti esplicitamente tutto il traffico
< p>A volte potresti voler consentire esplicitamente tutto il traffico di un particolare tipo all'interno di uno spazio dei nomi. Includi il tipo nella tua policy ma fornisci un selettore di pod vuoto e nessuna regola:
apiVersion: networking.k8s. io/v1kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: {} tipi di policy: – Ingresso – Uscita ingresso: – {} uscita: – &# 123;}
Tutti i pod nello spazio dei nomi possono comunicare liberamente, come se non esistesse una policy. La creazione della policy consente comunque di indicare le proprie intenzioni ad altri utenti del cluster. Potrebbero mettere in dubbio la presenza di uno spazio dei nomi con rete illimitata in un cluster che è stato altrimenti protetto.
Quando utilizzare i criteri di rete
< p>I criteri di rete devono essere creati per ognuno degli spazi dei nomi e dei pod nel tuo cluster. Questo isola meglio i tuoi pod e ti dà il controllo del flusso del traffico.
Cerca di rendere le tue politiche il più granulari possibile. L'ampliamento eccessivo dell'accesso, ad esempio consentendo l'accesso tra tutti i pod in uno spazio dei nomi, ti espone a rischi se uno dei tuoi container viene compromesso. Prendi in considerazione l'utilizzo di selettori precisi per identificare singoli remoti in ingresso e in uscita per pod sensibili come servizi di autenticazione, database e gestori dei pagamenti.
Kubernetes non abilita alcun criterio di rete per impostazione predefinita che può consentire il verificarsi di sviste, anche se intendi proteggere tutti i pod da un criterio. Puoi mitigare questo rischio aggiungendo una policy catch-all ai tuoi spazi dei nomi. Questo criterio seleziona ogni pod nello spazio dei nomi e applica una regola che vieta tutte le comunicazioni di rete:
apiVersion: networking. k8s.io/v1 kind: NetworkPolicy metadati: name: deny-all namespace : specificheapp:podSelector: {} policyTypes: – Ingress – Egress
I criteri di rete sono sempre limitati agli spazi dei nomi, quindi dovrai creare un separato per ognuno.
Riepilogo
Kubernetes consente a tutti i pod nel tuo cluster di comunicare tra loro. Questo è troppo permissivo per le applicazioni del mondo reale in esecuzione in cluster multiuso. I criteri di rete risolvono questo problema fornendo un sistema simile a un firewall per la gestione delle origini di ingresso e delle destinazioni di uscita accettate da ciascun pod.
È buona norma configurare un criterio di rete su tutti i tuoi pod. Questo proteggerà il tuo cluster in modo che siano consentiti solo i flussi di traffico legittimi. Tuttavia, le policy di rete sono solo una parte della sicurezza di Kubernetes: anche altri meccanismi di protezione come RBAC e contesti di sicurezza dei pod sono strumenti essenziali per rafforzare il tuo ambiente.
LEGGI SUCCESSIVO
- › 7 funzionalità di PowerPoint da utilizzare durante le presentazioni
- › Google Pixel Watch aggiungerà la popolare funzionalità di Apple Watch
- › ChatGPT è un impressionante chatbot basato sull'intelligenza artificiale che non riesce a smettere di mentire
- › Windows 10 vuole davvero che tu esegua già l'aggiornamento
- › Pixel 7 ora dispone di una VPN integrata gratuita
- › Come correggere la luminosità su iPhone quando lo schermo è troppo scuro