Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Grupos de seguridad por pod

Un grupo AWS de seguridad actúa como un firewall virtual para que EC2 las instancias controlen el tráfico entrante y saliente. De forma predeterminada, Amazon VPC CNI utilizará grupos de seguridad asociados al principal ENI del nodo. Más específicamente, todos los ENI asociados a la instancia tendrán los mismos grupos EC2 de seguridad. Por lo tanto, cada pod de un nodo comparte los mismos grupos de seguridad que el nodo en el que se ejecuta.

Como se ve en la imagen siguiente, todos los pods de aplicaciones que funcionen en los nodos de trabajo tendrán acceso al servicio de RDS base de datos (teniendo RDS en cuenta que los nodos entrantes permiten el grupo de seguridad de nodos). Los grupos de seguridad son demasiado generales porque se aplican a todos los pods que se ejecutan en un nodo. Los grupos de seguridad para Pods permiten segmentar la red de las cargas de trabajo, lo que constituye una parte esencial de una buena estrategia de defensa exhaustiva.

Con los grupos de seguridad para los pods, puede mejorar la eficiencia informática al ejecutar aplicaciones con diferentes requisitos de seguridad de red en recursos informáticos compartidos. Se pueden definir varios tipos de reglas de seguridad, como Pod-to-Pod las de Pod-to-External AWS servicios, en un solo lugar con grupos de EC2 seguridad y aplicarlos a las cargas de trabajo con Kubernetes nativo. APIs La siguiente imagen muestra los grupos de seguridad aplicados a nivel de pod y cómo simplifican la implementación de las aplicaciones y la arquitectura de los nodos. El Pod ahora puede acceder a la RDS base de datos de Amazon.

Puedes habilitar los grupos de seguridad para los pods configurando esta opción ENABLE_POD_ENI=true VPCCNI. Una vez activado, el controlador de VPC recursos que se ejecuta en el plano de control (gestionado porEKS) crea y conecta una interfaz troncal denominada «`aws-k8 s-trunk-eni «`al nodo. La interfaz troncal actúa como una interfaz de red estándar conectada a la instancia. Para gestionar las interfaces troncales, debes añadir la política AmazonEKSVPCResourceController gestionada al rol de clúster que acompaña a tu EKS clúster de Amazon.

El controlador también crea interfaces de rama denominadas «aws-k8s-branch-eni» y las asocia a la interfaz troncal. A los pods se les asigna un grupo de seguridad mediante el recurso SecurityGroupPolicypersonalizado y se asocian a una interfaz de sucursal. Como los grupos de seguridad se especifican con interfaces de red, ahora podemos programar pods que requieran grupos de seguridad específicos en estas interfaces de red adicionales. Consulta la sección de la guía del EKS usuario sobre los grupos de seguridad para los pods, incluidos los requisitos previos de implementación.

La capacidad de la interfaz de sucursal se suma a los límites de tipos de instancia existentes para las direcciones IP secundarias. Los pods que usan grupos de seguridad no se tienen en cuenta en la fórmula de max-pods y, si usas un grupo de seguridad para los pods, debes considerar la posibilidad de aumentar el valor de max-pods o estar de acuerdo con ejecutar menos pods de los que el nodo realmente puede admitir.

Un m5.large puede tener hasta 9 interfaces de red de sucursales y hasta 27 direcciones IP secundarias asignadas a sus interfaces de red estándar. Como se muestra en el siguiente ejemplo, el número máximo de pods predeterminado para un m5.large es 29 y EKS cuenta los pods que utilizan grupos de seguridad para calcular el número máximo de pods. Consulta la guía del EKS usuario para obtener instrucciones sobre cómo cambiar los max-pods de los nodos.

Cuando los grupos de seguridad para los pods se utilizan en combinación con redes personalizadas, se utiliza el grupo de seguridad definido en los grupos de seguridad para los pods en lugar del grupo de seguridad especificado en el. ENIConfig Como resultado, cuando las redes personalizadas estén habilitadas, evalúe cuidadosamente el orden de los grupos de seguridad y utilice los grupos de seguridad por pod.

Recomendaciones

Desactive TCP Early Demux para Liveness Probe

Si utilizas sondas de activación o preparación, también tendrás que deshabilitar la función de demux TCP temprana para que el kubelet pueda conectarse a los pods de las interfaces de red de las sucursales mediante. TCP Esto solo es necesario en modo estricto. Para ello, ejecute el siguiente comando:

kubectl edit daemonset aws-node -n kube-system

En la initContainer sección, cambie el valor de DISABLE_TCP_EARLY_DEMUX a true.

Utilice Security Group For Pods para aprovechar la inversión en AWS configuración existente.

Los grupos de seguridad facilitan la restricción del acceso de la red a VPC los recursos, como RDS bases de datos o EC2 instancias. Una clara ventaja de los grupos de seguridad por pod es la oportunidad de reutilizar los recursos de los grupos AWS de seguridad existentes. Si utilizas grupos de seguridad como firewall de red para limitar el acceso a tus AWS servicios, te proponemos aplicar grupos de seguridad a los pods mediante una sucursalENIs. Considera la posibilidad de usar grupos de seguridad para los pods si estás transfiriendo aplicaciones de EC2 instancias a otros servicios EKS y limita el acceso a otros AWS servicios con grupos de seguridad.

