Cómo utilizar las políticas de red con el modo automático de EKS - Amazon EKS
Descripción generalIntroducción¿Cómo funciona?Consideraciones

Ayude a mejorar esta página

Para contribuir a esta guía del usuario, elija el enlace Edit this page on GitHub que se encuentra en el panel derecho de cada página.

Cómo utilizar las políticas de red con el modo automático de EKS

Descripción general

A medida que los clientes escalan sus entornos de aplicaciones mediante EKS, el aislamiento del tráfico de la red se vuelve cada vez más fundamental para evitar el acceso no autorizado a los recursos tanto dentro como fuera del clúster. Esto es especialmente importante en un entorno de varios inquilinos con varias cargas de trabajo no relacionadas que se ejecutan en paralelo en el clúster. Las políticas de red de Kubernetes le permiten mejorar la posición de seguridad de la red para sus cargas de trabajo de Kubernetes y sus integraciones con los puntos de conexión externos al clúster. El modo automático de EKS admite distintos tipos de políticas de red.

Aislamiento de las capas 3 y 4

Las políticas de red estándar de Kubernetes operan en las capas 3 y 4 del modelo de red OSI y le permiten controlar el flujo de tráfico en la dirección IP o el puerto dentro del clúster de Amazon EKS.

Casos de uso

  • Segmente el tráfico de red entre las cargas de trabajo para garantizar que solo las aplicaciones relacionadas puedan comunicarse entre sí.

  • Aísle los inquilinos del espacio de nombres mediante políticas que impongan la separación de la red.

Aplicación basada en DNS

Los clientes suelen implementar cargas de trabajo en EKS que forman parte de un entorno distribuido más amplio, algunas de las cuales tienen que comunicarse con sistemas y servicios externos al clúster (tráfico en dirección norte). Estos sistemas y servicios pueden estar en la nube de AWS o completamente fuera de AWS. Las políticas basadas en el sistema de nombres de dominio (DNS) le permiten reforzar su posición de seguridad mediante la adopción de un enfoque más estable y predecible para evitar el acceso no autorizado desde los pods a los recursos o puntos de conexión externos al clúster. Este mecanismo elimina la necesidad de hacer un seguimiento manual de direcciones IP específicas y permitir incluirlas en una lista. Al proteger los recursos con un enfoque basado en DNS, también tiene más flexibilidad para actualizar la infraestructura externa sin tener que flexibilizar la posición de seguridad ni modificar las políticas de red en caso de cambios en los servidores y hosts ascendentes. Puede filtrar el tráfico de salida hacia puntos de conexión externos mediante un nombre de dominio completo (FQDN) o un patrón coincidente para un nombre de dominio de DNS. Esto le ofrece la flexibilidad adicional de ampliar el acceso a varios subdominios asociados a un punto de conexión externo al clúster en particular.

Casos de uso

  • Estandarice según un enfoque basado en DNS para filtrar el acceso desde un entorno de Kubernetes a los puntos de conexión externos al clúster.

  • Proteja el acceso a los servicios de AWS en un entorno de varios inquilinos.

  • Administre el acceso a la red desde los pods hasta las cargas de trabajo en las instalaciones en sus entornos de nube híbrida.

Reglas de administración (o según el ámbito del clúster)

En algunos casos, como en los escenarios de varios inquilinos, es posible que los clientes tengan que aplicar un estándar de seguridad de red a todo el clúster. En lugar de definir y mantener de forma repetitiva una política distinta para cada espacio de nombres, puede usar una política única para administrar de forma centralizada los controles de acceso a la red para las diferentes cargas de trabajo del clúster, independientemente de su espacio de nombres. Estos tipos de políticas le permiten ampliar el ámbito de aplicación de las reglas de filtrado de red que se aplican en las capas 3 y 4 y cuando se utilizan las reglas de DNS.

Casos de uso

  • Administre de forma centralizada los controles de acceso a la red para todas las cargas de trabajo (o un subconjunto de ellas) del clúster de EKS.

  • Defina una posición de seguridad de red predeterminada en todo el clúster.

  • Amplíe los estándares de seguridad de la organización al ámbito del clúster de una manera más eficiente desde el punto de vista operativo.

Introducción

Requisitos previos

  • Un clúster de Amazon EKS con el modo automático de EKS habilitado

  • kubectl configurado para conectarse al clúster

Paso 1: Habilitación del controlador de políticas de red

Para utilizar las políticas de red con el modo automático de EKS, primero debe habilitar el controlador de políticas de red, para lo cual se aplica un ConfigMap al clúster.

  1. Cree un archivo denominado enable-network-policy.yaml con el siguiente contenido:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. Aplique el ConfigMap al clúster

    kubectl apply -f enable-network-policy.yaml

