Protección del tráfico del clúster de Kubernetes con políticas de red de pod

Los pods de Kubernetes pueden comunicarse libremente entre sí de forma predeterminada. Esto representa un riesgo de seguridad cuando su clúster se usa para múltiples aplicaciones o equipos. El comportamiento erróneo o el acceso malicioso en un pod podría dirigir el tráfico a los otros pods de su clúster.

Este artículo le enseñará cómo evitar este escenario configurando políticas de red. Estas reglas le permiten controlar los flujos de tráfico de pod a pod en el nivel de dirección IP (capa 3 o 4 de OSI). Puede definir con precisión las fuentes de entrada y salida permitidas para cada Pod.

Creación de una política de red

Las políticas de red se crean agregando objetos NetworkPolicy a su clúster. Cada política define los pods a los que se aplica y una o más reglas de entrada y salida. Aquí hay un manifiesto de política básico:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector:
    matchLabels:
      component: database
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
      - podSelector:
          matchLabels:
            component: api
  egress:
    - to:
        - podSelector:
            matchLabels:
              component: api

Esta política de red se aplica a cualquier Pod con una etiqueta component: database en el espacio de nombres app. Establece que el tráfico de entrada (entrante) y de salida (saliente) solo se permite desde y hacia Pods con una etiqueta component: api. Se bloquearán todas las solicitudes que se originen en otros pods, como component: web-frontend.

Las políticas de red se pueden aplicar como cualquier otro objeto mediante Kubectl. Entrarán en vigor inmediatamente después de su creación. Puede agregar la política de redes antes de iniciar los Pods que seleccione.

$ kubectl apply -f policy.yaml
networkingpolicy.networking.k8s.io/network-policy created

Cómo funcionan las políticas de red

Las políticas de red se implementan mediante el complemento de red activo de su clúster. Sus políticas no tendrán ningún efecto si su complemento no es compatible con la función. Las opciones más populares, como Calico y Cilium, se envían con compatibilidad con políticas de red habilitada.

Cuando se aplica una política de red a un Pod, el complemento inspeccionará su tráfico para verificar que cumpla con los requisitos de la política. Cualquier conexión que no cumpla con los criterios será rechazada. El pod que intentó iniciar la conexión encontrará que no se puede acceder al host remoto, ya sea porque estaba tratando de acceder a un recurso bloqueado por una regla de salida o porque un pod remoto rechazó la conexión entrante mediante una regla de entrada.

Una conexión exitosa entre dos Pods solo se puede establecer cuando las políticas de red en ambos lo permiten. La conexión podría estar prohibida por una regla de salida del pod de inicio o una regla de entrada en el destino.

Las políticas de red son siempre de naturaleza aditiva. Cuando varias políticas seleccionan el mismo Pod, la lista de fuentes de entrada y salida permitidas será la combinación de todas las políticas.

Ejemplo de políticas de red

Las políticas de red admiten muchas opciones diferentes para personalizar los Pods a los que apuntan y los tipos de conexión que están permitidos. Los siguientes ejemplos muestran varios casos de uso comunes.

Aplique una política a cada pod en el espacio de nombres, permitiendo solo el tráfico de entrada desde un bloque de dirección IP específico

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16

El bloque podSelector vacío significa que todos los pods del espacio de nombres están destinados a la política. La regla ipBlock restringe el tráfico de entrada a los Pods con una dirección IP en el rango especificado. El tráfico de salida no está bloqueado.

Permita el tráfico de entrada desde un bloque de direcciones IP, pero excluya algunas IP específicas

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.0.1/24
              - 172.17.0.2/24
              - 172.17.0.3/24

Las reglas de ipBlock admiten un campo except para excluir el tráfico que se origina o se dirige a direcciones IP específicas.

Permitir el tráfico de entrada de todos los pods en el espacio de nombres, pero solo desde un puerto específico

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}
          ports:
            - protocol: TCP
              port: 443

El campo ports está disponible en las reglas de entrada y salida. Define los puertos desde los que se puede recibir y enviar tráfico. Opcionalmente, puede especificar un rango de puertos, como 3000 – 3500, configurando el campo endPort (3500) además del port (3000).

Permitir el tráfico de Pods con una etiqueta específica que existe en un espacio de nombres diferente

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: database
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              application: demo-app
          podSelector:
            matchLabels:
              component: database

La política establece que cualquier pod etiquetado como component: base de datos puede llegar a todos los pods en el espacio de nombres database, si su propio espacio de nombres está etiquetado como demo-app .

Puede permitir el tráfico de todos los pods en un espacio de nombres externo creando una regla que solo incluya un campo namespaceSelector.

Permitir explícitamente todo el tráfico

A veces, es posible que desee permitir explícitamente todo el tráfico de un tipo particular dentro de un espacio de nombres. Incluya el tipo en su política, pero proporcione un selector de Pod vacío y sin reglas:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: network-policy
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - {}
  egress:
    - {}

Todos los Pods en el espacio de nombres pueden comunicarse libremente, como si no hubiera una política. Crear la política de todos modos le permite indicar sus intenciones a otros usuarios del clúster. Podrían cuestionar la presencia de un espacio de nombres con redes sin restricciones en un clúster que, de otro modo, estaría protegido.

Cuándo usar políticas de red

Se deben crear políticas de red para cada uno de los espacios de nombres y pods en su clúster. Esto aísla mejor sus Pods y le permite controlar el flujo de tráfico.

Trate de hacer que sus políticas sean lo más granulares posible. Ampliar demasiado el acceso, como permitir el acceso entre todos los Pods en un espacio de nombres, lo deja expuesto a riesgos si uno de sus contenedores se ve comprometido. Considere el uso de selectores precisos para identificar controles remotos de entrada y salida individuales para pods confidenciales, como servicios de autenticación, bases de datos y controladores de pago.

Kubernetes no habilita ninguna política de red de forma predeterminada que pueda permitir que se produzcan descuidos, incluso si tiene la intención de que todos los pods estén protegidos por una política. Puede mitigar este riesgo agregando una política general a sus espacios de nombres. Esta política selecciona cada Pod en el espacio de nombres y aplica una regla que prohíbe toda comunicación de red:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Las políticas de red siempre se limitan a los espacios de nombres, por lo que deberá crear un cajón de sastre separado para cada uno.

Resumen

Kubernetes permite que todos los pods de su clúster se comuniquen entre sí. Esto es demasiado permisivo para las aplicaciones del mundo real que se ejecutan en clústeres multipropósito. Las políticas de red abordan este problema al proporcionar un sistema similar a un firewall para administrar las fuentes de entrada y los objetivos de salida que acepta cada Pod.

Es una buena práctica configurar una política de red en todos sus Pods. Esto asegurará su clúster para que solo se permitan flujos de tráfico legítimos. Sin embargo, las políticas de red son solo una parte de la seguridad de Kubernetes: otros mecanismos de protección, como los contextos de seguridad RBAC y Pod, también son herramientas esenciales para fortalecer su entorno.