Utilisation des règles de réseau Calico pour contrôler le trafic sur les clusters Classic

Apprenez à utiliser des stratégies Calico pour autoriser le trafic réseau depuis et vers certaines adresses IP.

Notez que les étapes suivantes sont destinées aux clusters Classic avec Classic LoadBalancers.

Par défaut, les services Kubernetes NodePort, LoadBalancer et Ingress rendent votre application accessible au public et à toutes les interfaces réseau du cluster publiques et privées. La règle réseau Calico par défaut allow-node-port-dnat autorise le trafic entrant en provenance des services NodePort, d'équilibreur de charge de réseau (NLS) et d'équilibreur de charge d'application (ALB) Ingress vers les pods d'application exposés par ces services. Kubernetes utilise la conversion d'adresse réseau de destination (DNAT) pour transférer les demandes de service aux pods appropriés.

Cependant, pour des raisons de sécurité, vous pouvez être amené à autoriser le trafic vers les services de réseau uniquement à partir de certaines adresses IP source. Vous pouvez utiliser les politiques de pré-DNAT d' Calico, pour autoriser ou bloquer le trafic en provenance ou à destination de certaines adresses IP. Les règles Pre-DNAT empêchent le trafic d'atteindre vos applications car elles sont appliquées avant que Kubernetes utilise la fonction DNAT standard pour acheminer le trafic vers les pods. Lorsque vous créez des règles Pre-DNAT Calico, vous choisissez d'autoriser ou de bloquer les adresses IP source. Pour la plupart des scénarios, l'autorisation d'un trafic spécifique fournit la configuration la plus sûre, car tout le trafic est bloqué, à l'exception du trafic provenant des adresses IP sources connues et autorisées.

Dans ce scénario, vous jouez le rôle d'un administrateur réseau pour une entreprise de relations publiques et vous constatez l'arrivée de trafic inhabituel dans vos applications. Les leçons de ce tutoriel vous guident dans le processus de création d'un modèle d'application de serveur Web, exposant l'application à l'aide d'un service d'équilibreur de charge de réseau (NLB) et protégeant l'application contre le trafic inhabituel indésirable avec des stratégies Calico de liste autorisée et de liste rouge.

Objectifs

Apprendre à bloquer tout le trafic entrant sur tous les ports de noeud en créant une règle Pre-DNAT de poids fort.
Apprendre à autoriser des adresses IP source spécifiques à accéder à l'adresse IP publique et au port du service d'équilibreur de charge de réseau (NLB) en créant une règle Pre-DNAT de poids faible. Les règles de poids faible remplacent les règles de poids fort.
Apprendre à bloquer des adresses IP source spécifiques pour les empêcher d'accéder à l'adresse IP publique et au port de l'équilibreur de charge de réseau (NLB) en créant une règle Pre-DNAT de poids faible.

Public ciblé

Ce tutoriel est destiné aux développeurs de logiciel et aux administrateurs réseau souhaitant gérer le trafic réseau vers une application.

Prérequis

Créez un cluster classique avec au moins 3 nœuds worker. Les clusters de noeuds worker uniques ne disposent pas des ressources requises pour exécuter ce tutoriel. Ce tutoriel n'est pas disponible pour les clusters VPC.
Connectez-vous à votre compte. Le cas échéant, ciblez le groupe de ressources approprié. Définissez le contexte de votre cluster.
Installez et configurez l'interface de ligne de commande de Calico.
Vérifiez que vous disposez des règles d'accès IBM Cloud IAM suivantes pour IBM Cloud Kubernetes Service :
- N'importe quel rôle d'accès à la plateforme
- Rôle d'accès au service Auteur ou Responsable

Déploiement d'une application et exposition de cette application à l'aide d'un NLB

La première leçon vous montre comment est exposée votre application depuis plusieurs adresses IP et ports et par où passe le trafic public pour atteindre votre cluster.

