Políticas de red de Kubernetes y Calico predeterminadas

Cuando se crea un clúster con una VLAN pública, se crea de forma automática un recurso HostEndpoint con la etiqueta ibm.role: worker_public para cada nodo trabajador y su interfaz de red pública. Este HostEndpoint hace que se descarte todo el tráfico hacia o desde la interfaz de red pública, a menos que se permita específicamente en una política de Calico que selecciona la etiqueta ibm.role: worker_public.

También se crea automáticamente un recurso HostEndpoint con la etiqueta ibm.role: worker_private para cada nodo trabajador y su interfaz de red privada. Se crea una política allow-all-private-default predeterminada para que todo el tráfico se permita hacia y desde la interfaz de red privada. Esto HostEndpoint facilita a los usuarios de clústeres restringir aún más el tráfico de la red privada mediante la creación de políticas de Calico que seleccionen y ibm.role: worker_private tengan un número de orden inferior al de la allow-all-private-default.

Estas políticas de host de Calico predeterminadas permiten todo el tráfico de red de salida pública, y permiten el tráfico de entrada público a componentes de clúster específicos como, por ejemplo, los servicios de Ingress, LoadBalancer y NodePort de Kubernetes. De forma predeterminada, la política allow-all-private-default permite todo el tráfico privado. Cualquier otro tráfico de red entrante de Internet a los nodos de trabajador que no se especifica en las políticas predeterminadas se bloquea. Las políticas predeterminadas no afectan al trafico entre pods.

No elimines las políticas predeterminadas de tu clúster, ya que se volverán a crear en la próxima actualización o refresco del clúster maestro. Si desea restringir más el tráfico, aplique políticas de Calico de orden inferior para bloquear el tráfico. Asegúrese de comprender completamente lo que está bloqueando y que los componentes del clúster no necesiten el tráfico que desea bloquear.

Revise las siguientes políticas de host de Calico predeterminadas que se aplican automáticamente a su clúster.

También se crean políticas predeterminadas de Kubernetes que limitan el acceso al panel de control de Kubernetes. Las políticas de Kubernetes no se aplican al punto final de host, sino a nivel de pod en su lugar, y a todos los clústeres clásicos y de VPC.

Visualización de políticas de red

Consulte los detalles de políticas de red añadidas y predeterminadas que se aplican a su clúster.

Antes de empezar, instala y configura la CLI de Calico y establece el contexto de tu clúster para ejecutar comandos de Calico.

1. Consultar el punto final del host de Calico.

   kubectl get hostendpoints.projectcalico.org -o yaml
   

2. Vea todas las políticas de red de Calico que se han creado para el clúster. Esta lista incluye políticas que pueden no aplicarse a ningún pod ni host todavía. Para que se aplique una política de Calico, debe existir un pod de Kubernetes o Calico HostEndpoint que coincida con el selector que hay en la política de red de Calico.

   Calico Las políticas de red se aplican a espacios de nombres específicos:

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

   Kubernetes Las políticas de red también se aplican a espacios de nombres específicos:

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

   Calico Las políticas de red globales no se limitan a espacios de nombres específicos:

   kubectl get globalnetworkpolicies.projectcalico.org -o wide
   

3. Ver detalles de una política de red de Calico.

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

4. Consulta los detalles de todas las políticas de la red global de Calico para el clúster.

   kubectl get globalnetworkpolicies.projectcalico.org -o yaml
   

5. Consulta los detalles de todas las políticas de red de Kubernetes para el clúster.

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

Adición de políticas de red

Normalmente, las políticas predeterminadas no requieren cambios. Sólo en escenarios avanzados se pueden requerir cambios. Si debe realizar cambios, cree sus propias políticas de red.

Para crear políticas de red de Kubernetes, consulta la documentación sobre políticas de red de Kubernetes.

Siga estos pasos para crear políticas de Calico.

1. Define tu política de red de Calico o tu política de red global creando un script de configuración (.yaml) con la sintaxis de la política Calico v3. Estos archivos de configuración incluyen los selectores que describen los pods, espacios de nombres o hosts a los que se aplican estas políticas.

2. Aplique las políticas al clúster.

   kubectl apply -f policy.yaml
   

Calico Además, las políticas de red de Kubernetes solo bloquean las nuevas conexiones; no interrumpen las conexiones que ya existían antes de que se aplicara la política. Después de aplicar una política nueva o modificada, para comprobar que funciona correctamente y que no bloquea más de lo que debería, haz lo siguiente:

1. Reinicia cualquier pod que pueda verse afectado por la política, o reinicia todos los pods en caso de que tu selector no sea el correcto y afecte a más pods de los que esperabas.

