Explicación de la seguridad de la red de Kubernetes

Las redes son una parte particularmente compleja de Kubernetes. Su configuración puede realizarse de diversas maneras. Puede utilizar una malla de servicios, aunque no necesariamente. Algunos recursos de su clúster pueden conectarse solo con redes internas, mientras que otros requieren acceso directo a Internet. Los puertos, las direcciones IP y otros atributos de la red suelen configurarse de forma dinámica, lo que puede dificultar el seguimiento de lo que ocurre a nivel de red.

Debido a estas y otras complejidades, la seguridad de la red de Kubernetes puede ser especialmente complicada. No solo requiere un profundo conocimiento de la arquitectura de red de Kubernetes, sino también estar familiarizado con las herramientas que Kubernetes ofrece de forma nativa para ayudar a proteger las redes, como las políticas de red y las herramientas de terceros que pueden reforzar aún más la seguridad de las redes.

En este artículo le explicamos los aspectos básicos de la seguridad de la red de Kubernetes. Aprenderá cómo funcionan las redes de Kubernetes, qué riesgos de seguridad pueden afectar a los recursos de la red y cuáles son las mejores prácticas para garantizar la seguridad de las redes en Kubernetes.

Redes Kubernetes 101

El primer paso para proteger Kubernetes a nivel de red es entender cómo funcionan las redes en Kubernetes. Este es un tema amplio y complejo, pero aquí repasaremos los aspectos básicos de las redes de Kubernetes que usted necesita saber.

Propósitos de la red

En Kubernetes, las redes tienen dos propósitos principales:

Redes internas: Las redes manejan el tráfico interno que facilita las comunicaciones entre pods, nodos y otros recursos de un clúster. Normalmente, las redes internas utilizan subredes y direcciones IP privadas, y están aisladas de la Internet pública.
Redes externas: Las workloads que necesitan conectarse a Internet utilizan direcciones IP públicas.

Kube-Proxy

El servicio que gestiona los flujos de tráfico dentro de Kubernetes es kube-proxy. Kube-proxy se ejecuta en cada uno de los nodos de un clúster de Kubernetes y reenvía los paquetes a los containers alojados en esos nodos basándose en las direcciones IP y los puertos de los containers.

En el backend, kube-proxy se basa en servicios de red a nivel de OS, como iptables en Linux, para controlar el tráfico. Pero como kube-proxy abstrae estos servicios de los recursos de Kubernetes, la capa de gestión de red subyacente a nivel de nodo no es especialmente importante para la seguridad de la red de Kubernetes.

Plugins CNI

En la mayoría de los casos, Kubernetes usa un plugin CNI (Container Network Interface) para crear una interfaz de red virtual que los containers pueden utilizar. Los plugins CNI se pueden utilizar para integrar Kubernetes con una variedad de plataformas de gestión de configuración de red de terceros, como las que se ejecutan de forma nativa en las nubes públicas (por ejemplo, Azure Virtual Networks y AWS Network Interfaces).

Los plugins CNI también pueden soportar plataformas como Project Calico y Weave Net, que están diseñadas para ayudar a estandarizar las configuraciones de red en entornos heterogéneos o híbridos (es decir, entornos que combinan múltiples tipos de plataformas, como Kubernetes y una nube pública o un centro de datos privado).

Aunque técnicamente es posible configurar la red en Kubernetes sin utilizar un plugin CNI, la mayoría de los clústeres de producción utilizan CNIs para gestionar la red.

Mallas de servicios

Además de los plugins CNI, los clústeres de producción de Kubernetes suelen utilizar una malla de servicios para ayudar a simplificar las redes. Las mallas de servicios automatizan el descubrimiento de diferentes recursos en una red. La mayoría de las mallas de servicios también ofrecen funciones de observabilidad y seguridad de la red.

Kubernetes no tiene una malla de servicios nativa, pero puede integrarse con la mayoría de las mallas de servicios más comunes, como Istio, Traefik y NGINX.

Configuraciones dinámicas

Independientemente del plugin CNI, la malla de servicios y otras herramientas de red que decida utilizar con Kubernetes, sus configuraciones de red serán casi siempre muy dinámicas.

Es decir, las direcciones IP y los puertos de los nodos, pods y servicios se configuran sobre la marcha a medida que se crean esos recursos. Si bien los administradores pueden definir grupos de direcciones IP que Kubernetes utilizará para hacer las asignaciones, no se pueden asignar direcciones IP estáticas (al menos no con las herramientas nativas de Kubernetes).

Las configuraciones dinámicas hacen que la seguridad de la red Kubernetes sea más difícil en algunos aspectos. Por ejemplo, no podrá hacer una lista blanca o negra de hosts basada en configuraciones de direcciones estáticas como cuando trabaja con máquinas virtuales. También puede ser más difícil asignar los datos de tráfico de red a recursos específicos de Kubernetes, porque no siempre podrá saber si una determinada dirección IP ha sido utilizada por un solo pod o nodo, por ejemplo, o bien ha sido utilizada por un recurso y luego reasignada a otro cuando el primero se cerró.

Cómo proteger los recursos de red de Kubernetes

Dado que Kubernetes normalmente depende de una mezcla de recursos internos (como kube-proxy) y servicios externos (como plugins CNI y mallas de servicios) para gestionar las configuraciones de red y el tráfico, la seguridad de las redes de Kubernetes también requiere que los administradores aprovechen una mezcla de herramientas nativas y de terceros.

