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
sugerencia
Explore las
Un grupo de seguridad de AWS actúa como un firewall virtual para que las instancias EC2 controlen el tráfico entrante y saliente. De forma predeterminada, el CNI de Amazon VPC utilizará grupos de seguridad asociados al ENI principal del nodo. Más específicamente, todos los ENI asociados a la instancia tendrán los mismos grupos de seguridad de EC2. 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 nodos de trabajo tendrán acceso al servicio de base de datos de RDS (teniendo en cuenta que la entrada de RDS permite la seguridad del grupo de nodos). Los grupos de seguridad son demasiado detallados porque se aplican a todos los pods que se ejecutan en un nodo. Los grupos de seguridad para los Pods permiten segmentar la red para las cargas de trabajo, lo cual es una parte esencial de una buena estrategia de defensa en profundidad.
Con los grupos de seguridad para Pods, puedes mejorar la eficiencia informática al ejecutar aplicaciones con diferentes requisitos de seguridad de red en recursos informáticos compartidos. Los grupos de seguridad de EC2 pueden definir varios tipos de reglas de seguridad, como Pod-to-Pod los servicios de Pod-to-External AWS, en un solo lugar y aplicarlos a las cargas de trabajo con las API nativas de Kubernetes. La siguiente imagen muestra los grupos de seguridad aplicados a nivel de pod y cómo simplifican la implementación de la aplicación y la arquitectura de nodos. El pod ahora puede acceder a la base de datos de Amazon RDS.
Puedes habilitar los grupos de seguridad para los pods configurando el CNI ENABLE_POD_ENI=true de la VPC. Una vez habilitada, la controladora de recursos de la VPC AmazonEKSVPCResourceController gestionada a la función de clúster que corresponde a su clúster de Amazon EKS.
El controlador también crea interfaces de sucursal 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 SecurityGroupPolicy
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 para obtener el número máximo de pods y, si usas un grupo de seguridad para los pods, debes considerar la posibilidad de aumentar el valor máximo de pods o aceptar 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 ejemplo siguiente, el número máximo de pods predeterminado para un m5.large es de 29, y EKS calcula el número máximo de pods que utilizan grupos de seguridad. Consulta la guía del usuario del EKS para obtener instrucciones sobre cómo cambiar el número máximo de pods por nodos.
Cuando los grupos de seguridad para los pods se utilizan en combinación con una red personalizada, se utiliza el grupo de seguridad definido en los grupos de seguridad para los pods en lugar del grupo de seguridad especificado en la ENIConfig. Por lo tanto, cuando se habilitan las redes personalizadas, evalúa cuidadosamente el orden de los grupos de seguridad mientras utilizas los grupos de seguridad por pod.
Recomendaciones
Deshabilite TCP Early Demux para Liveness Probe
Si utilizas sondeos de disponibilidad o disponibilidad, también debes deshabilitar la demultiplexación temprana de TCP para que el kubelet pueda conectarse a los pods de las interfaces de red de sucursales a través de TCP. Esto solo es necesario en el modo estricto. Para ello, ejecute el siguiente comando:
kubectl edit daemonset aws-node -n kube-system
En la initContainer sección, cambie el valor DISABLE_TCP_EARLY_DEMUX de true.
Utilice Security Group For Pods para aprovechar la inversión actual en configuración de AWS.
Los grupos de seguridad facilitan la restricción del acceso a la red a los recursos de la VPC, como las bases de datos de RDS o las instancias EC2. Una ventaja evidente de los grupos de seguridad por pod es la oportunidad de reutilizar los recursos de los grupos de seguridad de AWS existentes. Si utiliza grupos de seguridad como firewall de red para limitar el acceso a sus servicios de AWS, le proponemos aplicar grupos de seguridad a los pods que utilicen ENI de sucursales. Considera la posibilidad de usar grupos de seguridad para los pods si vas a transferir aplicaciones de instancias EC2 a EKS y limitar el acceso a otros servicios de AWS con grupos de seguridad.
Configure el modo de aplicación del grupo de seguridad de Pod
La versión 1.11 del complemento CNI de Amazon VPC añadió una nueva configuración denominada POD_SECURITY_GROUP_ENFORCING_MODE («modo de aplicación»). El modo de cumplimiento controla tanto los grupos de seguridad que se aplican al pod como si la NAT de origen está habilitada. Puede especificar el modo de aplicación como estricto o estándar. El valor predeterminado es estricto, lo que refleja el comportamiento anterior del CNI de la VPC con ENABLE_POD_ENI el valor establecido en. true
En el modo estricto, solo se aplican los grupos de seguridad ENI de la sucursal. La NAT de origen también está deshabilitada.
En el modo estándar, se aplican los grupos de seguridad asociados tanto al ENI principal como al ENI de sucursal (asociados al pod). El tráfico de red debe cumplir con ambos grupos de seguridad.
aviso
Cualquier cambio de modo solo afectará a los Pods recién lanzados. Los pods existentes usarán el modo que se configuró cuando se creó el pod. Los clientes deberán reciclar los Pods existentes con grupos de seguridad si quieren cambiar el comportamiento del tráfico.
Modo obligatorio: usa el modo estricto para aislar el tráfico de pods y nodos:
De forma predeterminada, los grupos de seguridad de los Pods están configurados en «modo estricto». Usa esta configuración si debes separar por completo el tráfico de los pods del resto del tráfico del nodo. En el modo estricto, la NAT de origen está desactivada para poder usar los grupos de seguridad salientes del ENI de la sucursal.
aviso
Cuando el modo estricto está habilitado, todo el tráfico saliente de un pod saldrá del nodo y entrará en la red de VPC. El tráfico entre los pods del mismo nodo pasará por la VPC. Esto aumenta el tráfico de la VPC y limita las funciones basadas en nodos. El NodeLocal DNSCache no es compatible con el modo estricto.
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 el comando external TrafficPolicy =local para preservar la IP de origen del cliente (clúster de tipo predeterminado). Ahora puedes ejecutar servicios de Kubernetes de tipo NodePort y LoadBalancer uso de destinos de instancia con una dirección externa TrafficPolicy configurada como Local en el modo estándar. Localconserva la IP de origen del cliente y evita que se produzca un segundo salto LoadBalancer y NodePort escriba Services.
Implementación de NodeLocal DNSCache
Cuando utilices grupos de seguridad para los pods, configura el modo estándar para que admitan los pods que utilizan NodeLocal DNSCache.
NodeLocal No se admite DNSCache en modo estricto, ya que todo el tráfico de red, incluso el que va al nodo, entra en la VPC.
Política de red compatible con Kubernetes
Te recomendamos usar el modo de ejecución estándar cuando utilices políticas de red con 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 los servicios de AWS que no forman parte de un clúster. Considera la posibilidad de aplicar políticas de red para restringir el tráfico de red entre los pods de un clúster, lo que suele East/West denominarse tráfico.
Identifica las incompatibilidades con los grupos de seguridad por pod
Windows-based y las instancias que no son nitro no admiten grupos de seguridad para los pods. Para utilizar los grupos de seguridad con los Pods, las instancias deben estar etiquetadas con este campo. TrunkingEnabled Usa políticas de red para gestionar el acceso entre pods en lugar de usar grupos de seguridad si tus pods no dependen de ningún servicio de AWS dentro o fuera de tu VPC.
Use grupos de seguridad por pod para controlar de manera eficiente el tráfico a los servicios de AWS
Si una aplicación que se ejecuta en el clúster de EKS tiene que comunicarse con otro recurso de la VPC, por ejemplo, una base de datos de RDS, considere la posibilidad de utilizar SGs para los pods. Si bien hay motores de políticas que permiten especificar un CIDR o un nombre DNS, son una opción menos óptima para comunicarse con los servicios de AWS que tienen puntos de enlace que residen en una VPC.
Por el contrario, las políticas de red de Kubernetes
Amazon EKS le permite utilizar motores de políticas de red como Calico
Etiquete un único grupo de seguridad para usar AWS Loadbalancer Controller
Cuando se asignan muchos grupos de seguridad a un pod, Amazon EKS recomienda etiquetar un único grupo de seguridad como kubernetes.io/cluster/$name compartido 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 con etiquetar un solo grupo de seguridad es suficiente para que el controlador del balanceador de carga localice y concilie las reglas. También ayuda a cumplir las cuotas predeterminadas definidas por los grupos de seguridad.
Configure la NAT para el tráfico saliente
La NAT de origen 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, lanza los nodos de trabajo en subredes privadas configuradas con una instancia o puerta de enlace de NAT y habilita la SNAT externa en el CNI.
kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true
Implementa 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 implementados 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.
Verificar terminación GracePeriodSeconds en el archivo de especificaciones del pod
Asegúrate de que no terminationGracePeriodSeconds sea cero en el archivo de especificaciones del pod (30 segundos por defecto). Esto es esencial para que el CNI de Amazon VPC elimine la red de pods del nodo de trabajo. Cuando se establece en cero, el complemento CNI no elimina la red de pods del host y el ENI de la sucursal no se limpia de forma eficaz.
Uso de grupos de seguridad para pods con Fargate
Los grupos de seguridad para los pods que se ejecutan en Fargate funcionan de manera muy similar a los de los pods que se ejecutan en los nodos de trabajo de EC2. Por ejemplo, debes crear el grupo de seguridad antes de hacer referencia a él en el que asocies a tu SecurityGroupPolicy Fargate Pod. De forma predeterminada, el grupo de seguridad del clúster se asigna a todos los Fargate Pods cuando no se asigna uno de forma explícita a un SecurityGroupPolicy Fargate Pod. Por motivos de simplicidad, es posible que desees añadir el grupo de seguridad del clúster a 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. Puedes encontrar el grupo de seguridad del clúster mediante la 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 enumeran aquí. https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html Estas reglas permiten que los Fargate Pods se comuniquen con servicios integrados en el clúster, como kube-apiserver, kubelet y CoreDNS. También necesitas agregar reglas para permitir las conexiones entrantes y salientes hacia y desde tu Fargate Pod. Esto permitirá que tu pod se comunique con otros pods o recursos de tu VPC. Además, debes incluir reglas para que Fargate extraiga imágenes de contenedores de Amazon ECR u otros registros de contenedores, por ejemplo. DockerHub Para obtener más información, consulte los intervalos de direcciones IP de AWS en la referencia general de AWS.
Puede usar los siguientes comandos para buscar los grupos de seguridad aplicados a un Fargate Pod.
kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.fargate\.amazonaws\.com/pod-sg}{"\n"}'
Anota el EniID del comando anterior.
aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'
Los pods de 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
