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. Este HostEndpoint permite a los usuarios del clúster restringir aún más el tráfico de red privada creando políticas de Calico que seleccionan ibm.role: worker_private y tienen un número de orden menor que 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 elimine las políticas predeterminadas de su clúster, ya que se vuelven a crear en la siguiente actualización maestra o actualización maestra del clúster. 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 de Kubernetes predeterminadas 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.

Instalación y configuración de la CLI de Calico

Instale y configure la CLI de Calico para ver, gestionar y añadir políticas de Calico.

1. Establezca el contexto para el clúster para ejecutar los mandatos de Calico.

   • Kubernetes versión 1.19 y posterior:

     1. Descargue el archivo de configuración kubeconfig para el clúster.

        ibmcloud ks cluster config --cluster <cluster_name_or_ID>
        

     2. Establezca la variable de entorno DATASTORE_TYPE en kubernetes.

        export DATASTORE_TYPE=kubernetes
        

2. Si las políticas de red corporativas utilizan cortafuegos o proxies para impedir el acceso desde su sistema local a puntos finales públicos, permita el acceso TCP a mandatos de Calico.

3. Siga los pasos necesarios para instalar la herramienta de línea de mandatos de calicoctl.

   • Linux y OS X

     1. Descargue la versión de la CLI de Calico que coincida con su sistema operativo. Para OS X, es posible que tenga que permitir manualmente que el archivo descargado se abra y ejecute navegando a Preferencias del sistema > Seguridad y privacidad > General.

     2. Mueva el archivo al directorio /usr/local/bin.

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

     3. Convierta en ejecutable el archivo.

        chmod +x /usr/local/bin/calicoctl
        

     4. Asegúrese de que no haya ningún archivo antiguo de configuración de Calico calicoctl.cfg en el directorio /etc/calico. Si el archivo /etc/calico/calicoctl.cfg existe, suprímalo.

   • Windows

     1. Descargue la CLI de Calico. Cuando guarde el archivo, cambie el nombre a calicoctl.exe y guárdelo en el mismo directorio que la CLI de IBM Cloud. Esta configuración le ahorra algunos cambios en la vía de acceso a archivo cuando ejecute mandatos posteriormente.

     2. Establezca la variable de entorno en el archivo de configuración para el clúster.

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

4. Compruebe que la configuración de Calico funciona correctamente.

   calicoctl get nodes
   

   Salida de ejemplo

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

No se da soporte al cambio del plugin de Calico, los componentes o los valores predeterminados de Calico. Por ejemplo, no despliegue una nueva versión de plugin de Calico ni modifique los conjuntos de daemon o los despliegues de los componentes de Calico, los recursos de IPPool predeterminados o los nodos de Calico. En su lugar, puede seguir la documentación para cambiar la MTU de Calico o inhabilitar el plugin de correlación de puertos para el CNI de Calico si es necesario.

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, instale y configure la CLI de Calico y establezca el contexto para el clúster para ejecutar mandatos de Calico.

1. Consultar el punto final del host de Calico.

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

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

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

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

   calicoctl get GlobalNetworkPolicy -o wide
   

3. Consultar los detalles correspondientes a una política de red.

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

4. Visualizar los detalles de todas las políticas de red globales del clúster.

   calicoctl get GlobalNetworkPolicy -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 directivas de red d Kubernetes, consulte la documentación de directivas de red d Kubernetes.

Siga estos pasos para crear políticas de Calico. Antes de empezar, instale y configure la CLI de Calico y establezca el contexto para el clúster para ejecutar mandatos de Calico.

1. Defina su política de red e Calico a o política de red global creando un script de configuración (.yaml) con una sintaxis de 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.

   Para los nuevos clústeres suministrados en la versión 1.29 o posterior, los nombres abreviados para globalnetworkpolicies.crd.projectcalico.org (gnp) y hostendpoints.crd.projectcalico.org (hep) no están soportados. Sin embargo, si actualiza un clúster a la versión 1.29 o posterior, los nombres abreviados siguen estando soportados.

2. Aplique las políticas al clúster. Si tiene un sistema Windows, incluya la opción --config=<filepath>/calicoctl.cfg.

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

Tenga en cuenta que las políticas de red de Calico y Kubernetes solo bloquean las conexiones nuevas; no interrumpen las conexiones que existían antes de aplicar la política. Por lo tanto, después de aplicar una política nueva o modificada, para probar que funciona correctamente y no bloquea más de lo que debería, siga estos pasos:

1. Reinicie los pods que puedan verse afectados por la política. Mejor aún, reinicie todos los pods, por si acaso no tiene el selector correcto y afecta a más personas de las que cree.

2. Ejecute ibmcloud ks cluster master refresh -c CLUSTER-ID para reiniciar los pods de los nodos maestros del clúster. Como resultado, se interrumpirán las conexiones existentes desde kubelet y otros componentes al nodo maestro y será necesario volver a conectarse. Esto permite saber si las políticas nuevas y modificadas bloquean conexiones necesarias con los componentes del nodo maestro.

3. Intente conectarse al panel de control de Kubernetes para asegurarse de que los cambios de política no bloquean 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

Proporcionamos un conjunto de políticas de red públicas de Calico de ejemplo que restringen aún más el tráfico de red público/privado en los nodos de trabajador del clúster. Estas políticas permiten el tráfico necesario para que el clúster se despliegue y bloquean otro tipo de tráfico.

Estas políticas no están indicadas para bloquear todo, ni necesariamente cumplen por su cuenta requisitos de conformidad. Están pensadas como un punto de partida y deben editarse para adaptarse a sus casos de uso exclusivos. Para obtener más información, consulte el README.

Siempre que se habilitan nuevas ubicaciones para IBM Cloud Kubernetes Service y otras IBM Cloud, las subredes para estas ubicaciones se añaden a las políticas de Calico. Asegúrese de observar el repositorio GitHub para ver si hay actualizaciones de estas políticas.

Tenga en cuenta que ya no recomendamos utilizar las políticas de ejemplo allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private o allow-private-services-pods en las secciones de políticas de red pública y privada que aparecen a continuación. Estas políticas controlaban la salida de todos los pods del cluster. Si desea controlar el tráfico hacia/desde los pods debe utilizar Kubernetes NetworkPolicy y apuntar a espacios de nombres y pods específicos en lugar de utilizar estas políticas generales que tratan a cada pod de la misma manera.

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.

Antes de empezar, instale y configure la CLI de Calico y establezca el contexto para el clúster para ejecutar mandatos 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.

      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 de Calico utiliza el mismo selector de pod que el ejemplo de política de access-nginx Kubernetes descrito en el paso 1, sin embargo, la sintaxis es ligeramente diferente, ya que es 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 etiqueta run=access se aceptarán inmediatamente, lo que significa que no se evalúan otras políticas.

   • Si la conexión proviene de un pod sin la etiqueta run=access (o de cualquier cosa que no sea un pod), ese Kubernetes NetworkPolicy no hará nada y Calico evalúa 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 entrante y no hace referencia únicamente al tráfico procedente del ALB de IBM Ingress. | ingress

   : action: la acción Log escribe una entrada de registro para cualquier solicitud que coincida con esta política en la vía de acceso /var/log/syslog en el nodo de trabajador.

   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 Calico, debe 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 run == 'nginx' original.

   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 después de que se hayan 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. Tenga en cuenta que Kubernetes NetworkPolicy se aplican como orden 1000.

3. Aplique la política. Si utiliza un equipo con Windows, incluya la opción --config=<filepath>/calicoctl.cfg.

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

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.