Paso 2: Habilitación de políticas de red en Clase de nodo

Antes de poder utilizar las políticas de red, debe asegurarse de que la Clase de nodo está configurada para admitirlas. Siga estos pasos:

  1. Cree o edite un archivo YAML de Clase de nodo (por ejemplo, nodeclass-network-policy.yaml) con el siguiente contenido:

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-enabled
spec:
  # Enables network policy support
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. Aplique la configuración de Clase de nodo al clúster:

    kubectl apply -f nodeclass-network-policy.yaml

  3. Verifique que se haya creado la Clase de nodo:

    kubectl get nodeclass network-policy-enabled

  4. Actualice el Grupo de nodos para utilizar esta Clase de nodo. Para obtener más información, consulte Creación de un grupo de nodos para el modo automático de EKS.

Una vez que los nodos utilicen esta Clase de nodo, podrán aplicar políticas de red. Ahora puede proceder a crear y aplicar políticas de red para controlar el tráfico dentro del clúster. Para conocer todas las opciones de configuración de las clases de nodos, consulte Cómo crear una clase de nodos para Amazon EKS.

Paso 3: Cómo crear y probar políticas de red

El clúster del modo automático de EKS ya está configurado para admitir las políticas de red de Kubernetes. Puede probar esto con la Demostración de Stars de política de red para Amazon EKS.

¿Cómo funciona?

Política de red basada en DNS

Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS
Ilustración del flujo de trabajo cuando se aplica una política basada en DNS al modo automático de EKS

  1. El equipo de la plataforma aplica una política basada en DNS al clúster de EKS.

  2. El controlador de políticas de red es responsable de supervisar la creación de políticas dentro del clúster y, a continuación, conciliar los puntos de conexión de las políticas. En este caso de uso, el controlador de políticas de red indica al agente de nodos que filtre las solicitudes de DNS en función de los dominios permitidos en la política creada. Los nombres de dominio se enumeran en la lista de dominios permitidos mediante el FQDN o un nombre de dominio que coincida con un patrón definido en la configuración de recursos de Kubernetes.

  3. La carga de trabajo A intenta resolver la IP de un punto de conexión externo al clúster. La solicitud de DNS pasa primero por un proxy que filtra dichas solicitudes en función de la lista de solicitudes permitidas aplicada a través de la política de red.

  4. Una vez que la solicitud de DNS pasa por la lista de filtros de DNS permitidos, se envía por proxy a CoreDNS.

  5. A su vez, CoreDNS envía la solicitud al Solucionador de DNS externo (Amazon Route 53 Resolver) para obtener la lista de direcciones IP detrás del nombre de dominio.

  6. Las IP resueltas con TTL se devuelven en respuesta a la solicitud de DNS. A continuación, estas direcciones IP se escriben en un mapa de eBPF que se utiliza en el siguiente paso para la aplicación de la capa de IP.

  7. A continuación, las sondas de eBPF conectadas a la interfaz veth del pod filtrarán el tráfico de salida de la carga de trabajo A al punto de conexión externo del clúster en función de las reglas vigentes. Esto garantiza que los pods solo puedan enviar tráfico externo al clúster a las IP de los dominios de la lista de dominios permitidos. La validez de estas IP se basa en el TTL obtenido del Solucionador de DNS externo (Amazon Route 53 Resolver).

Uso de la política de red de la aplicación

La ApplicationNetworkPolicy combina las capacidades de las políticas de red estándar de Kubernetes con el filtrado basado en DNS del espacio de nombres mediante una única definición de recursos personalizados (CRD). Por lo tanto, ApplicationNetworkPolicy se puede utilizar para:

  1. Definir las restricciones en las capas 3 y 4 de la pila de red mediante bloques de IP y números de puerto.

  2. Definir reglas que operen en la capa 7 de la pila de red y permitir filtrar el tráfico en función de los FQDN.

Nota importante: Las reglas basadas en DNS definidas mediante la ApplicationNetworkPolicy solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS.

Ejemplo

Tiene una carga de trabajo en el clúster del modo automático de EKS que necesita comunicarse con una aplicación en las instalaciones que se encuentra detrás de un equilibrador de carga con un nombre de DNS. Para ello, puede utilizar la siguiente política de red:

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

En la red de Kubernetes, esto permitiría salir de cualquier pod del espacio de nombres “galaxy” etiquetado con role: backend para conectarse al nombre de dominio myapp.mydomain.com en el puerto TCP 8080. Además, tendría que configurar la conectividad de red para el tráfico de salida de la VPC al centro de datos corporativo.

