Limitación del tráfico de un pod con políticas de red de Kubernetes - Amazon EKS
Descripción generalPolítica de red estándarPolítica de red de administración (o del clúster)Notas importantesConsideraciones

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.

Limitación del tráfico de un pod con políticas de red de Kubernetes

Descripción general

De forma predeterminada, no hay restricciones en Kubernetes para las direcciones IP, puertos o conexiones entre cualquier pod de su clúster o entre sus pods y recursos en cualquier otra red. Puede usar una política de red de Kubernetes para restringir el tráfico de red que entra y sale de sus pods. Para obtener más información, consulte Network Policies en la documentación de Kubernetes.

Política de red estándar

Puede usar la NetworkPolicy estándar para segmentar el tráfico de pod a pod en el clúster. Estas políticas de red permiten operar en las capas 3 y 4 del modelo de red OSI, lo que le permite controlar el flujo de tráfico en la dirección IP o el puerto dentro del clúster de Amazon EKS. El ámbito de las políticas de red estándar es el espacio de nombres.

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.

Ejemplo

En la política siguiente, se restringe el tráfico de salida de los pods webapp en el espacio de nombres sun.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

La política se aplica a los pods con la etiqueta role: webapp en el espacio de nombres sun.

  • Tráfico permitido: pods con la etiqueta role: frontend en el espacio de nombres moon del puerto TCP 8080

  • Tráfico permitido: pods con la etiqueta de rol de frontend en el espacio de nombres stars del puerto TCP 8080

  • Tráfico bloqueado: se deniega implícitamente el resto del tráfico saliente de los pods webapp

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

Puede usar la ClusterNetworkPolicy para 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.

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.

Ejemplo

En la política siguiente, 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

Notas importantes

Las políticas de red del complemento CNI de Amazon VPC para Kubernetes se admiten en las configuraciones que se enumeran a continuación.

  • Versión 1.21.0 (o posterior) del complemento CNI de Amazon VPC para políticas de red estándar y de administración.

  • Clúster configurado para las direcciones IPv4 o IPv6.

  • Puede utilizar las políticas de red con los grupos de seguridad para pods. Con las políticas de red, puede controlar todas las comunicaciones dentro del clúster. Con los grupos de seguridad para pods, puede controlar el acceso a servicios de AWS desde aplicaciones dentro de un pod.

  • Puede utilizar las políticas de red con las redes personalizadas y la delegación de prefijos.

Consideraciones

Arquitectura

  • Cuando se aplican las políticas de red del complemento CNI de Amazon VPC para Kubernetes a su clúster con el complemento CNI de Amazon VPC para Kubernetes, se pueden aplicar las políticas únicamente a los nodos de Linux de Amazon EC2. No se pueden aplicar las políticas a los nodos de Fargate o Windows.

  • Las políticas de red solo aplican direcciones IPv4 o IPv6, pero no ambas. En un clúster IPv4, la CNI de VPC asigna direcciones IPv4 a los pods y aplica políticas IPv4. En un clúster IPv6, la CNI de VPC asigna direcciones IPv6 a los pods y aplica políticas IPv6. Se ignora cualquier regla de política de red IPv4 aplicada a un clúster IPv6. Se ignora cualquier regla de política de red IPv6 aplicada a un clúster IPv4.

Políticas de red

  • Las políticas de red solo se aplican a los pods que forman parte de una implementación. No se pueden aplicar políticas de red a los pods independientes que no tengan un conjunto de metadata.ownerReferences.

  • Puede aplicar varias políticas de red al mismo pod. Cuando se han configurado dos o más políticas que seleccionan el mismo pod, todas las políticas se aplican al pod.

  • La cantidad máxima de combinaciones de puertos y protocolos para un único rango de direcciones IP (CIDR) es de 24 en todas las políticas de red. Los selectores, como namespaceSelector, se resuelven en uno o más CIDR. Si varios selectores se resuelven en un único CIDR o si especifica el mismo CIDR directo varias veces en la misma o en diferentes políticas de red, todos estos cuentan para este límite.

  • Para cualquiera de sus servicios de Kubernetes, el puerto de servicio debe ser el mismo que el puerto del contenedor. Si utiliza puertos con nombre, utilice también el mismo nombre en la especificación del servicio.

Políticas de red de administración

  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 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 a continuación los recursos de la NetworkPolicy 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.

Migración

  • Si su clúster utiliza actualmente una solución de terceros para la administración de políticas de red de Kubernetes, puede usar esas mismas políticas con el complemento CNI de Amazon VPC para Kubernetes. Sin embargo, debe eliminar la solución existente para que no administre las mismas políticas.

aviso

Se recomienda que, después de eliminar una solución de política de red, reemplace todos los nodos a los que se haya aplicado la solución de política de red. Esto se debe a que las reglas de tráfico podrían quedar desfasadas si un pod de la solución se cierra repentinamente.

Instalación

  • La característica de política de red crea y requiere una definición de recurso personalizada (CRD) de PolicyEndpoint llamada policyendpoints.networking.k8s.aws. Amazon EKS administra los objetos PolicyEndpoint del recurso personalizado. No se deben modificar ni eliminar estos recursos.

  • Si ejecuta pods que utilizan las credenciales de IAM del rol de instancia o se conectan al IMDS de EC2, compruebe si hay políticas de red que puedan bloquear el acceso al IMDS de EC2. Puede que tenga que añadir una política de red para permitir el acceso al IMDS de EC2. Para obtener más información, consulte Metadatos de instancia y datos de usuario en la guía del usuario de Amazon EC2.

    Los pods que utilizan los roles de IAM para cuentas de servicio o Pod Identity de EKS no acceden al IMDS de EC2.

  • El complemento CNI de Amazon VPC para Kubernetes no aplica políticas de red a las interfaces de red adicionales de cada pod, solo a la interfaz principal de cada pod (eth0). Esta característica afecta a las siguientes arquitecturas:

    • Pods IPv6 con la variable ENABLE_V4_EGRESS establecida en true. Esta variable habilita la característica de salida IPv4 para conectar los pods IPv6 a puntos de conexión IPv4, como aquellos fuera del clúster. La característica de salida IPv4 funciona mediante la creación de una interfaz de red adicional con una dirección IPv4 de bucle invertido local.

    • Cuando se utilizan complementos de red encadenados, como Multus. Debido a que estos complementos añaden interfaces de red a cada pod, las políticas de red no se aplican a los complementos de red encadenados.