Configura el modo de aplicación del grupo de seguridad de Pod

La versión 1.11 del VPC CNI complemento de Amazon agregó una nueva configuración denominada POD_SECURITY_GROUP_ENFORCING_MODE («modo de aplicación»). El modo de aplicación controla qué grupos de seguridad se aplican al pod y si la fuente NAT está habilitada. Puede especificar el modo de aplicación como estricto o estándar. Estricto es el valor predeterminado, lo que refleja el comportamiento anterior del parámetro VPC CNI con el valor ENABLE_POD_ENI establecido en. true

En el modo estricto, solo se aplican los grupos ENI de seguridad de las sucursales. La fuente también NAT está deshabilitada.

En el modo estándar, se aplican los grupos de seguridad asociados a la rama principal ENI y a la rama ENI (asociada al pod). El tráfico de red debe cumplir con ambos grupos de seguridad.

Modo obligatorio: utilice el modo estricto para aislar el tráfico de nodos y pods:

De forma predeterminada, los grupos de seguridad de los pods están configurados en «modo estricto». Usa esta configuración si debes separar completamente el tráfico del pod del resto del tráfico del nodo. En modo estricto, la fuente NAT está apagada para poder utilizar los grupos de seguridad ENI salientes de la rama.

Modo obligatorio: utilice el modo estándar en las siguientes situaciones

La IP de origen del cliente es visible para los contenedores del pod

Si necesitas mantener la IP de origen del cliente visible para los contenedores del pod, considera POD_SECURITY_GROUP_ENFORCING_MODE configurarla enstandard. Los servicios de Kubernetes admiten externalTrafficPolicy =local para permitir la conservación de la IP de origen del cliente (tipo clúster de tipo predeterminado). Ahora puedes ejecutar servicios de Kubernetes de este tipo NodePort y LoadBalancer usar instancias de destino externalTrafficPolicy configuradas en Local en el modo estándar. Localconserva la IP de origen del cliente y evita un segundo salto de tipo Servicios LoadBalancer . NodePort

Despliegue NodeLocal DNSCache

Cuando utilices grupos de seguridad para los pods, configura el modo estándar para que sea compatible con los pods que los usen NodeLocal DNSCache. NodeLocal DNSCachemejora el DNS rendimiento del clúster al ejecutar un agente de almacenamiento en DNS caché en los nodos del clúster como un DaemonSet. Esto permitirá que los módulos con los DNS QPS requisitos más exigentes consulten el Kube-DNS/Core local con una caché local, lo DNS que mejorará la latencia.

NodeLocal DNSCacheno se admite en el modo estricto, ya que todo el tráfico de la red, incluso el que se dirige al nodo, entra en. VPC

Compatible con la política de red de Kubernetes

Recomendamos utilizar el modo de aplicación estándar cuando se utilice la política de red con los pods que tengan grupos de seguridad asociados.

Recomendamos encarecidamente utilizar grupos de seguridad para los pods a fin de limitar el acceso a nivel de red a AWS los servicios que no forman parte de un clúster. Ten en cuenta las políticas de red para restringir el tráfico de red entre los pods de un clúster, lo que suele denominarse tráfico este/oeste.

Identifique las incompatibilidades con los grupos de seguridad por pod

Las instancias basadas en Windows y las que no son de Nitro no admiten grupos de seguridad para los pods. Para utilizar grupos de seguridad con los pods, las instancias deben estar etiquetadas con. isTrunkingEnabled Usa políticas de red para administrar el acceso entre los Pods en lugar de entre grupos de seguridad si tus Pods no dependen de ningún AWS servicio interno o externo al tuyoVPC.

Usa grupos de seguridad por pod para controlar de manera eficiente el tráfico a AWS los servicios

Si una aplicación que se ejecuta en el EKS clúster tiene que comunicarse con otro recurso del clústerVPC, por ejemplo, una RDS base de datos, considere la posibilidad de utilizarla SGs para los pods. Si bien hay motores de políticas que permiten especificar un nombre CIDR o un DNS nombre, son una opción menos óptima cuando se comunica con AWS servicios que tienen puntos finales que residen dentro de unVPC.

Por el contrario, las políticas de red de Kubernetes proporcionan un mecanismo para controlar el tráfico de entrada y salida tanto dentro como fuera del clúster. Se deben tener en cuenta las políticas de red de Kubernetes si la aplicación tiene dependencias limitadas de otros servicios. AWS Puedes configurar políticas de red que especifiquen reglas de salida en función de los CIDR rangos para limitar el acceso a los AWS servicios, en lugar de hacerlo con la semántica nativa. AWS SGs Puedes usar las políticas de red de Kubernetes para controlar el tráfico de red entre los pods (a menudo denominado tráfico este/oeste) y entre los pods y los servicios externos. Las políticas de red de Kubernetes se implementan en los niveles 3 y 4. OSI

