Politiche di rete Kubernetes e Calico predefinite

Quando si crea un cluster con una VLAN pubblica, viene creata automaticamente una risorsa HostEndpoint con l'etichetta ibm.role: worker_public per ogni nodo di lavoro e la relativa interfaccia di rete pubblica. Questa impostazione " HostEndpoint " fa sì che tutto il traffico da o verso l'interfaccia di rete pubblica venga scartato, a meno che non sia espressamente consentito da una politica " Calico " che selezioni l'etichetta " ibm.role: worker_public ".

Una risorsa HostEndpoint con l'etichetta ibm.role: worker_private viene creata automaticamente anche per ogni nodo di lavoro e la sua interfaccia di rete privata. Viene creata una politica allow-all-private-default predefinita in modo che tutto il traffico sia consentito verso e dall'interfaccia di rete privata. Questo HostEndpoint consente agli utenti del cluster di limitare ulteriormente il traffico sulla rete privata creando politiche " Calico " che selezionano " ibm.role: worker_private " e hanno un numero d'ordine inferiore rispetto a " allow-all-private-default".

Queste politiche predefinite per l'host Calico consentono tutto il traffico di rete in uscita verso reti pubbliche e consentono il traffico in entrata da reti pubbliche verso specifici componenti del cluster, quali Kubernetes, NodePort,, LoadBalancer, e i servizi Ingress. Tutto il traffico privato è consentito per impostazione predefinita dalla politica allow-all-private-default. Qualsiasi altro traffico di rete in entrata proveniente da Internet verso i nodi di lavoro che non sia specificato nelle politiche predefinite viene bloccato. Le politiche predefinite non influiscono sul traffico tra i pod

Non rimuovere le politiche predefinite dal tuo cluster, perché vengono ricreate al successivo aggiornamento del master del cluster o al successivo aggiornamento del master. Se si desidera limitare ulteriormente il traffico, applicare politiche di " Calico " di ordine inferiore per bloccare il traffico. Assicurati di comprendere appieno cosa stai bloccando e che i componenti del cluster non hanno bisogno del traffico che vuoi bloccare.

Controlla le seguenti politiche host Calico predefinite che vengono automaticamente applicate al tuo cluster.

Vengono inoltre create le politiche predefinite di “ Kubernetes ” che limitano l’accesso alla dashboard di “ Kubernetes ”. Le politiche Kubernetes non si applicano all'endpoint host, ma al livello del pod e a tutti i cluster classici e VPC.

Visualizzazione delle politiche di rete

Visualizza i dettagli per impostazione predefinita e tutte le politiche di rete aggiunte che vengono applicate al tuo cluster.

Prima di iniziare, installa e configurare la CLI Calico e imposta il contesto per il tuo cluster per eseguire i comandi Calico.

1. Visualizza l'endpoint host Calico.

   kubectl get hostendpoints.projectcalico.org -o yaml
   

2. Visualizza tutte le politiche di rete " Calico " create per il cluster. Questo elenco include politiche che potrebbero non essere ancora applicabili ad alcun pod o host. Perché venga applicata una politica Calico, deve esistere un pod Kubernetes o Calico HostEndpoint che corrisponda al selettore nella politica di rete Calico.

   Calico Le politiche di rete sono limitate a specifici spazi dei nomi:

   kubectl get networkpolicy.projectcalico.org --all-namespaces -o wide
   

   Kubernetes Le politiche di rete sono inoltre limitate a specifici spazi dei nomi:

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o wide
   

   Calico Le politiche di rete globali non sono limitate a spazi dei nomi specifici:

   kubectl get globalnetworkpolicies.projectcalico.org -o wide
   

3. Visualizza i dettagli di una politica di rete di tipo “ Calico ”.

   kubectl get networkpolicies.projectcalico.org -o yaml <policy_name> --namespace <policy_namespace>
   

4. Visualizza i dettagli di tutte le politiche della rete globale " Calico " relative al cluster.

   kubectl get globalnetworkpolicies.projectcalico.org -o yaml
   

