Protección de la infraestructura (hosts) - Amazon EKS
RecomendacionesAlternativasHerramientas y recursos

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.

Protección de la infraestructura (hosts)

Si bien es importante proteger las imágenes de los contenedores, es igual de importante proteger la infraestructura en la que se ejecutan. En esta sección, se analizan diferentes formas de mitigar los riesgos derivados de los ataques lanzados directamente contra el servidor. Estas directrices deben utilizarse junto con las descritas en la sección Seguridad en tiempo de ejecución.

Recomendaciones

Utilice un sistema operativo optimizado para ejecutar contenedores

Considere la posibilidad de usar Flatcar Linux, Project Atomic, RancherOS y Bottlerocket, un sistema operativo especial de AWS diseñado para ejecutar contenedores de Linux. Incluye una superficie de ataque reducida, una imagen de disco que se verifica al arrancar y límites de permisos obligatorios para su uso. SELinux

Como alternativa, utilice la AMI optimizada para EKS para sus nodos de trabajo de Kubernetes. La AMI optimizada para EKS se publica periódicamente y contiene un conjunto mínimo de paquetes de sistema operativo y binarios necesarios para ejecutar sus cargas de trabajo en contenedores.

Consulte la especificación de compilación de Amazon EKS AMI RHEL para ver un ejemplo de script de configuración que se puede utilizar para crear una AMI Amazon EKS personalizada que se ejecute en Red Hat Enterprise Linux mediante Hashicorp Packer. Este script se puede aprovechar aún más para crear EKS personalizados y compatibles con STIG. AMIs

Mantenga actualizado el sistema operativo de su nodo de trabajo

Independientemente de si utiliza un sistema operativo host optimizado para contenedores, como Bottlerocket, o un Amazon Machine Image más grande, pero aún minimalista, como el optimizado para EKS AMIs, se recomienda mantener estas imágenes del sistema operativo anfitrión actualizadas con los últimos parches de seguridad.

Si está optimizado para EKS AMIs, consulte periódicamente el registro de cambios o el canal de notas de la versión y automatice la distribución de las imágenes actualizadas de los nodos de trabajo en su clúster.

Trate su infraestructura como algo inmutable y automatice la sustitución de sus nodos de trabajo

En lugar de realizar actualizaciones in situ, sustituya a sus trabajadores cuando haya un nuevo parche o actualización disponible. Esto puede abordarse de dos maneras. Puede añadir instancias a un grupo de escalado automático existente mediante la AMI más reciente, ya que acordona y vacía los nodos de forma secuencial hasta que todos los nodos del grupo se sustituyan por la AMI más reciente. Como alternativa, puede añadir instancias a un nuevo grupo de nodos y, al mismo tiempo, acordonar y drenar los nodos del grupo de nodos anterior de forma secuencial hasta que se hayan reemplazado todos los nodos. Los grupos de nodos gestionados por EKS utilizan el primer enfoque y mostrarán un mensaje en la consola para actualizar a sus trabajadores cuando haya una nueva AMI disponible. eksctltambién tiene un mecanismo para crear grupos de nodos con la AMI más reciente y para acordonar y drenar correctamente los pods de los grupos de nodos antes de que se terminen las instancias. Si decide utilizar un método diferente para sustituir los nodos de trabajo, le recomendamos encarecidamente que automatice el proceso para minimizar la supervisión humana, ya que es probable que tenga que sustituir a los trabajadores periódicamente a medida que salgan nuevos nodos y cuando updates/patches se actualice el plano de control.

Con EKS Fargate, AWS actualizará automáticamente la infraestructura subyacente a medida que haya actualizaciones disponibles. A menudo, esto se puede hacer sin problemas, pero puede haber ocasiones en las que una actualización provoque que el pod se reprograme. Por lo tanto, le recomendamos que cree implementaciones con varias réplicas cuando ejecute la aplicación como un pod de Fargate.

Ejecute kube-bench periódicamente para verificar el cumplimiento de los puntos de referencia del CIS para Kubernetes

kube-bench es un proyecto de código abierto de Aqua que evalúa tu clúster comparándolo con los puntos de referencia del CIS para Kubernetes. El punto de referencia describe las mejores prácticas para proteger los clústeres de Kubernetes no gestionados. El índice de referencia de Kubernetes del CIS abarca el plano de control y el plano de datos. Dado que Amazon EKS proporciona un plano de control totalmente gestionado, no se aplican todas las recomendaciones del CIS Kubernetes Benchmark. Para garantizar que este ámbito refleje la forma en que se implementa Amazon EKS, AWS creó el Amazon EKS Benchmark de la CEI. El índice de referencia EKS proviene del Kubernetes Benchmark de CIS, con aportaciones adicionales de la comunidad y consideraciones de configuración específicas para los clústeres de EKS.

