Utilización de políticas de red de Calico para controlar el tráfico en los clústeres clásicos

Aprender a utilizar políticas de Calico para permitir el tráfico de red procedente y destinado a determinadas direcciones IP.

Tenga en cuenta que los pasos siguientes son para los clústeres clásicos con equilibradores de carga clásicos.

De forma predeterminada, los servicios Kubernetes NodePort, LoadBalancer e Ingress hacen que la app esté disponible en todas las interfaces de red de clúster públicas y privadas. La política predeterminada de Calico allow-node-port-dnat permite el tráfico de entrada procedente de los servicios de NodePort, equilibrador de carga de red (NLB) y equilibrador de carga de aplicación (ALB) de Ingress a los pods de la app que dichos servicios exponen. Kubernetes utiliza la conversión de direcciones de red de destino (DNAT) para reenviar las solicitudes de servicio a los pods adecuados.

Sin embargo, por motivos de seguridad, es posible que tenga que permitir el tráfico a los servicios de red solo desde determinadas direcciones IP de origen. Puede utilizar las políticas de Pre-DNAT(Calico) para permitir o bloquear el tráfico desde o hacia determinadas direcciones IP. Las políticas Pre-DNAT impiden que el tráfico especificado llegue a sus apps porque se aplican antes de que Kubernetes utilice DNAT normal para reenviar el tráfico a los pods. Cuando se crean políticas Pre-DNAT de Calico, se elige si las direcciones IP de origen se deben permitir o bloquear. Para la mayoría de los casos de ejemplo, permitir un tráfico específico supone la configuración más segura, porque se bloquea todo el tráfico excepto el que procede de direcciones IP de orígenes permitidos y conocidos. Denegar el tráfico específico sólo suele ser útil en situaciones como la prevención de un ataque de un conjunto reducido de direcciones IP.

En este caso de ejemplo, el usuario adopta el rol de administrador de una empresa de relaciones públicas (PR) y observa un tráfico poco habitual que afecta a sus apps. Las lecciones de esta guía de aprendizaje le guían a través de la creación de una app de servidor web de ejemplo, la exposición la app mediante un servicio equilibrador de carga de red (NLB) y protegiendo la app de tráfico no deseado con políticas de Calico de lista de elementos permitidos y de lista de elementos bloqueados.

Objetivos

Aprender a bloquear todo el tráfico entrante a todos los puertos de nodo creando una política de Pre-DNAT de orden superior.
Aprender a permitir el acceso de direcciones IP de origen específicas a IP pública de NLB y al puerto mediante la creación de una política Pre-DNAT de orden inferior. Las políticas de orden inferior tienen preferencia sobre las políticas de orden superior.
Aprender a bloquear el acceso de direcciones IP de origen específicas a la IP pública de NLB y al puerto mediante la creación de una política Pre-DNAT de orden inferior.

Audiencia

Esta guía de aprendizaje está destinada a los desarrolladores de software y administradores de la red que gestionan el tráfico de red a una app.

Requisitos previos

Cree un clúster clásico con al menos 3 nodos de trabajador. Los clústeres de un solo nodo trabajador no tienen los recursos necesarios para completar esta guía de aprendizaje. Esta guía de aprendizaje no está disponible para los clústeres de VPC.
Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
Instale y configure la CLI de Calico.
Asegúrese de tener las políticas de acceso de IBM Cloud IAM siguientes para IBM Cloud Kubernetes Service:
- Cualquier rol de acceso a la plataforma
- El rol de acceso al servicio de Escritor o Gestor

Desplegar una app y exponerla mediante un NLB

En la primera lección se muestra cómo se expone la app desde varias direcciones IP y puertos y de dónde procede el tráfico público que entra en el clúster.

Empiece desplegando una app de servidor web de ejemplo para utilizarla en la guía de aprendizaje. El servidor web echoserver muestra datos sobre la conexión que se establece con el clúster desde el cliente y le deja probar el acceso al clúster de la empresa PR. A continuación, exponga la app creando un servicio de equilibrador de carga de red (NLB) 1.0. Un servicio de NLB 1.0 hace que la app esté disponible a través de la dirección IP de servicio del NLB y de los puertos de nodo de los nodos trabajadores.

Al final de la lección 1, la aplicación del servidor web queda expuesta a Internet por el puerto de nodo público y el NLB público.