5. Visualizza i dettagli di tutte le politiche di rete " Kubernetes " relative al cluster.

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o yaml
   

Aggiunta di politiche di rete

Di solito, le politiche predefinite non richiedono modifiche. Solo in scenari avanzati potrebbero essere richieste delle modifiche. Se ritieni di dover apportare modifiche, puoi creare le tue politiche di rete.

Per creare politiche di ret Kubernetes, consultare la documentazione sulle politiche di rete di Kubernetes.

Per creare le politiche Calico, utilizza la seguente procedura.

1. Definisci il tuo " Calico politica di rete " o " politica di rete globale " creando uno script di configurazione (.yaml) con la sintassi delle policy di Calico v3. Questi file di configurazione includono i selettori che descrivono a quali pod, spazi dei nomi o host vengono applicate queste politiche.

2. Applica le politiche al cluster.

   kubectl apply -f policy.yaml
   

Calico Inoltre, le politiche di rete di Kubernetes bloccano solo le nuove connessioni, senza interrompere quelle già esistenti prima dell'applicazione della politica. Dopo aver applicato una politica nuova o modificata, per verificare che funzioni correttamente e che non blocchi più del dovuto, procedere come segue:

1. Riavvia tutti i pod che potrebbero essere interessati dalla policy, oppure riavvia tutti i pod nel caso in cui il selettore non sia corretto e l'impatto sia maggiore di quanto pensi.

2. Esegui ibmcloud ks cluster master refresh -c CLUSTER-ID per riavviare i tuoi pod master del cluster. Ciò interrompe le connessioni esistenti tra kubelet e altri componenti e il master, costringendoli a riconnettersi. Questo permette di verificare se le politiche nuove e modificate bloccano eventuali connessioni necessarie ai componenti master.

3. Prova a collegarti al dashboard Kubernetes per assicurarti che le modifiche della politica non blocchino le connessioni necessarie a quei componenti.

Controllo del traffico in entrata ai servizi NLB o NodePort

Per impostazione predefinita, i servizi Kubernetes, NodePort e LoadBalancer rendono la tua app disponibile su tutte le interfacce del cluster, sia pubbliche che private. Tuttavia, puoi usare le politiche Calico per bloccare il traffico in entrata ai tuoi servizi in base all'origine o alla destinazione del traffico.

È difficile applicare le politiche predefinite di Kubernetes e Calico per proteggere i servizi Kubernetes, NodePort e LoadBalancer a causa delle regole DNAT di iptables generate per tali servizi. Tuttavia, le politiche pre-DNAT impediscono al traffico specificato di raggiungere le tue applicazioni perché generano e applicano le regole iptables prima che Kubernetes utilizzi la DNAT regolare per inoltrare il traffico ai pod.

Alcuni utilizzi comuni per le politiche di rete pre-DNAT Calico:

• Blocca il traffico alle porte del nodo pubblico di un servizio NLB (network load balancer) privato. Un servizio NLB rende la tua applicazione disponibile sulla porta e l'indirizzo IP dell'NLB e la rende disponibile sulle porte del nodo del servizio. È possibile accedere alle porte del nodo da ogni indirizzo IP (pubblico e privato) di ogni nodo all'interno del cluster.
• Blocca il traffico verso le porte del nodo pubblico sui cluster che eseguono i nodi di lavoro edge: il blocco delle porte del nodo assicura che i nodi di lavoro edge siano gli unici nodi di lavoro a gestire il traffico in entrata.
• Blocca il traffico da determinati indirizzi IP o CIDR di origine
• Consenti il traffico solo da determinati indirizzi IP o CIDR di origine e blocca tutto il resto del traffico

Per vedere come consentire o bloccare gli indirizzi IP di origine, prova l'esercitazione sull'utilizzo delle politiche di rete Calico per bloccare il traffico.

Politiche Calico di esempio per limitare il traffico di rete pubblico o privato

IBM fornisce una serie di esempi di politiche di rete pubblica Calico e di politiche di rete privata Calico che limitano ulteriormente il traffico di rete pubblico e privato sui worker del cluster.

