Utilizzo delle politiche di rete di Calico per controllare il traffico sui cluster Classic

Impara come utilizzare le politiche Calico per consentire il traffico di rete da e verso specifici indirizzi IP.

Si noti che i passaggi seguenti riguardano i cluster classici con LoadBalancers.

Per impostazione predefinita, i servizi Ingress, LoadBalancer e NodePort Kubernetes rendono la tua applicazione disponibile su tutte le interfacce di rete cluster private e pubbliche. La politica Calico predefinita allow-node-port-dnat consente il traffico in entrata dai servizi NodePort, NLB (network load balancer) e ALB (application load balancer) Ingress ai pod dell'applicazione esposti da questi servizi. Kubernetes utilizza la conversione degli indirizzi di rete di destinazione (o DNAT, destination network address translation) per inoltrare le richieste di servizio ai pod corretti.

Tuttavia, per motivi di sicurezza, potresti dover consentire il traffico ai servizi di rete solo da specifici indirizzi IP di origine. È possibile utilizzare i criteri Pre-DNAT di Calico per consentire o bloccare il traffico da o verso determinati indirizzi IP. Le politiche pre-DNAT impediscono al traffico specificato di raggiungere le tue applicazioni perché vengono applicate prima che Kubernetes utilizzi la DNAT regolare per inoltrare il traffico ai pod. Quando crei delle politiche pre-DNAT Calico, scegli se consentire o bloccare gli indirizzi IP di origine. Per la maggior parte degli scenari, l'abilitazione di un traffico specifico fornisce la configurazione più sicura perché tutto il traffico è bloccato tranne il traffico da indirizzi IP di origine noti e consentiti. negare il traffico specifico è di solito utile solo in scenari come la prevenzione di un attacco da una piccola serie di indirizzi IP.

In questo scenario, hai il ruolo di amministratore di rete per una società di PR e noti del traffico insolito verso le tue applicazioni. Le lezioni in questa esercitazione ti guidano nella creazione di un'applicazione server web di esempio, nell'esposizione dell'applicazione utilizzando un servizio NLB (network load balancer) e nella protezione dell'applicazione da traffico insolito e indesiderato con entrambe le politiche Calico di allowlist e blocklist.

Obiettivi

Impara a bloccare tutto il traffico in entrata per tutte le porte del nodo creando una politica pre-DNAT di ordine superiore.
Impara a consentire a specifici indirizzi IP di origine di accedere all'IP e alla porta pubblici dell'NLB creando una politica pre-DNAT di basso livello. Le politiche di basso livello sovrascrivono le politiche di ordine superiore.
Impara a bloccare per specifici indirizzi IP di origine l'accesso all'IP e alla porta pubblici dell'NLB creando una politica pre-DNAT di basso livello.

Destinatari

Questa esercitazione è destinata agli sviluppatori di software e agli amministratori di rete che vogliono gestire il traffico di rete a un'applicazione.

Prerequisiti

Crea un cluster classico con minimo 3 nodi di lavoro. I singoli cluster di nodi di lavoro non hanno le risorse richieste per completare questa esercitazione. Questa esercitazione non è disponibile per i cluster VPC.
Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.
Installa e configura la CLI Calico.
Assicurati di disporre delle seguenti politiche di accesso IBM Cloud IAM per IBM Cloud Kubernetes Service:
- Qualsiasi ruolo di accesso alla piattaforma
- Il ruolo di accesso al servizio Scrittore o Gestore

Distribuisci un'applicazione ed esponila utilizzando un NLB

La prima lezione ti mostra in che modo la tua applicazione viene esposta da molteplici indirizzi IP e porte e da dove proviene il traffico pubblico nel tuo cluster.

Inizia distribuendo un'applicazione webserver di esempio da utilizzare in tutta l'esercitazione. Il server web echoserver mostra i dati sulla connessione che si stabilisce al cluster dal client e puoi testare l'accesso al cluster della società di PR. Esponi quindi l'applicazione creando un servizio NLB (network load balancer) 1.0. Un servizio NLB 1.0 rende la tua applicazione disponibile sia sull'indirizzo IP dell'NLB che sulle porte del nodo dei nodi di lavoro.

Al termine della lezione 1, l'applicazione server web è esposta a Internet tramite la porta pubblica del nodo e l'NLB pubblico.