Despliegue la app de servidor web de ejemplo. Cuando se establece una conexión con la app de servidor web, la app responde con las cabeceras HTTP que ha recibido en la conexión.
```
kubectl apply -f https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/webserver.yaml
```

Verifique que los pods de la app de servidor web tienen en STATUS el valor Running.

kubectl get pods -o wide

Salida de ejemplo

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

Para exponer la app a internet público, cree un archivo de configuración de servicio de NLB 1.0 denominado webserver-lb.yaml en un editor de texto.

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.

Despliegue el NLB.

kubectl apply -f filepath/webserver-lb.yaml

Verifique que puede acceder públicamente a la app expuesta por el NLB desde el sistema.

Obtenga la dirección EXTERNAL-IP pública del NLB.

kubectl get svc -o wide

Salida de ejemplo

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

Cree un archivo de texto de hoja de apuntes y copie la IP del NLB en el archivo de texto. La hoja de apuntes le ayuda a utilizar valores rápidamente en las lecciones siguientes.

Verifique que puede acceder públicamente a la IP externa correspondiente al NLB.

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

La información de salida del siguiente ejemplo confirma que el NLB expone la app en la dirección IP pública del NLB 169.1.1.1. El pod de aplicación webserver-855556f688-76rkp ha recibido la solicitud de 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-

Verifique que puede acceder públicamente a la app expuesta por el node desde el sistema. Un servicio de NLB hace que la app esté disponible a través de la dirección IP de servicio del NLB y de los puertos de nodo de los nodos trabajadores.
1. Obtenga el puerto de nodo que el NLB ha asignado a los nodos trabajadores. El puerto de nodo se encuentra en el rango comprendido entre 30000 y 32767.
```
kubectl get svc -o wide
```
  En la siguiente información de salida de ejemplo, el puerto de nodo es 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. Para clústeres clásicos, obtenga la dirección IP pública de un nodo trabajador. Para clústeres de VPC, obtenga en su lugar la dirección IP privada.
```
ibmcloud ks worker ls --cluster <cluster_name>
```
  Salida de ejemplo
```
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. Copie la IP pública del nodo trabajador y el puerto de nodo en la hoja de apuntes de texto para utilizarla en lecciones posteriores.
4. Verifique que puede acceder a la dirección IP pública del nodo trabajador a través del puerto de nodo. Nota:: puesto que los nodos de trabajador de los clústeres de VPC no tienen una dirección IP pública, sólo puede acceder a una aplicación a través de un NodePort si está conectado a la red privada de VPC, como por ejemplo a través de una conexión VPN. A continuación, puede utilizar el NodePort y la dirección IP privada del nodo de trabajador: <worker_private_IP>:<NodePort>.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
  La información de salida de ejemplo siguiente confirma que la solicitud a la app se ha recibido a través de la dirección IP privada 10.1.1.1 para el nodo trabajador y el puerto de nodo 31024. El pod de la app webserver-855556f688-xd849 ha recibido la solicitud 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-
```

En este punto, la app está expuesta desde varias direcciones IP y puertos. La mayoría de estas direcciones IP son internas del clúster y solo se puede acceder a ellas a través de la red privada. Solo el puerto de nodo público y el puerto del NLB público están expuestos a Internet público.

A continuación, puede empezar a crear y aplicar políticas de Calico para bloquear el tráfico público.

Bloquear todo el tráfico de entrada a todos los puertos de nodo

Para proteger el clúster de la empresa PR, debe bloquear el acceso público tanto al servicio de NLB como a los puertos de nodo que exponen la app. Empiece bloqueando el acceso a los puertos de nodo.

Al final de la Lección 2, la aplicación de servidor web está expuesta a Internet únicamente mediante NLB público.

En un editor de texto, cree una política Pre-DNAT de orden superior denominada deny-nodeports.yaml para denegar el tráfico TCP y UDP entrante procedente de cualquier IP de origen a todos los puertos de 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

Aplique la política.

Linux:

calicoctl apply -f filepath/deny-nodeports.yaml

Windows y OS X:

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

Salida de ejemplo

Successfully applied 1 'GlobalNetworkPolicy' resource(s)

