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 rende più semplice per gli utenti del cluster limitare ulteriormente il traffico di rete privata creando delle politiche Calico che selezionano ibm.role: worker_private e hanno un numero di 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.

Installazione e configurazione della CLI Calico

Per visualizzare, gestire e aggiungere le politiche Calico, installare e configurare la CLI Calico.

1. Imposta il contesto per il tuo cluster per eseguire i comandi Calico.

   • Kubernetes versione 1.19 e successive:

     1. Scarica il file di configurazione " kubeconfig " relativo al tuo cluster.

        ibmcloud ks cluster config --cluster CLUSTER_NAME_OR_ID
        

     2. Impostare la variabile di ambiente DATASTORE_TYPE su kubernetes.

        export DATASTORE_TYPE=kubernetes
        

2. Se le politiche di rete aziendali utilizzano proxy o firewall che impediscono l'accesso dal tuo sistema locale agli endpoint pubblici, consenti l'accesso TCP dei comandi Calico.

3. Attenersi alla procedura per installare lo strumento della riga comandi calicoctl.

   • Linux e OS X

     1. Scarica la versione della CLI di Calico compatibile con il tuo sistema operativo. Per OS X, potrebbe essere necessario consentire manualmente l'apertura e l'esecuzione del file scaricato selezionando Preferenze di sistema > Sicurezza & Privacy > Generale.

     2. Sposta il file nella directory /usr/local/bin.

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. Rendi il file eseguibile.

        chmod +x /usr/local/bin/calicoctl
        

     4. Assicurati che non ci sia un vecchio file di configurazione Calico calicoctl.cfg nella directory /etc/calico. Se il file /etc/calico/calicoctl.cfg esiste, eliminarlo.

   • Windows

     1. Scarica la CLI Calico. Quando salvi il file, rinominalo in calicoctl.exe e salvalo nella stessa directory della CLI IBM Cloud. Questa configurazione ti consente di ridurre le modifiche al percorso file quando esegui i comandi in un secondo momento.

     2. Imposta la variabile di ambiente sul file di configurazione per il cluster.

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/kube-config.yaml
        

4. Verifica che la configurazione di Calico funzioni correttamente.

   calicoctl get nodes
   

   Output di esempio

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

La modifica del plug-in " Calico ", dei componenti o delle impostazioni predefinite di " Calico " non è supportata. Ad esempio, non distribuire una nuova versione del plug-in Calico, né modificare i daemon set o le distribuzioni relativi ai componenti Calico, alle risorse predefinite IPPool o ai nodi Calico. In alternativa, è possibile seguire le istruzioni riportate nella documentazione per modificare l'MTU di Calico o, se necessario, per disabilitare il plug-in di mappatura delle porte per il CNI Calico.

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.

   calicoctl get hostendpoint -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.

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

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

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

   calicoctl get GlobalNetworkPolicy -o wide
   

3. Visualizza i dettagli per una politica di rete.

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. Visualizza i dettagli di tutte le politiche di rete globali per il cluster.

   calicoctl get GlobalNetworkPolicy -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. Prima di iniziare, installa e configurare la CLI Calico e imposta il contesto per il tuo cluster per eseguire i comandi Calico.

1. Definisci il tuo " Calico politica di rete " o " politica di rete globale " creando uno script di configurazione (.yaml) utilizzando 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.

   Per i nuovi cluster creati con la versione 1.29 o successive, i nomi abbreviati globalnetworkpolicies.crd.projectcalico.org (gnp) e hostendpoints.crd.projectcalico.org (hep) non sono supportati. Tuttavia, se si esegue l'aggiornamento di un cluster alla versione 1.29 o successive, i nomi abbreviati continuano a essere supportati.

2. Applica le politiche al cluster. Se si dispone di un sistema Windows, includere l'opzione --config=<filepath>/calicoctl.cfg.

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Tieni presente che le politiche di rete Calico e Kubernetes bloccano solo le nuove connessioni, non interrompono le connessioni che esistevano prima dell'applicazione della politica. Quindi, dopo aver applicato una politica nuova o modificata, per verificare che stia funzionando e non stia bloccando più di quanto dovrebbe, effettuare le seguenti operazioni:

1. Riavviare i pod che potrebbero essere interessati dalla politica. Meglio ancora, riavvia tutti i pod, nel caso in cui non hai il tuo selettore corretto e influisce più di quanto pensi.

2. Esegui ibmcloud ks cluster master refresh -c CLUSTER-ID per riavviare i tuoi pod master del cluster. Ciò interromperà le connessioni esistenti da kubelet e altri componenti al master e le forzerà a riconnettersi. Ciò mostrerà se le politiche nuove e modificate bloccano le 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 l'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

Forniamo una serie di file di esempio Calico politiche relative alle reti pubbliche che limitano ulteriormente il traffico di rete pubblico/privato sui worker del cluster. Questi criteri consentono il traffico necessario per l'implementazione del cluster e bloccano altri tipi di traffico.

Queste politiche non sono destinate a bloccare tutto, né necessariamente soddisfano da sole i requisiti di conformità. Sono intesi come un punto di partenza e devono essere modificati per soddisfare i tuoi casi di utilizzo univoci. Per ulteriori informazioni, consultare il file README.

Ogni volta che le nuove ubicazioni per IBM Cloud Kubernetes Service e altri IBM Cloud sono abilitate, le sottoreti per queste ubicazioni vengono aggiunte alle politiche Calico. Assicuratevi di tenere d'occhio il repository GitHub per eventuali aggiornamenti a queste politiche.

Si noti che non consigliamo 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. Se desideri controllare il traffico da e verso i pod, dovresti utilizzare Kubernetes NetworkPolicy e indirizzare il traffico verso namespace e pod specifici, anziché ricorrere a queste policy 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 criteri di rete " Kubernetes " per isolare i microservizi delle applicazioni gli uni dagli altri all'interno di uno stesso spazio dei nomi o tra spazi dei nomi diversi.

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.

Prima di iniziare, installa e configurare la CLI Calico e imposta il contesto per il tuo cluster per eseguire i comandi 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 verranno immediatamente accettate, 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 che indica tutto il traffico in entrata e non si riferisce esclusivamente al traffico proveniente dall'ALB di ingresso 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 poiché 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 policy di ordine molto elevato, come 3000, viene effettivamente applicata per ultima, dopo che sono state applicate tutte le policy di ordine inferiore. I pacchetti di richiesta in entrata passano attraverso 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. Se utilizzi un computer Windows, includi l'opzione " --config=<filepath>/calicoctl.cfg ".

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

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.