Distribuisci l'applicazione webserver di esempio. Quando viene stabilita una connessione all'applicazione webserver, essa risponde con le intestazioni HTTP che aveva ricevuto nella connessione.
```
kubectl apply -f https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/webserver.yaml
```

Verifica che i pod dell'applicazione webserver abbiano una condizione (STATUS) di Running.

kubectl get pods -o wide

Output di esempio

NAME                         READY     STATUS    RESTARTS   AGE       IP               NODE
webserver-855556f688-6dbsn   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78
webserver-855556f688-76rkp   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78
webserver-855556f688-xd849   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78

Per esporre l'applicazione a internet pubblico, crea un file di configurazione del servizio NLB 1.0 denominato webserver-lb.yaml in un editor di testo.

apiVersion: v1
kind: Service
metadata:
  labels:
    run: webserver                               
  name: webserver-lb
spec:
  type: LoadBalancer
  selector:
    run: webserver
  ports:
  - name: webserver-port
    protocol: TCP
    port: 8080
    targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.

Distribuisci l'NLB.

kubectl apply -f filepath/webserver-lb.yaml

Verifica di poter accedere pubblicamente all'applicazione esposta dall'NLB dal tuo computer.

Ottieni l'indirizzo EXTERNAL-IP pubblico dell'NLB.

kubectl get svc -o wide

Output di esempio

NAME           CLUSTER-IP       EXTERNAL-IP        PORT(S)        AGE       SELECTOR
webserver-lb   172.21.xxx.xxx   169.xx.xxx.xxx     80:31024/TCP   2m        run=webserver

Crea un file di testo di scheda di riferimento e copia in esso l'IP dell'NLB. La scheda di riferimento ti aiuta a usare più rapidamente i valori nelle lezioni successive.

Verifica di poter accedere pubblicamente all'IP esterno per l'NLB.

curl --connect-timeout 10 <loadbalancer_IP>:80

Il seguente output di esempio conferma che l'NLB espone la tua applicazione sull'indirizzo IP dell'NLB pubblico 169.1.1.1. L'app pod webserver-855556f688-76rkp ha ricevuto la richiesta curl.

Hostname: webserver-855556f688-76rkp
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=10.176.XX.XX
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://169.1.1.1:8080/
Request Headers:
    accept=*/*
    host=169.1.1.1
    user-agent=curl/7.54.0
Request Body:
    -no body in request-

Verifica di poter accedere pubblicamente all'applicazione esposta dalla porta del nodo dal tuo computer. Un servizio NLB rende la tua applicazione disponibile sia sull'indirizzo IP del servizio NLB che sulle porte del nodo dei nodi di lavoro.
1. Ottieni la porta del nodo che l'NLB ha assegnato ai nodi di lavoro. La porta del nodo è compresa nell'intervallo 30000 - 32767.
```
kubectl get svc -o wide
```
  Nel seguente output di esempio, la porta del nodo è 31024:
```
NAME           CLUSTER-IP       EXTERNAL-IP        PORT(S)        AGE       SELECTOR
webserver-lb   172.21.xxx.xxx   169.xx.xxx.xxx     80:31024/TCP   2m        run=webserver
```
2. Per i cluster classici, ottieni l'indirizzo IP pubblico (Public IP) di un nodo di lavoro. Per i cluster VPC, ottieni invece l'indirizzo IP privato (Private IP).
```
ibmcloud ks worker ls --cluster <cluster_name>
```
  Output di esempio
```
ID                                                 Public IP        Private IP     Machine Type        State    Status   Zone    Version   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w1   169.xx.xxx.xxx   10.176.48.67   u3c.2x4.encrypted   normal   Ready    dal10   1.35_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w2   169.xx.xxx.xxx   10.176.48.79   u3c.2x4.encrypted   normal   Ready    dal10   1.35_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w3   169.xx.xxx.xxx   10.176.48.78   u3c.2x4.encrypted   normal   Ready    dal10   1.35_1513*   
```
3. Copia l'IP pubblico del nodo di lavoro e la porta del nodo nella tua scheda di riferimento testuale per un utilizzo nelle lezioni successive.
4. Verifica di poter accedere all'indirizzo IP pubblico del nodo di lavoro tramite la porta del nodo. Nota: poiché i nodi worker nei cluster VPC non hanno un indirizzo IP pubblico, è possibile accedere a un'applicazione tramite NodePort solo se si è connessi alla rete VPC privata, ad esempio tramite una connessione VPN. Quindi, è possibile utilizzare l'indirizzo IP privato del nodo worker e NodePort: <worker_private_IP>:<NodePort>.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
  Il seguente output di esempio conferma che la richiesta alla tua applicazione è arrivata tramite l'indirizzo IP privato 10.1.1.1 per il nodo di lavoro e la porta del nodo 31024. Il pod dell'applicazione webserver-855556f688-xd849 ha ricevuto la richiesta curl:
```
Hostname: webserver-855556f688-xd849
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=1.1.1.1
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://10.1.1.1:8080/
Request Headers:
    accept=*/*
    host=10.1.1.1:31024
    user-agent=curl/7.60.0