Commencez par déployer un modèle d'application de serveur Web à utiliser tout au long de ce tutoriel. Le serveur Web echoserver présente les données de la connexion établie avec le cluster à partir du client et vous pouvez tester l'accès au cluster de l'entreprise de relations publiques (RP). Exposez ensuite l'application en créant un service d'équilibreur de charge de réseau (NLB) 1.0. Un service NLB 1.0 rend votre application accessible via l'adresse IP du service NLB et les ports de noeud des noeuds worker.

À la fin de la leçon 1, l'application du serveur Web est exposée à Internet par le port du nœud public et le NLB public.

Déployez le modèle d'application de serveur Web. Lorsqu'une connexion à l'application de serveur Web est établie, l'application répond avec les en-têtes HTTP qu'elle a reçus dans la connexion.
```
kubectl apply -f https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/webserver.yaml
```

Vérifiez que la zone STATUS des pods de l'application de serveur Web a la valeur Running.

kubectl get pods -o wide

Exemple de sortie

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

Pour exposer l'application sur l'Internet public, créez un fichier de configuration de service d'équilibreur de charge de réseau 1.0 nommé webserver-lb.yaml dans un éditeur de texte.

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.

Déployez l'équilibreur de charge de réseau.
```
kubectl apply -f filepath/webserver-lb.yaml
```
Vérifiez que vous disposez d'un accès public à l'application qui est exposée par l'équilibreur de charge de réseau à partir de votre ordinateur.
1. Procurez-vous l'adresse EXTERNAL-IP de l'équilibreur de charge de réseau.
```
kubectl get svc -o wide
```
  Exemple de sortie
```
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. Créez un fichier aide-mémoire et copiez l'adresse IP de l'équilibreur de charge de réseau dans ce fichier texte. Cet aide-mémoire vous aidera à retrouver plus rapidement des valeurs dans les leçons suivantes.
3. Vérifiez que vous disposez d'un accès public à l'adresse IP externe de l'équilibreur de charge de réseau.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
  L'exemple de sortie suivante confirme que l'équilibreur de charge de réseau expose votre application sur son adresse IP publique 169.1.1.1. L'application webserver-855556f688-76rkp a reçu la requête 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-
```
Vérifiez que vous disposez d'un accès public à l'application qui est exposée par le port de noeud à partir de votre ordinateur. Un service NLB rend votre application accessible via son adresse IP et les ports de noeud des noeuds worker.
1. Procurez-vous le port de noeud que l'équilibreur de charge de réseau a affecté aux noeuds worker. La valeur du port de noeud est comprise entre 30000 et 32767.
```
kubectl get svc -o wide
```
  Dans la sortie de l'exemple suivant, la valeur du port de noeud est 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. Pour les clusters classiques, obtenez l'adresse IP publique d'un noeud worker. Pour les clusters VPC, obtenez à la place l'adresse IP privée.
```
ibmcloud ks worker ls --cluster <cluster_name>
```
  Exemple de sortie
```
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.32_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w2   169.xx.xxx.xxx   10.176.48.79   u3c.2x4.encrypted   normal   Ready    dal10   1.32_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w3   169.xx.xxx.xxx   10.176.48.78   u3c.2x4.encrypted   normal   Ready    dal10   1.32_1513*   
```
3. Copiez l'adresse IP publique du noeud worker et le port de noeud dans votre aide-mémoire pour les utiliser dans les leçons suivantes.
4. Vérifiez que vous pouvez accéder à l'adresse IP publique du noeud worker via le port de noeud. Remarque : comme les noeuds worker des clusters VPC n'ont pas d'adresse IP publique, vous pouvez accéder à une application via un port de nœud uniquement si vous êtes connecté à votre réseau VPC privé, par exemple, via une connexion VPN. Vous pouvez ensuite utiliser l'adresse IP privée du nœud worker et le port de nœud : <worker_private_IP>:<NodePort>.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
  L'exemple de sortie suivant confirme que la demande transmise à votre application provient de l'adresse IP privée 10.1.1.1 du noeud worker et du port de noeud 31024. Le pod d'application webserver-855556f688-xd849 a reçu la demande 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 ce stade, votre application est exposée à partir de plusieurs ports et adresses IP. La plupart de ces adresses IP sont internes au cluster et sont accessibles uniquement via le réseau privé. Seuls le port de noeud public et le port de l'équilibreur de charge de réseau public sont exposés sur l'Internet public.