Cuando ejecutes kube-bench en un clúster de EKS, sigue estas instrucciones de Aqua Security. Para obtener más información, consulte Presentamos el Amazon EKS Benchmark de la CEI.

Minimice el acceso a los nodos de trabajo

En lugar de habilitar el acceso SSH, utilice el administrador de sesiones SSM cuando necesite acceder de forma remota a un host. A diferencia de las claves SSH, que se pueden perder, copiar o compartir, el administrador de sesiones le permite controlar el acceso a las EC2 instancias mediante IAM. Además, proporciona una pista de auditoría y un registro de los comandos que se ejecutaron en la instancia.

A partir del 19 de agosto de 2020, los grupos de nodos gestionados admiten plantillas personalizadas AMIs y de EC2 lanzamiento. Esto le permite incrustar el agente SSM en la AMI o instalarlo mientras se inicia el nodo de trabajo. Si prefiere no modificar la AMI optimizada ni la plantilla de lanzamiento del ASG, puede instalar el agente SSM con una, DaemonSet como en este ejemplo.

Política de IAM mínima para el acceso SSH basado en SSM

La política administrada por AmazonSSMManagedInstanceCore AWS contiene una serie de permisos que no son necesarios para SSM Session Manager/SSM RunCommand si solo quiere evitar el acceso a SSH. En concreto, son motivo de preocupación los * permisos ssm:GetParameter(s) que permitirían al rol acceder a todos los parámetros del almacén de parámetros (incluso SecureStrings con la clave de KMS administrada por AWS configurada).

La siguiente política de IAM contiene el conjunto mínimo de permisos para permitir el acceso a los nodos a través de SSM Systems Manager.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableAccessViaSSMSessionManager",
      "Effect": "Allow",
      "Action": [
        "ssmmessages:OpenDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:CreateControlChannel",
        "ssm:UpdateInstanceInformation"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnableSSMRunCommand",
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ec2messages:SendReply",
        "ec2messages:GetMessages",
        "ec2messages:GetEndpoint",
        "ec2messages:FailMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:AcknowledgeMessage"
      ],
      "Resource": "*"
    }
  ]
}

Una vez implementada esta política y el complemento Session Manager instalado, puede ejecutar

aws ssm start-session --target [INSTANCE_ID_OF_EKS_NODE]

para acceder al nodo.

nota

También puede considerar la posibilidad de añadir permisos para habilitar el registro del administrador de sesiones.

Despliegue a los trabajadores en subredes privadas

Al desplegar a los trabajadores en subredes privadas, se minimiza su exposición a Internet, donde suelen originarse los ataques. A partir del 22 de abril de 2020, la subred en la que se desplieguen controlará la asignación de direcciones IP públicas a los nodos de un grupo de nodos gestionado. Antes de esto, a los nodos de un grupo de nodos gestionado se les asignaba automáticamente una IP pública. Si decide implementar sus nodos de trabajo en subredes públicas, implemente reglas restrictivas de grupos de seguridad de AWS para limitar su exposición.

Ejecute Amazon Inspector para evaluar la exposición, las vulnerabilidades y las desviaciones de los hosts con respecto a las mejores prácticas

Puede utilizar Amazon Inspector para comprobar si hay accesos no intencionados a la red a sus nodos y si hay vulnerabilidades en las EC2 instancias de Amazon subyacentes.

Amazon Inspector puede proporcionar datos sobre vulnerabilidades y exposiciones comunes (CVE) para sus EC2 instancias de Amazon solo si el agente Amazon EC2 Systems Manager (SSM) está instalado y activado. Este agente viene preinstalado en varias Amazon Machine Images (AMIs), incluido Amazon Linux AMIs optimizado para EKS. Independientemente del estado del agente de SSM, todas tus EC2 instancias de Amazon se escanean para detectar problemas de accesibilidad de la red. Para obtener más información sobre la configuración de escaneos para Amazon EC2, consulta Escanear EC2 instancias de Amazon.

importante

El Inspector no se puede ejecutar en la infraestructura utilizada para ejecutar los pods de Fargate.

Alternativas

¡Corre SELinux

nota

Disponible en Red Hat Enterprise Linux (RHEL), CentOS, Bottlerocket y Amazon Linux 2023

SELinux proporciona una capa de seguridad adicional para mantener los contenedores aislados unos de otros y del host. SELinux permite a los administradores aplicar controles de acceso (MAC) obligatorios para cada usuario, aplicación, proceso y archivo. Considérelo como un mecanismo de salvaguardia que restringe las operaciones que se pueden realizar con recursos específicos en función de un conjunto de etiquetas. En EKS, se SELinux puede usar para evitar que los contenedores accedan a los recursos de los demás.