Request Body:
    -no body in request-
```

A questo punto, la tua applicazione è esposta a molteplici indirizzi IP e porte. La maggior parte di questi IP è interna al cluster ed è possibile accedervi solo sulla rete privata. Solo la porta del nodo pubblico e la porta dell'NLB pubblico sono esposte a internet pubblico.

Puoi quindi iniziare a creare ed applicare politiche Calico per bloccare il traffico pubblico.

Blocca tutto il traffico in entrata a tutte le porte del nodo

Per proteggere il cluster dell'agenzia di PR, devi bloccare l'accesso pubblico sia al servizio NLB che alle porte del nodo che stanno esponendo la tua applicazione. Inizia bloccando l'accesso alle porte del nodo.

Alla fine della Lezione 2, l'applicazione server web è esposta a Internet solo tramite NLB pubblico.

In un editor di testo, crea una politica pre-DNAT di ordine superiore denominata deny-nodeports.yaml per negare il traffico TCP e UDP in entrata da qualsiasi IP di origine a tutte le porte del nodo.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-nodeports
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      ports:
      - 30000:32767
    protocol: TCP
    source: {}
  - action: Deny
    destination:
      ports:
      - 30000:32767
    protocol: UDP
    source: {}
  selector: ibm.role=='worker_public'
  order: 1100
  types:
  - Ingress

Applica la politica.

Linux:

calicoctl apply -f filepath/deny-nodeports.yaml

Windows e OS X:

calicoctl apply -f filepath/deny-nodeports.yaml --config=filepath/calicoctl.cfg

Output di esempio

Successfully applied 1 'GlobalNetworkPolicy' resource(s)

Utilizzando i valori dalla tua scheda di riferimento, verifica di non poter accedere pubblicamente alla porta del nodo e all'indirizzo IP pubblico del nodo di lavoro.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
La connessione va in timeout perché la politica Calico da te creata sta bloccando il traffico alle porte del nodo.
```
curl: (28) Connection timed out after 10016 milliseconds
```
Cambiare la externalTrafficPolicy del LoadBalancer creato nella lezione precedente da Cluster a Local. Local assicura che l'IP di origine del sistema sia conservato quando si ricorre all'IP esterno del LoadBalancer nel passaggio successivo.
```
kubectl patch svc webserver-lb -p '{"spec":{"externalTrafficPolicy":"Local"}}'
```
Utilizzando il valore dalla tua scheda di riferimento, verifica di potere ancora accedere pubblicamente all'indirizzo IP esterno dell'NLB.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Output di esempio
```
Hostname: webserver-855556f688-76rkp
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=1.1.1.1
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://<loadbalancer_IP>:8080/
Request Headers:
    accept=*/*
    host=<loadbalancer_IP>
    user-agent=curl/7.54.0
Request Body:
    -no body in request-
```
Nella sezione Request Information dell'output, l'indirizzo IP di origine è, ad esempio, client_address=1.1.1.1. L'indirizzo IP di origine è l'IP pubblico del sistema che stai utilizzando per eseguire curl. Altrimenti, se ti stai collegando a Internet tramite un proxy o una VPN, è possibile che questi ultimi stiano oscurando l'indirizzo IP effettivo del tuo sistema. In entrambi i casi, l'NLB vede l'indirizzo IP di origine del tuo sistema come indirizzo IP del client.
Copia l'indirizzo IP di origine del sistema (client_address=1.1.1.1 nell'output del passo precedente) nella tua scheda di riferimento per utilizzarlo nelle lezioni successive.

Bene! A questo punto, la tua applicazione è esposta a internet pubblico solo dalla porta dell'NLB pubblico. Il traffico alle porte del nodo pubblico è bloccato. Il tuo cluster è parzialmente bloccato al traffico indesiderato.

Puoi quindi creare e applicare politiche Calico per consentire il traffico solo da specifici IP di origine.

Consenti il traffico in entrata da uno specifico IP all'NLB

Ora decidi di bloccare completamente il traffico al cluster dell'agenzia di PR e di testare l'accesso consentendo solo l'indirizzo IP del tuo computer.

Per prima cosa, oltre alle NodePort, devi bloccare tutto il traffico in entrata all'NLB che espone l'applicazione. Puoi quindi creare una politica che consente l'indirizzo IP del tuo sistema. Al termine della Lezione 3, tutto il traffico verso le porte dei nodi pubblici e NLB è bloccato e solo il traffico proveniente dall'IP di sistema consentito è permesso.

In un editor di testo, crea una politica pre-DNAT di ordine superiore denominata deny-lb-port-80.yaml per negare tutto il traffico TCP e UDP in entrata da qualsiasi IP di origine all'indirizzo IP e alla porta dell'NLB. Sostituire <loadbalancer_IP> con l'indirizzo IP pubblico di NLB del foglio informativo.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-lb-port-80
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source: {}
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source: {}
  selector: ibm.role=='worker_public'
  order: 800
  types:
  - Ingress

Applica la politica.

Linux:

calicoctl apply -f filepath/deny-lb-port-80.yaml

Windows e OS X:

calicoctl apply -f filepath/deny-lb-port-80.yaml --config=filepath/calicoctl.cfg

Utilizzando il valore dalla tua scheda di riferimento, verifica che ora non puoi accedere all'indirizzo IP dell'NLB pubblico. La connessione va in timeout perché la politica Calico da te creata sta bloccando il traffico all'NLB.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

In un editor di testo, crea una politica pre-DNAT di basso livello denominata allowlist.yaml per consentire il traffico dall'IP del tuo sistema all'indirizzo IP e alla porta dell'NLB. Utilizzando i valori del foglio di calcolo, sostituire <loadbalancer_IP> con l'indirizzo IP pubblico dell'NLB e <client_address> con l'indirizzo IP pubblico dell'IP di origine del sistema. Se non riesci a ricordarti il tuo IP di sistema, puoi eseguire curl ifconfig.co.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allowlist
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Allow
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 500
  types:
  - Ingress

Applica la politica.

Linux:

calicoctl apply -f filepath/allowlist.yaml

Windows e OS X:

calicoctl apply -f filepath/allowlist.yaml --config=filepath/calicoctl.cfg

L'indirizzo IP del tuo sistema è ora consentito.

Utilizzando il valore dalla tua scheda di riferimento, verifica che ora puoi accedere all'indirizzo IP dell'NLB pubblico.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Se hai accesso a un altro sistema che ha un indirizzo IP differente, prova ad accedere all'NLB da tale sistema.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
La connessione va in timeout perché l'indirizzo IP del sistema non è consentito.

A questo punto, tutto il traffico all'NLB e alle porte del nodo pubblici è bloccato. È consentito solo il traffico dal tuo IP di sistema consentito.

Rifiuta il traffico in entrata da specifici IP all'NLB

Nella lezione precedente, hai bloccato tutto il traffico e consentito solo alcuni IP. Tale scenario funziona bene per scopi di test quando vuoi limitare l'accesso solo a pochi indirizzi IP di origine controllati. Tuttavia, l'agenzia di PR ha delle applicazioni che devono essere ampiamente disponibili per il pubblico. Devi assicurarti che sia consentito tutto il traffico, fatta eccezione per il traffico insolito che vedi da qualche indirizzo IP. Una denylist è utile in uno scenario come questo perché può aiutare a prevenire un attacco da un piccolo insieme di indirizzi IP.

In questa lezione, blocchi il traffico dall'indirizzo IP di origine del tuo sistema. Alla fine della Lezione 4, tutto il traffico alle porte del nodo pubblico è bloccato e tutto il traffico all'NLB pubblico è consentito. Viene bloccato solo il traffico dal tuo IP di sistema specifico all'NLB.

Elimina le politiche di elenco di elementi consentiti (allowlist) che hai creato nella lezione precedente.

Linux:

calicoctl delete GlobalNetworkPolicy deny-lb-port-80

calicoctl delete GlobalNetworkPolicy allowlist

Windows e OS X:

calicoctl delete GlobalNetworkPolicy deny-lb-port-80 --config=filepath/calicoctl.cfg

calicoctl delete GlobalNetworkPolicy allowlist --config=filepath/calicoctl.cfg

Ora tutto il traffico TCP e UDP in entrata da qualsiasi IP di origine all'indirizzo IP e alla porta dell'NLB è nuovamente consentito.

Per negare tutto il traffico TCP e UDP in entrata dall'indirizzo IP di origine del tuo sistema all'indirizzo IP e alla porta dell'NLB, crea una politica pre-DNAT di basso livello denominata blocklist.yaml in un editor di testo. Utilizzando i valori del foglio di calcolo, sostituire <loadbalancer_IP> con l'indirizzo IP pubblico dell'NLB e <client_address> con l'indirizzo IP pubblico dell'IP di origine del sistema.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: blocklist
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source:
      nets:
      - <client_address>/32
 selector: ibm.role=='worker_public'
 order: 500
 types:
 - Ingress

Applica la politica.

Linux:

calicoctl apply -f filepath/blocklist.yaml

Windows e OS X:

calicoctl apply -f filepath/blocklist.yaml --config=filepath/calicoctl.cfg

L'indirizzo IP del tuo sistema è ora bloccato.

Utilizzando il valore dalla tua scheda di riferimento, verifica dal tuo sistema che non puoi accedere all'IP dell'NLB perché l'IP del tuo sistema è bloccato.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
A questo punto, tutto il traffico alle porte del nodo pubblico è bloccato e tutto il traffico all'NLB pubblico è consentito. Viene bloccato solo il traffico dal tuo IP di sistema specifico all'NLB.

Ottimo lavoro! Hai controllato con successo il traffico nella tua applicazione utilizzando le politiche pre-DNAT Calico per bloccare gli IP origine.

Registrazione del traffico bloccato da specifici IP all'NLB

Nella lezione precedente, hai bloccato il traffico dal tuo IP di sistema all'NLB. In questa lezione, puoi imparare a registrare le richieste di traffico rifiutate.

In questo scenario di esempio, l'azienda di pubbliche relazioni per cui lavorate vuole che impostiate una traccia di registrazione per qualsiasi traffico insolito che viene continuamente negato da uno dei vostri criteri di rete. Per monitorare la potenziale minaccia alla sicurezza, configuri la registrazione nei log per eseguire una registrazione ogni volta che la politica blocklist rifiuta un'azione tentata sull'IP dell'NLB.

Crea una NetworkPolicy Calico denominata log-denied-packets. Questa politica di log utilizza lo stesso selettore della politica blocklist, che aggiunge questa politica alla catena di regole Iptables Calico. Utilizzando un numero di ordine più basso, come 300, puoi assicurarti che questa regola venga aggiunta alla catena di regole Iptables prima della politica di blocklist. I pacchetti dal tuo IP vengono registrati da questa politica prima che provino la messa in corrispondenza alla regola della politica blocklist e vengano rifiutati.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
    name: log-denied-packets
 spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Log
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  - action: Log
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 300
  types:
  - Ingress

Applica la politica.

Linux:

calicoctl apply -f /log-denied-packets.yaml

Windows e OS X:

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

Genera le voci di log inviando le richieste dal tuo IP di sistema all'IP dell'NLB. Questi pacchetti di richiesta vengono registrati prima di essere rifiutati.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

Controlla la presenza di voci di log scritte nel percorso /var/log/syslog . 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

Ben fatto! Imposti la registrazione in modo che il traffico bloccato possa essere monitorato più facilmente.

Se vuoi ripulire l'elenco di elementi bloccati (blocklist) e le politiche di log:

Ripulisci la politica di blocklist.

Linux:

calicoctl delete GlobalNetworkPolicy blocklist

Windows e OS X:

calicoctl delete GlobalNetworkPolicy blocklist --config=filepath/calicoctl.cfg

Ripulisci la politica di log.

Linux:

calicoctl delete GlobalNetworkPolicy log-denied-packets

Windows e OS X:

calicoctl delete GlobalNetworkPolicy log-denied-packets --config=filepath/calicoctl.cfg

Operazioni successive

Leggi ulteriori informazioni sul controllo del traffico con le politiche di rete.
Per ulteriori politiche di rete Calico di esempio che controllano il traffico da e verso il tuo cluster, puoi controllare le esercitazioniCalico.