Ilustración de la carga de trabajo en el modo automático de EKS que se comunica con las aplicaciones en las instalaciones

Política de red de administración (o del clúster)

Ilustración del orden de evaluación de las políticas de red en EKS

Uso de la política de red del clúster

Cuando se usa una ClusterNetworkPolicy, las políticas del nivel de administración se evalúan primero y no se pueden anular. Una vez evaluadas las políticas del nivel de administración, se utilizan las políticas estándar del ámbito del espacio de nombres para ejecutar las reglas de segmentación de red aplicadas. Esto se puede lograr mediante el uso de ApplicationNetworkPolicy o NetworkPolicy. Por último, se aplicarán las reglas del nivel de línea de base que definen las restricciones de red predeterminadas para las cargas de trabajo de los clústeres. Si es necesario, las políticas del ámbito del espacio de nombres pueden anular estas reglas del nivel de línea de base.

Ejemplo

Tiene una aplicación en el clúster que desea aislar de las cargas de trabajo de otros inquilinos. Puede bloquear de forma explícita el tráfico del clúster desde otros espacios de nombres para impedir el acceso de la red al espacio de nombres confidencial de la carga de trabajo.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

Consideraciones

Descripción del orden de evaluación de políticas

Las capacidades de políticas de red compatibles con EKS se evalúan en un orden específico para garantizar una administración del tráfico predecible y segura. Por lo tanto, es importante comprender el flujo de evaluación para diseñar una posición de seguridad de red efectiva para el entorno.

  1. Políticas del nivel de administración (se evalúan primero): todas las ClusterNetworkPolicies del nivel de administración se evalúan antes que cualquier otra política. En el nivel de administración, las políticas se procesan por orden de prioridad (se comienza por el número de prioridad más baja). El tipo de acción determina lo que sucede a continuación.

    • Acción de denegación (máxima prioridad): cuando una política de administración con una acción de denegación coincide con el tráfico, ese tráfico se bloquea inmediatamente, independientemente de cualquier otra política. No se procesan más reglas de ClusterNetworkPolicy ni NetworkPolicy. Esto garantiza que las políticas del espacio de nombres no puedan anular los controles de seguridad de toda la organización.

    • Acción de permiso: una vez evaluadas las reglas de denegación, las políticas de administración que incluyen acciones de permiso se procesan por orden de prioridad (se comienza por el número de prioridad más baja). Cuando una acción de permiso coincide, se acepta el tráfico y no se lleva a cabo ninguna otra evaluación de la política. Estas políticas pueden conceder el acceso a varios espacios de nombres en función de los selectores de etiquetas, lo que proporciona un control centralizado sobre qué cargas de trabajo pueden acceder a recursos específicos.

    • Acción de transferencia: las acciones de transferencia en las políticas del nivel de administración delegan la toma de decisiones a los niveles inferiores. Cuando el tráfico coincide con una regla de transferencia, la evaluación omite todas las reglas del nivel de administración restantes para ese tráfico y continúa directamente con el nivel de la NetworkPolicy. Esto permite a los administradores delegar explícitamente el control de determinados patrones de tráfico a los equipos de aplicaciones. Por ejemplo, puede usar reglas de transferencia para delegar la administración del tráfico dentro del espacio de nombres a los administradores del espacio de nombres y, al mismo tiempo, mantener controles estrictos sobre el acceso externo.

  2. Nivel de política de red: si ninguna política del nivel de administración coincide con ninguna acción de denegación o permiso, o si coincide con una acción de transferencia, se evalúan los recursos de la ApplicationNetworkPolicy y de la NetworkPolicy tradicional del ámbito del espacio de nombres. Estas políticas proporcionan un control detallado dentro de los espacios de nombres individuales y las administran los equipos de aplicaciones. Las políticas relacionadas con el espacio de nombres solo pueden ser más restrictivas que las políticas de administración. No pueden anular ninguna decisión de denegación de una política de administración, pero pueden restringir aún más el tráfico permitido o transferido por las políticas de administración.

  3. Políticas de administración del nivel de línea de base: si ninguna política de administración o del ámbito del espacio de nombres coincide con el tráfico, se evalúan las ClusterNetworkPolicies del nivel de línea de base. Proporcionan posiciones de seguridad predeterminadas que pueden ser anuladas por políticas del ámbito del espacio de nombres, lo que permite a los administradores establecer valores predeterminados para toda la organización y, al mismo tiempo, ofrecer a los equipos la flexibilidad necesaria para personalizarlas según sea necesario. Las políticas de referencia se evalúan por orden de prioridad (se comienza por el número de prioridad más baja).

  4. Denegación de forma predeterminada (si ninguna política coincide): este comportamiento de denegación de forma predeterminada garantiza que solo se permitan las conexiones explícitamente permitidas, lo que mantiene una posición de seguridad sólida.