Amazon te EKS permite utilizar motores de políticas de red como Calico y Cilium. De forma predeterminada, los motores de políticas de red no están instalados. Consulte las guías de instalación correspondientes para obtener instrucciones sobre cómo configurarlos. Para obtener más información sobre cómo utilizar la política de red, consulta las prácticas recomendadas de EKS seguridad. La función de DNS nombres de host está disponible en las versiones empresariales de los motores de políticas de red, lo que podría resultar útil para controlar el tráfico entre los servicios o pods de Kubernetes y los recursos que se ejecutan fuera de ellos. AWS Además, puedes considerar la posibilidad de admitir DNS nombres de host para los AWS servicios que no admiten grupos de seguridad de forma predeterminada.

Etiquete un solo grupo de seguridad para usar AWS Loadbalancer Controller

Cuando se asignan muchos grupos de seguridad a un pod, Amazon EKS recomienda etiquetar un solo grupo de seguridad como kubernetes.io/cluster/$namecompartido o propio. La etiqueta permite al AWS Loadbalancer Controller actualizar las reglas de los grupos de seguridad para dirigir el tráfico a los pods. Si solo se asigna un grupo de seguridad a un pod, la asignación de una etiqueta es opcional. Los permisos establecidos en un grupo de seguridad son acumulativos, por lo que basta con etiquetar un único grupo de seguridad para que el controlador del balanceador de cargas localice y concilie las reglas. También ayuda a cumplir las cuotas predeterminadas definidas por los grupos de seguridad.

Configure NAT para el tráfico saliente

NATLa fuente está deshabilitada para el tráfico saliente de los pods a los que se les han asignado grupos de seguridad. En el caso de los pods que utilizan grupos de seguridad que requieren acceso a Internet, lance los nodos de trabajo en subredes privadas configuradas con una NAT puerta de enlace o instancia y habilite los externos SNAT en las. CNI

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

Implemente pods con grupos de seguridad en subredes privadas

Los pods a los que se les asignan grupos de seguridad deben ejecutarse en nodos que estén desplegados en subredes privadas. Ten en cuenta que los pods con grupos de seguridad asignados implementados en subredes públicas no podrán acceder a Internet.

Verifica los terminationGracePeriodsegundos en el archivo de especificaciones del pod

Asegúrese de que no terminationGracePeriodSeconds sea cero en el archivo de especificaciones del pod (30 segundos por defecto). Esto es esencial para VPC CNI que Amazon elimine la red Pod del nodo trabajador. Cuando se establece en cero, el CNI complemento no elimina la red Pod del host y la rama no ENI se limpia de manera efectiva.

Uso de grupos de seguridad para cápsulas con Fargate

Los grupos de seguridad para los pods que se ejecutan en Fargate funcionan de forma muy similar a los pods que se ejecutan en los nodos de EC2 trabajo. Por ejemplo, debe crear el grupo de seguridad antes de hacer referencia a él en el SecurityGroupPolicy que asocie a su Fargate Pod. De forma predeterminada, el grupo de seguridad del clúster se asigna a todos los Fargate Pods cuando no se asigna explícitamente SecurityGroupPolicy un a un Fargate Pod. Por motivos de simplicidad, es posible que desees añadir el grupo de seguridad del clúster al de un Fagate Pod SecurityGroupPolicy ; de lo contrario, tendrás que añadir las reglas mínimas del grupo de seguridad a tu grupo de seguridad. Puede encontrar el grupo de seguridad del clúster mediante el comando API describe-cluster.

 aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'

cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-fargate-sg-policy
  namespace: my-fargate-namespace
spec:
  podSelector:
    matchLabels:
      role: my-fargate-role
  securityGroups:
    groupIds:
      - cluster_security_group_id
      - my_fargate_pod_security_group_id
EOF

Las reglas mínimas del grupo de seguridad se muestran aquí. Estas reglas permiten que los Fargate Pods se comuniquen con servicios integrados en el clúster, como kube-apiserver, kubelet y Core. DNS También necesitas añadir reglas para permitir las conexiones entrantes y salientes desde y hacia tu Fargate Pod. Esto permitirá que tu Pod se comunique con otros Pods o recursos del tuyo. VPC Además, debes incluir reglas para que Fargate pueda extraer imágenes de contenedores de Amazon ECR u otros registros de contenedores, como. DockerHub Para obtener más información, consulta los rangos de direcciones AWS IP en la Referencia AWSgeneral.

Puedes usar los siguientes comandos para buscar los grupos de seguridad aplicados a un Fargate Pod.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Anote el comando eniId de arriba.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

Los pods Fargate existentes se deben eliminar y volver a crear para poder aplicar los nuevos grupos de seguridad. Por ejemplo, el siguiente comando inicia la implementación de la aplicación de ejemplo. Para actualizar pods específicos, puedes cambiar el espacio de nombres y el nombre de la implementación en el siguiente comando.

kubectl rollout restart -n example-ns deployment example-pod

📝 Edita esta página en GitHub