2. Ejecute ibmcloud ks cluster master refresh -c CLUSTER-ID para reiniciar los pods de los nodos maestros del clúster. Esto interrumpe las conexiones existentes entre kubelet y otros componentes y el maestro, y les obliga a volver a conectarse. Esto indica si las políticas nuevas y modificadas bloquean alguna conexión necesaria con tus componentes principales.

3. Intenta conectarte al panel de control de Kubernetes para asegurarte de que los cambios en las políticas no bloqueen las conexiones que necesitan esos componentes.

Control del tráfico entrante a los servicios de NLB o NodePort

De forma predeterminada, los servicios NodePort y LoadBalancer de Kubernetes facilitan el acceso a la app en todas las interfaces de clúster públicas y privadas. Sin embargo, puede utilizar políticas de Calico para bloquear el tráfico de entrada a los servicios en función del origen o el destino del tráfico.

Las políticas de Kubernetes y Calico predeterminadas son difíciles de aplicar para proteger los servicios NodePort y LoadBalancer de Kubernetes debido a las reglas Iptables de DNAT generadas para estos servicios. Sin embargo, las políticas pre-DNAT impiden que el tráfico especificado llegue a sus apps porque generan y aplican reglas Iptables antes de que Kubernetes utilice DNAT normal para reenviar el tráfico a los pods.

Algunos usos comunes de las políticas de red pre-DNAT de Calico:

• Bloquear el tráfico a puertos de nodo públicos de un servicio de equilibrador de carga de red (NLB) privado: un servicio de NLB hace que la app esté disponible en la dirección IP y el puerto del NLB y hace que la app está disponible en los puertos del nodo del servicio. Se puede acceder a los puertos de nodo en cada dirección IP (pública y privada) para cada nodo del clúster.
• Bloquear el tráfico a los puertos de nodo públicos en clústeres que ejecutan nodos trabajadores de extremo: el bloqueo de los puertos de los nodos garantiza que los nodos trabajadores de extremo sean los únicos nodos trabajadores que manejen el tráfico entrante.
• Bloquear el tráfico procedente de determinadas direcciones IP de origen o CIDR
• Permitir solo el tráfico procedente de determinadas direcciones IP de origen o CIDR y bloquear todo el otro tráfico

Para ver cómo permitir o bloquear direcciones IP de origen, consulte la guía de aprendizaje sobre cómo utilizar políticas de red de Calico para bloquear el tráfico.

Ejemplo de políticas de Calico para restringir el tráfico de red público o privado

IBM Proporciona un conjunto de ejemplos de políticas de red pública Calico y de políticas de red privada Calico que restringen aún más el tráfico de red público y privado en los nodos de trabajo del clúster.

Estas políticas no están indicadas para bloquear todo, ni necesariamente cumplen por su cuenta requisitos de conformidad. IBM no ofrece soporte activo para estos documentos, que solo pretenden servir como un posible punto de partida y deben modificarse para adaptarse a tus casos de uso específicos. Para obtener más información, consulte el README.

IBM Ya no se recomienda utilizar las políticas de ejemplo allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private o allow-private-services-pods que aparecen en las secciones Aplicación de políticas de red pública y Aplicación de políticas de red privada. Estas políticas controlaban la salida de todos los pods del cluster. Para controlar el tráfico hacia y desde los pods, IBM recomienda utilizar Kubernetes NetworkPolicy y centrarse en espacios de nombres y pods específicos, en lugar de utilizar estas políticas generales que tratan a todos los pods por igual.

Control del tráfico entre pods

Las políticas de Kubernetes protegen los pods frente al tráfico de red interno. Puede crear políticas de red de Kubernetes sencillas simple para aislar los microservicios de aplicaciones entre sí dentro de un espacio de nombres o entre varios espacios de nombres.

De forma predeterminada, cualquier pod tiene acceso a cualquier otro pod del clúster. Además, cualquier pod tiene acceso a cualquier servicio que exponga la red de pod, como un servicio de métricas, el DNS de clúster, el servidor de API o cualquier servicio que cree manualmente en el clúster.

Registro de tráfico denegado

Para registrar las solicitudes de tráfico denegadas a determinados pods del clúster, puede crear una política de red de registro de Calico.

Cuando se configuran políticas de red para limitar el tráfico a los pods de app, las solicitudes de tráfico que no están permitidas por estas políticas se deniegan y se descartan. En algunos casos, quizá desee más información sobre las solicitudes de tráfico denegadas. Por ejemplo, es posible que observe algún tráfico poco habitual que una de las políticas de red deniega continuamente. Para supervisar la amenaza de seguridad potencial, puede configurar el registro para que registre todas las veces que la política deniega un intento de acción en pods de app determinados.

En esta sección se muestra cómo registrar el tráfico denegado por una política de red de Kubernetes. Para registrar el tráfico denegado por una política de red de Calico, consulte la Lección 5 de la guía de aprendizaje de la política de red de Calico.

