Prácticas recomendadas para las políticas de red de Kubernetes

Controlar y filtrar el tráfico al contenerizar una carga de trabajo en Pods de Kubernetes es tan crucial como usar un firewall en una configuración de red más tradicional. La diferencia es que, en este escenario, estas capacidades las proporciona la API Kubernetes NetworkPolicy.

En este artículo exploraremos Kubernetes NetworkPolicy creando una política de red de ejemplo y examinando sus parámetros principales. Luego, veremos algunos casos de uso comunes de NetworkPolicy y aprenderemos a monitorearlos con kubectl. Por último, descubriremos cómo implementar la Container Network Interface (CNI) mediante extensiones de Kubernetes de terceros.

Por qué no deberías evitar las políticas de red de Kubernetes

Implementar políticas de red es fundamental para operar un entorno de Kubernetes. Sin una política de red configurada, todos los Pods de un clúster pueden comunicarse entre sí de forma predeterminada. Por eso, si nuestro Pod contiene datos confidenciales, como una base de datos de backend con información privada, debemos asegurarnos de que solo ciertos Pods de frontend puedan conectarse a él.

También podemos aislar el tráfico de red entre los Pods de un entorno de desarrollo y los que se ejecutan en un entorno de producción. Sin políticas de red, todo el tráfico circula libremente hacia y desde todos los puntos de la red.

Por suerte, configurar Kubernetes NetworkPolicy es una forma sencilla, eficaz e integral de garantizar que el tráfico de red fluya solo según lo previsto.

Definición de políticas de red de Kubernetes

Veamos un ejemplo de NetworkPolicy. Considera una carga de trabajo de ejemplo con un frontend de WordPress y un backend de base de datos MySQL, que ejecuta una colección de Pods con servicios web y de base de datos, todos implementados en el espacio de nombres default de Kubernetes. Los protocolos de seguridad de la empresa exigen que aislemos el tráfico de red de cargas de trabajo específicas y permitamos solo el tráfico entrante y saliente mínimo necesario para usarlas.

Esta estrategia contempla las siguientes condiciones:

• Bloquear el comportamiento predeterminado de Kubernetes que permite todo el tráfico.

• Asegurarse de que solo los Pods con la etiqueta wordpress en el espacio de nombres default puedan comunicarse entre sí.

• Permitir la conectividad entrante (ingress) desde la Internet pública en los puertos 80/443 y desde el rango de IP 172.16.0.0.

• Permitir únicamente que los Pods con la etiqueta wordpress se conecten a los Pods de la base de datos MySQL por el puerto 3306.

• Permitir siempre la conectividad con el servicio DNS de Kubernetes (puerto 53).

• Bloquear toda conectividad saliente fuera del clúster.

El diagrama de red de abajo ilustra cómo podrían verse estas reglas.

Para este ejemplo, podemos distribuir las políticas de red entre los archivos de definición de políticas o combinarlas en un solo archivo de manifiesto YAML. Como nuestro ejemplo utiliza una carga de trabajo (webapp), tiene sentido usar un solo archivo de definición del conjunto de reglas. Sin embargo, como este ejemplo incluye varias conexiones de entrada y salida, también podríamos crear archivos de configuración individuales para cada conexión dentro del clúster.

Revisemos varios de los parámetros anteriores para entender cómo se relacionan con la configuración y cómo afectan el comportamiento del tráfico de red.

API y metadatos

En la primera línea del archivo YAML de abajo, especificamos la API de redes (networking.k8s.io) y su versión (v1). También definimos el tipo de archivo YAML como NetworkPolicy para indicar al controlador de la API de Kubernetes que estamos configurando políticas de red. Los elementos name y namespace de la sección metadata contienen el nombre que asignamos a este conjunto de reglas y el espacio de nombres al que está vinculado.

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: sample-network-policy
5  namespace: default

La siguiente parte del archivo YAML contiene la sección de especificaciones (specs), donde podemos establecer los filtros que aplicará la política de red.

El siguiente fragmento incluye varios parámetros importantes:

• podSelector — Especifica qué Pods están sujetos a las políticas de tráfico establecidas. Nuestro ejemplo usa el parámetro matchLabels para garantizar que la política de red se aplique a todos los Pods con la etiqueta app: wordpress. Además, el parámetro excluye de esta política de red a todos los demás Pods.

• policyTypes — Contiene dos categorías: Ingress y Egress

• Ingress — Define todo el tráfico entrante de Pods, espacios de nombres o colecciones de Pods

• Egress — Define todo el tráfico saliente de Pods, espacios de nombres o colecciones de Pods

1spec:
2  podSelector:
3    matchLabels:
4      app: wordpress
5  policyTypes:
6    - Egress
7    - Ingress

A continuación, la sección ingress de la política de red define los tipos de tráfico entrante permitidos. La siguiente sección permite el tráfico entrante en los puertos 443 y 80 desde:

• Todos los Pods con la etiqueta wordpress

• Todo el tráfico de la Internet pública (cidr: 0.0.0.0/0)

• Todas las direcciones IP del rango 172.16.0.0/16, que podría representar un rango de IP corporativo (una VPN, VLAN o subred).

El fragmento YAML que permite el tráfico anterior se vería así:

1  ingress:
2    - from:
3      - podSelector:
4          matchLabels:
5            app: wordpress
6      ports:
7        - port: 443
8        - port: 80  
9    - from:
10      - ipBlock:
11          cidr: 172.16.0.0/16
12      ports:
13        - port: 443
14        - port: 80
15    - from:
16      - ipBlock:
17          cidr: 0.0.0.0/0
18      ports:
19        - port: 443
20        - port: 80

Por último, detallamos la sección egress con las reglas de tráfico saliente. Permitimos que el tráfico saliente de los Pods con la etiqueta webapp se comunique por los puertos 1433 (SQL) y 53 (DNS).

Especificar la etiqueta webapp garantiza que ningún otro Pod pueda comunicarse con las instancias de SQL Server, lo que elimina todos los riesgos de seguridad relacionados. De manera similar, la configuración permite que el puerto 53 se conecte a todos los Pods del clúster.

Hay otra conclusión importante de esta definición de política. Una vez que integramos la política de red para controlar la conectividad de los Pods, debemos configurar los ajustes de permiso y denegación en ambas direcciones. Permitir el tráfico saliente del frontend sin permitir el tráfico entrante al backend impedirá la comunicación.

El fragmento YAML para esta parte del tráfico se ve así:

1  egress: 
2    - to:
3        - namespaceSelector: {}
4          podSelector:
5            matchLabels:
6              k8s-app: kube-dns
7      ports:
8        - port: 53
9          protocol: UDP
10
11    - to:
12        - podSelector:
13            matchLabels:
14              app: wordpress
15      ports:
16        - port: 3306

Aplicación de políticas de red de Kubernetes

Ya terminamos el manifiesto YAML de ejemplo de NetworkPolicy, que se ve así:

1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4  name: sample-network-policy
5  namespace: default
6spec:
7  podSelector:
8    matchLabels:
9      app: webapp
10  policyTypes:
11    - Egress
12    - Ingress
13  ingress:
14    - from:
15        - podSelector:
16            matchLabels:
17              app: webapp
18      ports:
19        - port: 443
20        - port: 80
21    - from:
22        - podSelector: {}
23    - from:
24        - ipBlock:
25            cidr: 172.16.0.0/16
26      ports:
27        - port: 443
28        - port: 80
29    - from:
30        - ipBlock:
31            cidr: 0.0.0.0/0
32      ports:
33        - port: 443
34        - port: 80
35  egress:
36    - to:
37        - namespaceSelector: {}
38          podSelector:
39            matchLabels:
40              k8s-app: kube-dns
41      ports:
42        - port: 53
43          protocol: UDP
44    - to:
45        - podSelector: {}
46    - to:
47        - podSelector:
48            matchLabels:
49              app: webapp
50      ports:
51        - port: 443
52        - port: 80

Ahora debemos incorporar el archivo al clúster de Kubernetes. Para hacerlo, primero guarda el archivo como sample-network-policy.yaml.