Las SELinux políticas de contenedores se definen en el paquete container-selinux. Docker CE requiere este paquete (junto con sus dependencias) para que los procesos y archivos creados por Docker (u otros entornos de ejecución de contenedores) se ejecuten con un acceso limitado al sistema. Los contenedores utilizan la container_t etiqueta a la que sirve de alias. svirt_lxc_net_t Estas políticas impiden eficazmente que los contenedores accedan a determinadas funciones del servidor.

Cuando se configura SELinux para Docker, Docker etiqueta automáticamente las cargas de trabajo container_t como un tipo y asigna a cada contenedor un nivel de MCS único. Esto aislará los contenedores unos de otros. Si necesita restricciones más flexibles, puede crear su propio perfil en el SElinux que se concedan permisos a un contenedor para acceder a áreas específicas del sistema de archivos. Esto es similar a PSPs que puedes crear diferentes perfiles para distintos contenedores o pods. Por ejemplo, puede tener un perfil para cargas de trabajo generales con un conjunto de controles restrictivos y otro para las cosas que requieren un acceso privilegiado.

SELinux for Containers tiene un conjunto de opciones que se pueden configurar para modificar las restricciones predeterminadas. Los siguientes valores SELinux booleanos se pueden activar o desactivar en función de sus necesidades:

Booleano Predeterminado/a Descripción

container_connect_any

off

Permita que los contenedores accedan a los puertos privilegiados del host. Por ejemplo, si tiene un contenedor que necesita asignar los puertos 443 u 80 del host.

container_manage_cgroup

off

Permita que los contenedores administren la configuración del grupo. Por ejemplo, un contenedor que ejecute systemd necesitará que esté habilitado.

container_use_cephfs

off

Permita que los contenedores usen un sistema de archivos ceph.

De forma predeterminada, los contenedores pueden guardar /usr y read/execute leer la mayor parte del /etc contenido. Los archivos que están debajo /var/lib/docker y /var/lib/containers tienen la etiquetacontainer_var_lib_t. Para ver una lista completa de los valores predeterminados, las etiquetas consultan el archivo container.fc.

docker container run -it \
  -v /var/lib/docker/image/overlay2/repositories.json:/host/repositories.json \
  centos:7 cat /host/repositories.json
# cat: /host/repositories.json: Permission denied

docker container run -it \
  -v /etc/passwd:/host/etc/passwd \
  centos:7 cat /host/etc/passwd
# cat: /host/etc/passwd: Permission denied

Los archivos etiquetados con container_file_t son los únicos archivos en los que los contenedores pueden escribir. Si desea que se pueda escribir en un montaje de volumen, tendrá que especificar :z o al :Z final.

  • :zvolverá a etiquetar los archivos para que el contenedor pueda leer/escribir

  • :Zvolverá a etiquetar los archivos para que solo el contenedor pueda leer/escribir

ls -Z /var/lib/misc
# -rw-r--r--. root root system_u:object_r:var_lib_t:s0   postfix.aliasesdb-stamp

docker container run -it \
  -v /var/lib/misc:/host/var/lib/misc:z \
  centos:7 echo "Relabeled!"

ls -Z /var/lib/misc
#-rw-r--r--. root root system_u:object_r:container_file_t:s0 postfix.aliasesdb-stamp
docker container run -it \
  -v /var/log:/host/var/log:Z \
  fluentbit:latest

En Kubernetes, el reetiquetado es ligeramente diferente. En lugar de hacer que Docker vuelva a etiquetar automáticamente los archivos, puede especificar una etiqueta MCS personalizada para ejecutar el pod. Los volúmenes que admiten el reetiquetado se volverán a etiquetar automáticamente para que sean accesibles. Los módulos que tengan la etiqueta MCS correspondiente podrán acceder al volumen. Si necesitas un aislamiento estricto, establece una etiqueta MCS diferente para cada cápsula.

securityContext:
  seLinuxOptions:
    # Provide a unique MCS label per container
    # You can specify user, role, and type also
    # enforcement based on type and level (svert)
    level: s0:c144:c154

En este ejemplo, s0:c144:c154 corresponde a una etiqueta MCS asignada a un archivo al que el contenedor puede acceder.

En EKS, puede crear políticas que permitan la ejecución de contenedores privilegiados, como FluentD, y crear SELinux una política que le permita leer desde /var/log en el host sin necesidad de volver a etiquetar el directorio del host. Los pods con la misma etiqueta podrán acceder a los mismos volúmenes del host.

Hemos implementado un ejemplo AMIs para Amazon EKS que se ha SELinux configurado en Centos 7 y RHEL 7. AMIs Se desarrollaron para mostrar ejemplos de implementaciones que cumplen con los requisitos de los clientes altamente regulados.

aviso

SELinux ignorará los contenedores cuyo tipo no esté confinado.

Herramientas y recursos