Queste politiche non sono destinate a bloccare tutto, né necessariamente soddisfano da sole i requisiti di conformità. Non sono supportati attivamente da IBM e sono intesi semplicemente come un possibile punto di partenza; devono essere modificati per adattarsi alle vostre specifiche esigenze. Per ulteriori informazioni, consultare il file README.

IBM Non si consiglia più di utilizzare le politiche di esempio “allow-egress-pods-public”, “allow-public-services-pods”, “allow-egress-pods-private” o “allow-private-services-pods” riportate nelle sezioni “Applicazione delle politiche di rete pubblica ” e “Applicazione delle politiche di rete privata ”. Questi criteri controllavano l'uscita da tutti i pod del cluster. Per controllare il traffico da e verso i pod, IBM consiglia di utilizzare Kubernetes NetworkPolicy e di indirizzare le regole verso namespace e pod specifici, anziché ricorrere a queste politiche generiche che trattano tutti i pod allo stesso modo.

Controllo del traffico tra i pod

Le politiche di Kubernetes proteggono i pod dal traffico di rete interno. È possibile creare semplici politiche di rete " Kubernetes " per isolare i microservizi delle applicazioni gli uni dagli altri all'interno di uno stesso namespace o tra diversi namespace.

Per impostazione predefinita, qualsiasi pod ha accesso a qualsiasi altro pod nel cluster. Inoltre, qualsiasi pod ha accesso a qualsiasi servizio esposto dalla rete di pod, come un servizio di metriche, il DNS del cluster, il server API o qualsiasi servizio che crei manualmente nel tuo cluster.

Registrazione del traffico rifiutato

Per registrare le richieste di traffico rifiutate per specifici pod nel tuo cluster, puoi creare una politica di rete di log Calico.

Quando configuri le politiche di rete per limitare il traffico ai pod dell'applicazione, le richieste di traffico che non sono consentite da queste politiche vengono rifiutate ed eliminate. In alcuni scenari, potresti volere ulteriori informazioni sulle richieste di traffico rifiutate. Ad esempio, potresti notare del traffico insolito che viene continuamente rifiutato da una delle tue politiche di rete. Per monitorare la potenziale minaccia alla sicurezza, puoi impostare la registrazione nei log per eseguire una registrazione ogni volta che la politica rifiuta un'azione tentata su specifici pod dell'applicazione.

Questa sezione ti mostra come registrare il traffico rifiutato da una politica di rete Kubernetes. Per registrare il traffico rifiutato da una politica di rete Calico, vedi la lezione 5 dell'esercitazione relativa alla politica di rete Calico.

1. Crea o utilizza una politica di rete Kubernetes esistente che blocca o limita il traffico in entrata.

   1. Crea una politica di rete Kubernetes. Ad esempio, per controllare il traffico tra i pod, potresti utilizzare la seguente politica Kubernetes di esempio denominata access-nginx che limita l'accesso a un'applicazione NGINX. Il traffico in entrata ai pod con etichetta "run=nginx" è consentito solo dai pod con l'etichetta "run=access". Tutto l'altro traffico in entrata ai pod dell'applicazione "run=nginx" viene bloccato.

       kind: NetworkPolicy
       apiVersion: networking.k8s.io/v1
       metadata:
        name: access-nginx
       spec:
        podSelector:
          matchLabels:
            run: nginx
        ingress:
          - from:
            - podSelector:
                matchLabels:
                  run: access
       ```
   2. Applica la politica.
   
   ```sh {: pre}
       kubectl apply -f <policy_name>.yaml
       ```
   

2. Per registrare tutto il traffico rifiutato dalla politica che hai creato nel passo precedente, crea una politica di rete (NetworkPolicy) Calico denominata log-denied-packets. La seguente politica Calico utilizza lo stesso selettore pod della politica access-nginx Kubernetes di esempio descritta nel passo 1, tuttavia la sintassi è leggermente differente poiché è una Calico NetworkPolicy invece di una Kubernetes NetworkPolicy. Inoltre, poiché tutte le NetworkPolicy Kubernetes vengono valutate da Calico come ordine 1000, viene aggiunto il numero d'ordine 3000 per garantire che venga valutato dopo la NetworkPolicy di Kubernetes. Con queste due politiche in atto, ecco il risultato:

   • Le nuove connessioni in entrata nel pod nginx vengono prima valutate rispetto alla NetworkPolicy (ordine 1000) Kubernetes. Le connessioni provenienti da un pod con l'etichetta " run=access " vengono accettate immediatamente, il che significa che non vengono valutate altre politiche.
   • Se la connessione proviene da un pod senza l'etichetta run=access (o da qualsiasi cosa che non sia un pod), Kubernetes NetworkPolicy non eseguirà alcuna operazione e Calico valuta successivamente la politica log-denied-packets. Questa politica registra il pacchetto in syslog sul nodo di lavoro su cui si trova il pod nginx.
   • Calico, quindi, verifica la presenza di altre politiche da applicare alla connessione e, poiché non ne trova alcuna, il pacchetto viene eliminato. Questo perché tutto il traffico verso un pod con una politica che non è esplicitamente consentita viene eliminato.

       apiVersion: projectcalico.org/v3
       kind: NetworkPolicy
       metadata:
         name: log-denied-packets
       spec:
         types:
         - Ingress
         ingress:
         - action: Log
           destination: {}
           source: {}
         selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
         order: 3000
       ```
   
   