Defina políticas de red

El recurso más importante que ofrece Kubernetes de forma nativa para la seguridad de la red son las políticas de red. Básicamente, las políticas de red definen las reglas que rigen la forma en que los pods pueden comunicarse entre sí a nivel de red.

Además de proporcionar un medio sistemático para controlar las comunicaciones de los pods, una de las ventajas importantes de las políticas de red es que permiten a los administradores definir los recursos y las reglas de red asociadas basándose en el contexto, como las etiquetas de los pods y los namespaces. Este es un aspecto es crucial porque, como explicamos antes, no se pueden utilizar direcciones IP para gestionar las reglas de red debido a la naturaleza dinámica de las configuraciones de red de Kubernetes.

Las políticas de red son similares a las políticas RBAC de Kubernetes. Son archivos que especifican las reglas de red que se desean aplicar y también identifican los recursos (un namespace, un pod, etc.) a los que se aplican las reglas.

Por ejemplo, esta política de red impide el tráfico de salida del backend entre los pods que ejecutan el namespace “default”:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-backend-egress
  namespace: default
  spec:
    podSelector:
    matchLabels:
      tier: backend
      policyTypes:
      - Egress
      egress:
      - to:
        - podSelector:
        matchLabels:
        tier: backend

Limitaciones de las políticas de red

Aunque las políticas de red son una herramienta indispensable para la seguridad de la red de Kubernetes, es importante conocer sus limitaciones:

Se centran en los pods: Las políticas de red están diseñadas esencialmente para aislar o restringir el acceso a la red de los pods. No se pueden utilizar (al menos no de una manera directa y sencilla) para gestionar las reglas de red para nodos u otros recursos en Kubernetes.
No detectan usos indebidos: Las políticas de red son una excelente manera de bloquear el acceso a la red y cerrar posibles agujeros de seguridad. Pero no sirven para detectar o alertar de posibles problemas de seguridad.
No cifran los datos: Las políticas de red no pueden cifrar los datos en movimiento mientras se desplazan entre los componentes de Kubernetes. Para conseguir el cifrado de la red, sería necesario utilizar herramientas de terceros (como una malla de servicios).

Aproveche las herramientas de seguridad de red de terceros

En lo que se refiere a las herramientas de seguridad de red nativas en Kubernetes, las políticas de red son básicamente todo lo que hay disponible. Por lo tanto, necesitará recurrir a herramientas externas para abordar otras facetas de la seguridad de la red.

Teniendo en cuenta que las distintas soluciones de red de terceros para Kubernetes varían en cuanto a las herramientas y funciones de seguridad que ofrecen, no existe una solución única para gestionar los requisitos de seguridad de la red por medio de herramientas externas.

Pero, en general, las mallas de servicios le permitirán cifrar el tráfico, implementar la autenticación y la autorización de los recursos conectados a la red y recopilar datos de telemetría de los recursos de red de Kubernetes que, a su vez, podrá introducir en las plataformas de análisis de seguridad para facilitar la detección de brechas. Algunas mallas de servicios también proporcionan marcos de políticas que puede utilizar para aplicar reglas de seguridad de red que no resultan prácticas utilizando las políticas de red de Kubernetes, como el aislamiento de namespaces o la denegación de conexiones si no existe seguridad en la capa de transporte.

Los plugins CNI suelen ofrecer características similares, como marcos de políticas y funcionalidad de monitorización de la red. Por lo tanto, dependiendo de las herramientas específicas que prefiera, puede optar por confiar en su plataforma de red conectada a CNI o en su malla de servicios para proporcionar la visibilidad y la aplicación de políticas necesarias para maximizar la seguridad de la red de Kubernetes.

Aplique las mejores prácticas de seguridad de Kubernetes

Aparte de aprovechar las diversas herramientas disponibles para reforzar la seguridad de las redes de Kubernetes, también hay una serie de mejores prácticas que deben seguirse cuando se trabaja con recursos de red en general en entornos que alojen un clúster de Kubernetes.

Utilice RBAC: Aunque el control de acceso basado en roles (RBAC) de Kubernetes no es un marco de seguridad de red, las reglas de RBAC pueden ayudar a mitigar el impacto de las amenazas de red restringiendo su acceso a los recursos dentro de un clúster.
Evite los puertos por defecto: Kubernetes utiliza puertos por defecto para la mayoría de sus servicios. Para mejorar la seguridad de la red, elija puertos personalizados, ya que esto dificultará a los atacantes la localización de los recursos.
Segmente las redes externamente: Aunque puede (y debe) utilizar las políticas de red, las reglas de malla de servicios y otros recursos para aislar las redes en Kubernetes, puede obtener una capa adicional de seguridad de red segmentando también las redes externas. Dependiendo de dónde estén alojados sus clústeres, esto significa aprovechar recursos como VPC o cortafuegos locales para minimizar la exposición de los recursos a la Internet pública.
Aproveche los registros de auditoría:Los registros de auditoría de Kubernetes proporcionan registros de todas las solicitudes de recursos que se ejecutan en Kubernetes. Si habilita y analiza los registros de auditoría, aumentará las probabilidades de detectar comportamientos que pueden indicar una brecha en la red.