Ensuite, vous pouvez commencer à créer et appliquer des stratégies Calico pour bloquer le trafic public.

Blocage de tout le trafic entrant sur tous les ports de noeud

Pour sécuriser le cluster de l'entreprise de relations publiques, vous devez bloquer l'accès public au service NLB et aux ports de noeud qui exposent votre application. Commencez par bloquer l'accès aux ports de noeud.

À la fin de la leçon 2, l'application du serveur web est exposée à l'internet par le NLB public uniquement.

Dans un éditeur de texte, créez une règle Pre-DNAT de poids fort nommée deny-nodeports.yaml pour refuser le trafic entrant TCP et UDP provenant d'une adresse IP source vers tous les ports de noeud.

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

Appliquez la politique.

Linux:

calicoctl apply -f filepath/deny-nodeports.yaml

Windows et OS X :

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

Exemple de sortie

Successfully applied 1 'GlobalNetworkPolicy' resource(s)

En utilisant les valeurs de votre aide-mémoire, vérifiez que vous ne disposez d'aucun accès public à l'adresse IP publique du noeud worker et au port de noeud.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
La connexion arrive à expiration car la règle Calico que vous avez créée bloque le trafic vers les ports de noeud.
```
curl: (28) Connection timed out after 10016 milliseconds
```
Remplacez la politique de trafic externe Cluster, de l'équilibreur de charge que vous avez créé dans la leçon précédente, par Local. Local garantit que l'adresse IP source de votre système est préservée lorsque vous récupérez (curl) l'adresse IP externe de l'éqilibreur de charge dans l'étape suivante.
```
kubectl patch svc webserver-lb -p '{"spec":{"externalTrafficPolicy":"Local"}}'
```
En utilisant la valeur de votre aide-mémoire, vérifiez que vous bénéficiez toujours de l'accès public à l'adresse IP externe de l'équilibreur de charge de réseau.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Exemple de sortie
```
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-
```
Dans la section Request Information de la sortie, l'adresse IP source est, par exemple, client_address=1.1.1.1. L'adresse IP source est l'adresse IP publique du système que vous utilisez pour exécuter la commande curl. Autrement, si vous vous connectez à Internet via un proxy ou un réseau privé virtuel (VPN), le proxy ou le VPN peut rendre illisible l'adresse IP réelle de votre système. Dans les deux cas, l'équilibreur de charge de réseau voit l'adresse IP source de votre système en tant qu'adresse IP client.
Copiez l'adresse IP source de votre système (client_address=1.1.1.1 figurant dans la sortie de l'étape précédente) dans votre aide-mémoire pour l'utiliser dans les leçons suivantes.

Parfait ! A ce stade, votre application est exposée sur l'Internet public uniquement à partir du port de l'équilibreur de charge de réseau public. Le trafic vers les ports de noeud publics est bloqué. Votre cluster est en partie verrouillé par rapport au trafic indésirable.

Ensuite, vous pouvez créer et appliquer des stratégies Calico pour autoriser le trafic en provenance de certaines adresses IP source.

Autorisation de trafic entrant à partir d'une adresse IP spécifique vers l'équilibreur de charge de réseau

A présent, vous décidez de bloquer l'intégralité du trafic vers le cluster de l'entreprise de relations publiques et de tester l'accès en autorisant uniquement l'adresse IP de votre ordinateur.

Tout d'abord, en plus des ports de noeud, vous devez bloquer tout le trafic entrant vers l'équilibreur de charge de réseau qui expose l'application. Ensuite, vous pouvez créer une règle qui autorise l'adresse IP de votre système. A la fin de la leçon 3, tout le trafic vers les ports de noeud et l'équilibreur de charge de réseau publics est bloqué et seul le trafic en provenance de l'adresse IP de votre système autorisée est autorisé.