types

Questa politica Ingress si applica a tutte le richieste di traffico in entrata. Il valore Ingress è un termine generico per tutto il traffico in entrata e non fa riferimento al traffico solo dall'ALB Ingress IBM. ingress : action: L'azione " Log " scrive una voce di log per ogni richiesta che soddisfa questa politica nel percorso /var/log/syslog sul nodo di lavoro. : destination: Non viene specificata alcuna destinazione perché l’ selector a applica questa policy a tutti i pod con una determinata etichetta. : source: La presente politica si applica alle richieste provenienti da qualsiasi fonte.

selector

Il selettore deve indirizzare lo stesso traffico dell'accesso originale - nginx Kubernetes NetworkPolicy. Poiché questa è una politica Calico, devi includere projectcalico.org/orchestrator == 'k8s' per indicare che si applica a tutti i pod nello spazio dei nomi della politica, oltre al run == 'nginx' originale.

order

Le politiche Calico hanno degli ordini che determinano quando vengono applicate ai pacchetti di richiesta in entrata. Le politiche con ordini più bassi, come 1000, sono applicate per prime. Le politiche con ordini più alti sono applicate dopo le politiche con ordini più bassi. Ad esempio, una politica di ordine molto elevato, come 3000, viene effettivamente applicata per ultima, dopo che sono state applicate tutte le politiche di ordine inferiore. I pacchetti di richiesta in entrata passano per la catena di regole iptables e provano a mettere in corrispondenza prima le regole dalle politiche con un ordine più basso. Se corrisponde a una qualsiasi regola, il pacchetto viene accettato. Tuttavia, se un pacchetto non corrisponde ad alcuna regola, arriva all'ultima regola nella catena di regole iptables con l'ordine più alto. Per assicurarti che questa politica sia l'ultima politica nella catena, utilizza un ordine molto più alto, come 3000, rispetto alla politica che hai creato nel passo 1. Nota che Kubernetes NetworkPolicy vengono applicati come ordine 1000.

3. Applica la politica.

   kubectl apply -f log-denied-packets.yaml
   

4. Generare voci di log inviando richieste non consentite dalla politica creata nel passo 1. Ad esempio, prova a eseguire il ping del pod protetto dalla politica di rete da un pod o da un indirizzo IP non consentito.

5. Controlla la presenza di voci di log scritte nel percorso /var/log/syslog . Gli indirizzi IP DST (destinazione) o SRC (origine) nella voce di log potrebbero essere diversi da quelli previsti a causa di proxy, NAT (Network Address Translation) e altri processi di rete. La voce di log ha un aspetto simile al seguente:

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. Facoltativo: inoltra i log da /var/log/syslog a IBM Cloud Logs oppure a un server syslog esterno.