Utilizando los valores de la hoja de apuntes, verifique que no puede acceder públicamente a la dirección IP pública del nodo trabajador y al puerto de nodo.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
La conexión excede el tiempo de espera porque la política de Calico que ha creado está bloqueando el tráfico a los puertos de nodo.
```
curl: (28) Connection timed out after 10016 milliseconds
```
Cambie el valor de externalTrafficPolicy del equilibrador de carga que ha creado en la lección anterior de Cluster a Local. Local garantiza que la IP de origen del sistema se conserve cuando se utilice curl en la IP externa del equilibrador de carga en el paso siguiente.
```
kubectl patch svc webserver-lb -p '{"spec":{"externalTrafficPolicy":"Local"}}'
```
Utilizando el valor de la hoja de apuntes, verifique que aún puede acceder públicamente a la dirección IP externa del NLB.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Salida de ejemplo
```
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-
```
En la sección Request Information de la información de salida, la dirección IP de origen es, por ejemplo, client_address=1.1.1.1. La dirección IP de origen es la dirección IP pública del sistema que está utilizando para ejecutar curl. De lo contrario, si se está conectando a internet a través de un proxy o VPN, es posible que el proxy o VPN esté ocultando la dirección IP real del sistema. En cualquier caso, el servicio de NLB ve la dirección IP de origen del sistema como la dirección IP del cliente.
Copie la dirección IP de origen del sistema (client_address=1.1.1.1 en la información de salida del paso anterior) en la hoja de apuntes para utilizarla en lecciones posteriores.

Estupendo. En este punto, la app está expuesta a internet público solo desde el puerto público del NLB. El tráfico a los puertos de nodo públicos está bloqueado. El clúster se bloquea parcialmente ante tráfico no deseado.

A continuación, puede crear y aplicar políticas de Calico para permitir solo el tráfico procedentes de determinadas IP de origen.

Permitir el tráfico de entrada procedente de una IP específica al NLB

Supongamos que ahora decide bloquear por completo el tráfico al clúster de la empresa PR y probar el acceso permitiendo solo la dirección IP de su propio sistema.

En primer lugar, además de los puertos de nodo, debe bloquear todo el tráfico entrante al NLB que expone la app. A continuación, puede crear una política que permita la dirección IP de su sistema. Al final de la Lección 3, todo el tráfico a los NLB y puertos de nodo públicos se bloquean y solo se permite el tráfico de la IP de sistema permitida.

En un editor de texto, cree una política Pre-DNAT de orden superior denominada deny-lb-port-80.yaml para denegar todo el tráfico TCP y UDP entrante procedente de cualquier IP de origen a la dirección IP y puerto del NLB. Sustituya <loadbalancer_IP> por la dirección IP pública del NLB de la hoja de apuntes.

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

Aplique la política.

Linux:

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

Windows y OS X:

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

Utilizando el valor de la hoja de apuntes, verifique que ahora no puede acceder a la dirección IP pública del NLB. La conexión excede el tiempo de espera porque la política de Calico que ha creado está bloqueando el tráfico hacia el NLB.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

En un editor de texto, cree una política de Pre-DNAT de orden inferior denominada allowlist.yaml para permitir el tráfico desde la IP del sistema a la dirección IP y puerto del NLB. Utilizando los valores de la hoja de apuntes, sustituya <loadbalancer_IP> por la dirección IP pública del NLB y <client_address> por la dirección IP pública de la IP de origen del sistema. Si no recuerda la IP del sistema, puede ejecutar 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

Aplique la política.

Linux:

calicoctl apply -f filepath/allowlist.yaml

Windows y OS X:

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

Ahora la dirección IP de su sistema no se permite.

Utilizando el valor de la hoja de apuntes, verifique que ahora puede acceder a la dirección IP pública del NLB.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Si tiene acceso a otro sistema que tenga otra dirección IP, intente acceder al NLB desde dicho sistema.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
La conexión supera el tiempo de espera porque la dirección IP del sistema no se permite.

En este punto, todo el tráfico dirigido al NLB y a los puertos de nodo públicos está bloqueado. Solo se permite el tráfico procedente de la IP del sistema.

Denegar el tráfico de entrada procedente de IP específicas al NLB