1. Cree o utilice una política de red de Kubernetes existente que bloquee o limite el tráfico entrante.

   1. Cree una política de red de Kubernetes. Por ejemplo, para controlar el tráfico entre pods, puede utilizar la siguiente política de Kubernetes de ejemplo denominada access-nginx, que limita el acceso a una app NGINX. El tráfico de entrada a pods etiquetados como "run=nginx" solo se permite desde pods con la etiqueta "run=access". El resto del tráfico entrante a los pods de app "run = nginx" está bloqueado.

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

2. Para registrar todo el tráfico que ha denegado la política que ha creado en el paso anterior, cree una NetworkPolicy de Calico denominada log-denied-packets. La siguiente política Calico utiliza el mismo selector de pod que la política de ejemplo Kubernetesaccess-nginx descrita en el paso 1; sin embargo, la sintaxis es ligeramente diferente, ya que se trata de un Calico NetworkPolicy en lugar de un Kubernetes NetworkPolicy. Asimismo, puesto que Calico evalúa todas las Kubernetes NetworkPolicy como si fueran 1000, se añade el número de pedido 3000 para asegurarse de que se evalúa después de Kubernetes NetworkPolicy. Con estas dos políticas en vigor, este es el resultado:

   • Las nuevas conexiones que llegan al pod nginx se evalúan primero con la NetworkPolicy de Kubernetes (orden 1000). Las conexiones procedentes de un pod con la run=access etiqueta se aceptan inmediatamente, lo que significa que no se evalúan otras políticas.
   • Si la conexión procede de un pod sin la etiqueta run=access (o de cualquier elemento que no sea un pod), Kubernetes NetworkPolicy no hará nada y Calico evaluará a continuación la política log-denied-packets. Esta política registra el paquete en syslog en el nodo de trabajador donde se encuentra el pod nginx.
   • A continuación, Calico comprueba si hay otras políticas que se deben aplicar a la conexión y, como no encuentra ninguna, el paquete se descarta. Esto se debe a que todo tráfico a un pod con una política que no se permita explícitamente se descartará.

       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

Esta política de Ingress se aplica a todas las solicitudes de tráfico entrantes. El valor Ingress es un término general para todo el tráfico de entrada, y no hace referencia solo al tráfico procedente del ALB de IBM Ingress. ingress : action: La acción Log escribe una entrada de registro para cualquier solicitud que cumpla con esta política en la ruta /var/log/syslog del nodo de trabajo. : destination: No se ha especificado ningún destino porque selector aplica esta política a todos los pods con una determinada etiqueta. : source: Esta política se aplica a las solicitudes de cualquier origen.

selector

El selector debe apuntar al mismo tráfico que la NetworkPolicy de Kubernetes access-nginx original. Dado que se trata de una política de tipo Calico, debes incluir projectcalico.org/orchestrator == 'k8s' para indicar que se aplica a todos los pods del espacio de nombres de la política, además del original run == 'nginx'.

order

Las políticas de Calico tienen un orden que determina cuándo se aplican a los paquetes de solicitud entrantes. Las políticas con un orden más bajo, como por ejemplo 1000, se aplican primero. Las políticas con un orden más alto se aplican después de las políticas de orden más bajo. Por ejemplo, una política con un orden muy alto, como 3000, se aplica efectivamente en último lugar, una vez que se han aplicado todas las políticas de orden inferior. Los paquetes de solicitud entrantes pasan por la cadena de reglas de Iptables e intentan coincidir con las reglas de las políticas de orden inferior en primer lugar. Si un paquete coincide con alguna regla, se acepta. Sin embargo, si un paquete no coincide con ninguna regla, llega a la última regla de la cadena de reglas de Iptables con el orden más alto. Para asegurarse de que ésta es la última política de la cadena, utilice un orden mucho más alto, como 3000, que la política que ha creado en el paso 1. Ten en cuenta que se aplican las reglas de Kubernetes y NetworkPolicy en este orden 1000.

3. Aplique la política.

   kubectl apply -f log-denied-packets.yaml
   

4. Genere entradas de registro enviando solicitudes que no están permitidas por la política que ha creado en el paso 1. Por ejemplo, intente hacer ping al pod protegido por la política de red desde un pod o una dirección IP que no estén permitidos.

5. Busque entradas de registro escritas en la vía de acceso /var/log/syslog. Las direcciones IP de DST (destino) o SRC (origen) en la entrada de registro pueden ser distintas de lo esperado debido a los proxies, a la conversión de direcciones de red (NAT) y a otros procesos de red. 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
   

6. Opcional: reenvíe los registros de /var/log/syslog a IBM Cloud Logs o a un servidor de syslog externo.