Ahora aplicamos el archivo de definición como la mayoría de las demás configuraciones de Kubernetes: mediante la interfaz de línea de comandos (CLI) kubectl.

Ejecuta el siguiente comando:

1kubectl apply -f sample-network-policy.yaml

Validación y monitoreo de las políticas de red de Kubernetes

Al igual que con la administración tradicional de firewalls, la validación y el monitoreo de las políticas de red de Kubernetes requieren supervisión operativa. De vez en cuando, debemos volver a evaluar las reglas de red existentes para decidir si siguen siendo aplicables a la carga de trabajo asociada.

También es posible que debamos validar el conjunto de reglas para solucionar problemas de tráfico o investigar conflictos entre distintas políticas de red. Por suerte, podemos validar las políticas de red mediante la CLI kubectl. Ejecutar el siguiente comando analiza y monitorea tus políticas de red actuales:

1kubectl describe networkpolicy <networkpolicy name as listed in the YAML manifest>

A continuación, se muestra un ejemplo del resultado para el tipo de política ingress.

Además, esta imagen muestra un ejemplo del resultado para el tipo de política egress:

Prácticas recomendadas para aplicar políticas de red de Kubernetes

Como en cualquier configuración de seguridad de red, conviene seguir varias prácticas recomendadas para las políticas de red de Kubernetes:

• Usa la política de red predeterminada deny-all para garantizar que solo se permita la comunicación autorizada explícitamente.

• Agrupa los Pods que deben comunicarse entre sí mediante el parámetro PodSelector.

• Permite la comunicación entre espacios de nombres solo cuando sea necesario.

• No permitas comunicaciones de red innecesarias, ni siquiera dentro del clúster de Kubernetes.

• Ten cuidado al permitir que los Pods del clúster reciban tráfico de red que provenga de fuera del clúster.

• Denegar el tráfico saliente hacia la Internet pública podría interferir con ciertas actualizaciones de aplicaciones o procesos de validación.

Los complementos CNI de Kubernetes optimizan la administración de políticas de red

Una de las ventajas de los complementos CNI es que abstraen los detalles de implementación de NetworkPolicy, lo que permite que quienes administran el clúster elijan la mejor solución para sus necesidades sin tener que lidiar con la complejidad de las tecnologías subyacentes.

Sin embargo, las instalaciones predeterminadas de Kubernetes no incluyen un complemento CNI preinstalado, a menos que la distribución o el proveedor haya agregado uno. Esto significa que tendrás que elegir e instalar el complemento que mejor se adapte a tus necesidades. Además, aunque tu distribución incluya uno predeterminado, es posible que otro se ajuste mejor a tus requisitos.

Hay muchos proveedores de CNI, y algunos de los más populares son:

• Cilium

• Calico

• Antrea

Cada complemento tiene capacidades únicas, así que quizá debas probar varios para decidir cuál se adapta mejor a tus requisitos de red y seguridad de red.

Conclusión

Configurar una topología de red empresarial con enrutamiento complejo, reglas de tráfico e integraciones de seguridad puede ser tedioso. Por suerte, en un entorno de Kubernetes, las políticas de red pueden cumplir la misma función que los firewalls en una infraestructura tradicional.

Por supuesto, configurar políticas de red es solo el primer paso de un proceso que requiere reevaluaciones y mantenimiento periódicos. Aunque el complemento kubenet integrado ofrece ciertas capacidades de red para administrar tus políticas, otros complementos CNI ofrecen funcionalidades más avanzadas. Por suerte, la combinación adecuada de políticas y administración garantiza que el tráfico de red se mantenga seguro y eficiente.

Recursos adicionales sobre seguridad de Kubernetes

• Seguridad de Kubernetes: problemas comunes y prácticas recomendadas

• Cómo crear imágenes de Docker en Kubernetes

• Guía de monitoreo de Kubernetes para 2022

• 10 configuraciones del contexto de seguridad de Kubernetes que debes conocer

• Implicaciones de seguridad de los operadores de Kubernetes