Aplicación del principio de privilegio mínimo

  • Inicio con políticas restrictivas y adición de permisos gradualmente según sea necesario: comience por implementar políticas de denegación de forma predeterminada en el clúster y, a continuación, agregue reglas de autorización de forma gradual según valide los requisitos de conectividad legítimos. Este enfoque obliga a los equipos a justificar de forma explícita cada conexión externa, lo que crea un entorno más seguro y auditable.

  • Auditoría y eliminación periódicas de las reglas de políticas no utilizadas: las políticas de red pueden acumularse con el tiempo a medida que las aplicaciones evolucionan y dejar atrás reglas obsoletas que amplían innecesariamente la superficie expuesta a ataques. Implemente un proceso de revisión periódico para identificar y eliminar las reglas de políticas que ya no sean necesarias, lo que garantiza que su posición de seguridad siga siendo estricta y fácil de mantener.

  • Uso de nombres de dominio específico en lugar de patrones amplios cuando sea posible: si bien los patrones de comodines como *.amazonaws.com proporcionan conveniencia, también otorgan acceso a una amplia gama de servicios. Siempre que sea posible, especifique nombres de dominio exactos como s3.us-west-2.amazonaws.com para limitar el acceso solo a los servicios específicos que requieren las aplicaciones, lo que reduce el riesgo de movimientos laterales si la carga de trabajo se ve comprometida.

Uso de políticas basadas en DNS en EKS

  • Las reglas basadas en DNS definidas mediante la ApplicationNetworkPolicy solo se aplican a las cargas de trabajo que se ejecutan en instancias de EC2 lanzadas por el modo automático de EKS. Si ejecuta un clúster de modo mixto (compuesto por nodos de trabajo del modo automático de EKS y nodos que no son del modo automático de EKS), las reglas basadas en DNS solo son efectivas en los nodos de trabajo del modo automático de EKS (instancias administradas de EC2).

Validación de las políticas de DNS

  • Uso de clústeres de almacenamiento provisional que reflejen la topología de la red de producción para llevar a cabo pruebas: el entorno de pruebas debe replicar la arquitectura de la red, las dependencias externas y los patrones de conectividad de la producción para garantizar la precisión de las pruebas de políticas. Esto incluye configuraciones de VPC coincidentes, comportamiento de resolución de DNS y acceso a los mismos servicios externos que requieren las cargas de trabajo de producción.

  • Implementación de pruebas automatizadas para rutas de red críticas: cree pruebas automatizadas que validen la conectividad con los servicios externos esenciales como parte del proceso de CI/CD. Estas pruebas deben verificar que se permiten los flujos de tráfico legítimos mientras se bloquean las conexiones no autorizadas, lo que permite validar continuamente que las políticas de red mantengan la posición de seguridad correcta a medida que la infraestructura evoluciona.

  • Supervisión del comportamiento de las aplicaciones tras los cambios en las políticas: tras implementar políticas de red nuevas o modificadas en el entorno de producción, supervise de cerca los registros de las aplicaciones, las tasas de errores y las métricas de rendimiento para identificar rápidamente cualquier problema de conectividad. Establezca procedimientos de reversión claros para poder revertir rápidamente los cambios en las políticas si provocan un comportamiento inesperado de las aplicaciones o interrupciones en el servicio.

Interacción con el firewall de DNS de Amazon Route 53

Las políticas de administración y de red de EKS se evalúan primero en el pod cuando se inicia el tráfico. Si una política de red de EKS permite la salida a un dominio específico, el pod lleva a cabo una consulta de DNS que llega a Route 53 Resolver. En este punto, se evalúan las reglas de firewall de DNS de Route 53. Si el firewall de DNS bloquea la consulta del dominio, se produce un error en la resolución de DNS y no se puede establecer la conexión, aunque la política de red de EKS lo permita. Esto crea capas de seguridad complementarias: las políticas de red basadas en DNS de EKS proporcionan un control de salida de pods para los requisitos de acceso específicos de la aplicación y los límites de seguridad de varios inquilinos, mientras que el firewall de DNS proporciona protección en toda la VPC contra los dominios maliciosos conocidos y aplica las listas de bloqueo en toda la organización.