En la lección anterior, ha bloqueado todo el tráfico y solo ha permitido unas pocas IP. Este caso de ejemplo funciona bien para fines de prueba cuando se desea limitar el acceso a unas pocas direcciones IP de origen controladas. Sin embargo, la empresa PR tiene apps que tienen que estar ampliamente disponibles para el público. Debe asegurarse de que se permita todo el tráfico, excepto el tráfico inusual que ve desde unas pocas direcciones IP. La creación de una lista de elementos bloqueados resulta útil en una situación como esta, porque puede ayudarle a evitar un ataque desde un pequeño conjunto de direcciones IP.

En esta lección, bloqueará el tráfico procedente de la dirección IP de origen de su propio sistema. Al final de la Lección 4, todo el tráfico dirigido a los puertos de nodo públicos se bloquea y se permite todo el tráfico dirigido al NLB. Solo se bloquea el tráfico procedente de la IP de su sistema específico.

Limpie las políticas de lista de direcciones permitidas que ha creado en la lección anterior.

Linux:

calicoctl delete GlobalNetworkPolicy deny-lb-port-80

calicoctl delete GlobalNetworkPolicy allowlist

Windows y OS X:

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

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

Ahora, todo el tráfico TCP y UDP entrante procedente cualquier IP de origen a la dirección IP y puerto del NLB vuelve a estar permitido.

Para denegar todo el tráfico TCP y UDP de entrada procedente de la dirección IP de origen de su sistema a la dirección IP y puerto del NLB, cree una política pre-DNAT de orden inferior denominada blocklist.yaml en un editor de texto. Utilizando los valores de la hoja de apuntes, sustituya <loadbalancer_IP> por la dirección IP pública del NLB y <client_address> por la dirección IP pública de la IP de origen 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

Aplique la política.

Linux:

calicoctl apply -f filepath/blocklist.yaml

Windows y OS X:

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

Ahora la dirección IP de su sistema está bloqueada.

Utilizando el valor de la hoja de apuntes, verifique desde su sistema que no puede acceder a la dirección IP del NLB porque la IP de su sistema está bloqueada.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
En este punto, todo el tráfico dirigido a los puertos de nodo públicos está bloqueado y se permite todo el tráfico dirigido al NLB público. Solo se bloquea el tráfico procedente de la IP de su sistema específico.

¡Buen trabajo! Ha controlado correctamente el tráfico de entrada en la app utilizando las políticas Pre-DNAT de Calico para bloquear direcciones IP de origen.

Registrar tráfico bloqueado procedente de IP específicas al NLB

En la lección anterior, ha bloqueado el tráfico procedente de la dirección IP de su sistema al NLB. En esta lección puede aprender a registrar las solicitudes de tráfico denegadas.

En este ejemplo, la empresa de relaciones públicas para la que trabajas quiere que establezcas un registro de cualquier tráfico inusual que una de tus políticas de red rechace continuamente. Para supervisar la amenaza de seguridad potencial, configura el registro para que registre todas las veces que la política de bloqueo deniega un intento de acción en la IP de NLB.

Cree una NetworkPolicy de Calico denominada log-denied-packets. Esta política de registro utiliza el mismo selector de pod que la política blocklist, que añade esta política a la cadena de reglas de Iptables de Calico. Si utiliza un número de orden inferior, como por ejemplo 300, puede asegurarse de que esta regla se añade a la cadena de reglas de Iptables antes de la política de lista de bloqueo. Los paquetes procedentes de su IP los registra esta política antes de que intenten coincidir con la regla de política blocklist y sean denegados.

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

Aplique la política.

Linux:

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

Windows y OS X:

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

Genere entradas de registro enviando solicitudes de la IP del sistema a la IP de NLB. Estos paquetes de solicitud se registran antes de ser denegados.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

Busque entradas de registro escritas en la vía de acceso /var/log/syslog. La entrada de registro se parecerá a lo siguiente.

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! Ha configurado el registro de forma que se pueda supervisar más fácilmente el tráfico bloqueado.

Si desea limpiar la lista de bloqueo y las políticas de registro:

Limpie la política de lista de bloqueo.

Linux:

calicoctl delete GlobalNetworkPolicy blocklist

Windows y OS X:

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

Limpie la política de registro.

Linux:

calicoctl delete GlobalNetworkPolicy log-denied-packets

Windows y OS X:

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

¿Qué hacer a continuación?

Obtenga más información sobre cómo controlar el tráfico con políticas de red.
Para obtener más ejemplos de políticas de red de Calico que controlan el tráfico hacia y desde el clúster, puede consultar las guías de aprendizaje deCalico.