Dans un éditeur de texte, créez une règle Pre-DNAT de poids fort nommée deny-lb-port-80.yaml pour refuser tout le trafic TCP et UDP entrant en provenance de n'importe quelle adresse IP source vers l'adresse IP et le port de l'équilibreur de charge de réseau. Remplacez <loadbalancer_IP> par l'adresse IP publique NLB de votre aide-mémoire.

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

Appliquez la politique.

Linux:

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

Windows et OS X :

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

En utilisant la valeur de votre aide-mémoire, vérifiez que vous ne pouvez plus accéder à l'adresse IP publique de l'équilibreur de charge de réseau. La connexion arrive à expiration car la règle Calico que vous avez créée bloque le trafic vers l'équilibreur de charge de réseau.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Dans un éditeur de texte, créez une règle Pre-DNAT de poids faible nommée allowlist.yaml pour autoriser le trafic en provenance de l'adresse IP de votre système vers l'adresse IP et le port de l'équilibreur de charge de réseau. A l'aide des valeurs de votre aide-mémoire, remplacez <loadbalancer_IP> par l'adresse IP publique du NLB et <client_address> par l'adresse IP publique de l'adresse IP source de votre système. Si avez oublié votre adresse IP système, vous pouvez exécuter la commande 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
```

Appliquez la politique.

Linux:

calicoctl apply -f filepath/allowlist.yaml

Windows et OS X :

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

L'adresse IP de votre système est désormais autorisée.

En utilisant la valeur de votre aide-mémoire, vérifiez que vous pouvez désormais accéder à l'adresse IP publique de l'équilibreur de charge de réseau.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Si vous avez accès à un autre système ayant une adresse IP différente, essayez d'accéder à l'équilibreur de charge de réseau à partir de ce système.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
La connexion arrive à expiration car l'adresse IP de ce système n'est pas autorisée.

A ce stade, tout le trafic vers les ports de noeud publics et l'équilibreur de charge de réseau est bloqué. Seul le trafic en provenance de votre adresse IP système autorisée est autorisé.

Refus d'accès entrant en provenance d'adresses IP spécifiques vers l'équilibreur de charge de réseau

Dans la leçon précédente, vous avez bloqué tout le trafic et autorisé uniquement quelques adresses IP. Ce scénario fonctionne bien à des fins de test lorsque vous voulez limiter l'accès à quelques adresses IP source contrôlées. Cependant, l'entreprise de relations publiques dispose d'applications qui nécessitent une plus grande ouverture au public. Vous devez veiller à ce que tout le trafic soit autorisé sauf le trafic inhabituel que vous voyez en provenance de quelques adresses IP. L'utilisation d'une liste d'exclusion est utile dans un scénario de ce type car elle vous permet d'éviter toute attaque en provenance d'un petit groupe d'adresses IP.

Dans cette leçon, vous bloquez le trafic depuis l'adresse IP source de votre propre système. A la fin de la leçon 4, tout le trafic vers les ports de noeud publics sera bloqué et tout le trafic vers l'équilibreur de charge de réseau public sera autorisé. Seul le trafic en provenance de votre adresse IP système spécifique vers l'équilibreur de charge de réseau sera bloqué.

Supprimez les règles d'inscription sur liste autorisée que vous avez créées dans la leçon précédente.
- Linux:
```
calicoctl delete GlobalNetworkPolicy deny-lb-port-80
```
```
calicoctl delete GlobalNetworkPolicy allowlist
```
- Windows et OS X :
```
calicoctl delete GlobalNetworkPolicy deny-lb-port-80 --config=filepath/calicoctl.cfg
```
```
calicoctl delete GlobalNetworkPolicy allowlist --config=filepath/calicoctl.cfg
```
Désormais, tout le trafic TCP et UDP entrant en provenance de n'importe quelle adresse IP source vers l'adresse IP et le port de l'équilibreur de charge de réseau est à nouveau autorisé.

Pour refuser tout le trafic TCP et UDP entrant en provenance de l'adresse IP source de votre système vers l'adresse IP et le port de l'équilibreur de charge de réseau, créez une règle Pre-DNAT de poids faible nommée blocklist.yaml dans un éditeur de texte. A l'aide des valeurs de votre aide-mémoire, remplacez <loadbalancer_IP> par l'adresse IP publique du NLB et <client_address> par l'adresse IP publique de l'adresse IP source de votre système.

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

Appliquez la politique.

Linux:

calicoctl apply -f filepath/blocklist.yaml

Windows et OS X :

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

L'adresse IP de votre système est désormais bloquée.

En utilisant la valeur de votre aide-mémoire, vérifiez sur votre système que vous ne pouvez pas accéder à l'adresse IP de l'équilibreur de charge de réseau car l'adresse IP de votre système est bloquée.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
A ce stade, tout le trafic vers les ports de noeud public est bloqué et tout le trafic vers l'équilibreur de charge de réseau public est autorisé. Seul le trafic en provenance de votre adresse IP système spécifique vers l'équilibreur de charge de réseau sera bloqué.

Parfait ! Vous avez réussi à contrôler le trafic dans votre application en utilisant des règles Pre-DNAT Calico pour bloquer des adresses IP source.

Journalisation du trafic bloqué en provenance d'adresses IP spécifiques vers l'équilibreur de charge de réseau

Dans la leçon précédente, vous avez bloqué le trafic entre l'adresse IP de votre système et l'équilibreur de charge de réseau. Dans cette leçon, vous allez apprendre à consigner les demandes de trafic refusé.

Dans ce scénario, l'agence de relations publiques pour laquelle vous travaillez souhaite que vous mettiez en place une piste d'audit pour tout trafic inhabituel qui est continuellement refusé par l'une de vos politiques réseau. Pour surveiller cette menace de sécurité potentielle, configurez la journalisation de manière à enregistrer toutes les fois qu'une règle d'inscription sur liste rouge refuse une action intentée sur l'adresse IP d'équilibreur de charge de réseau.

Créez une règle réseau Calico nommée log-denied-packets. Cette règle de journal utilise le même sélecteur que la règle blocklist, qui ajoute cette règle à la chaîne de règles Iptables Calico. En utilisant un numéro d'ordre plus faible, tel que 300, vous pouvez garantir que cette règle est ajoutée à la chaîne de règles Iptables avant la règle d'inscription sur liste rouge. Les paquets provenant de votre adresse IP sont consignés par cette règle avant de tenter d'établir une correspondance avec la règle conditionnelle blocklist et d'être refusés.

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

Appliquez la politique.

Linux:

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

Windows et OS X :

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

Générez des entrées de journal en envoyant des paquets depuis l'adresse IP de votre système vers l'adresse IP de l'équilibreur de charge de réseau. Ces paquets de requêtes sont consignés avant d'être refusés.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

Recherchez les entrées de journal qui sont écrites dans le chemin /var/log/syslog. L'entrée de journal se présente comme suit :

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

Bien ! Vous avez configuré la journalisation de sorte que le trafic bloqué puisse être surveillé plus facilement.

Si vous souhaitez nettoyer les règles de liste rouge et de journal :

Nettoyez la règle de liste rouge.

Linux:

calicoctl delete GlobalNetworkPolicy blocklist

Windows et OS X :

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

Nettoyez la règle de journal.

Linux:

calicoctl delete GlobalNetworkPolicy log-denied-packets

Windows et OS X :

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

Étape suivante ?

En savoir plus sur comment contrôler le trafic avec des règles réseau.
Pour d'autres exemples de règles réseau Calico qui contrôlent le trafic vers et depuis votre cluster, vous pouvez consulter les tutorielsCalico.