Seguridad de imagen - Amazon EKS
RecomendacionesHerramientas 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.

Seguridad de imagen

Debe considerar la imagen del contenedor como su primera línea de defensa contra un ataque. Una imagen insegura y mal construida puede permitir que un atacante escape de los límites del contenedor y acceder al host. Una vez en el host, un atacante puede acceder a información confidencial o moverse lateralmente dentro del clúster o con su cuenta de AWS. Las siguientes prácticas recomendadas ayudarán a mitigar el riesgo de que esto ocurra.

Recomendaciones

Crea imágenes mínimas

Comience por eliminar todos los archivos binarios extraños de la imagen del contenedor. Si utilizas una imagen desconocida de Dockerhub, inspecciona la imagen con una aplicación como Dive, que puede mostrarte el contenido de cada una de las capas del contenedor. Elimine todos los archivos binarios con los bits SETUID y SETGID, ya que pueden usarse para aumentar los privilegios, y considere la posibilidad de eliminar todos los comandos y utilidades, como nc y curl, que puedan usarse con fines perversos. Puede encontrar los archivos con los bits SETUID y SETGID con el siguiente comando:

find / -perm /6000 -type f -exec ls -ld {} \;

Para eliminar los permisos especiales de estos archivos, añade la siguiente directiva a la imagen del contenedor:

RUN find / -xdev -perm /6000 -type f -exec chmod a-s {} \; || true

Coloquialmente, esto se conoce como quitar los colmillos de la imagen.

Usa compilaciones de varias etapas

El uso de compilaciones de varias etapas es una forma de crear imágenes mínimas. A menudo, las compilaciones en varias etapas se utilizan para automatizar partes del ciclo de integración continua. Por ejemplo, las compilaciones en varias etapas se pueden usar para borrar el código fuente o realizar un análisis de código estático. Esto brinda a los desarrolladores la oportunidad de obtener comentarios casi inmediatos en lugar de esperar a que se ejecute una canalización. Las compilaciones en varias etapas son atractivas desde el punto de vista de la seguridad porque permiten minimizar el tamaño de la imagen final que se inserta en el registro del contenedor. Las imágenes de contenedores sin herramientas de compilación ni otros binarios desconocidos mejoran la seguridad al reducir la superficie expuesta a ataques de la imagen. Para obtener información adicional sobre las compilaciones de varias etapas, consulta la documentación de compilaciones de varias etapas de Docker.

Cree una lista de materiales de software (SBOMs) para la imagen de su contenedor

Una «lista de materiales de software» (SBOM) es un inventario anidado de los artefactos de software que componen la imagen del contenedor. La SBOM es un elemento fundamental de la seguridad del software y de la gestión del riesgo de la cadena de suministro de software. Generar y almacenar los SBOMS en un repositorio central y analizarlos en busca SBOMs de vulnerabilidades ayuda a resolver los siguientes problemas:

  • Visibilidad: comprenda qué componentes componen la imagen de su contenedor. El almacenamiento en un repositorio central permite SBOMs auditarlo y escanearlo en cualquier momento, incluso después del despliegue, para detectar nuevas vulnerabilidades y responder a ellas, como las de día cero.

  • Verificación de procedencia: garantía de que las suposiciones existentes sobre dónde y cómo se origina un artefacto son ciertas y de que el artefacto o los metadatos que lo acompañan no han sido manipulados durante los procesos de construcción o entrega.

  • Fiabilidad: garantía de que se puede confiar en que un artefacto determinado y su contenido harán lo que se supone que hacen, es decir, que son adecuados para un propósito. Esto implica juzgar si el código es seguro de ejecutar y tomar decisiones informadas sobre los riesgos asociados a la ejecución del código. La confiabilidad se garantiza mediante la creación de un informe de ejecución de la canalización certificado junto con un informe de escaneo certificado de la SBOM y del CVE acreditado para garantizar a los consumidores de la imagen que, de hecho, la imagen se creó por medios seguros (canalización) con componentes seguros.

  • Verificación de la confianza en la dependencia: comprobación recursiva del árbol de dependencias de un artefacto para comprobar la fiabilidad y la procedencia de los artefactos que utiliza. Drift in SBOMs puede ayudar a detectar actividades maliciosas, incluidas las dependencias no autorizadas y no confiables y los intentos de infiltración.

Se pueden utilizar las siguientes herramientas para generar la SBOM:

  • Amazon Inspector se puede utilizar para crear y exportar SBOMs.

  • Syft de Anchore también se puede utilizar para la generación de SBOM. Para que los escaneos de vulnerabilidades sean más rápidos, la SBOM generada para la imagen de un contenedor se puede utilizar como entrada para escanear. A continuación, la SBOM y el informe de escaneo se certifican y se adjuntan a la imagen antes de enviarla a un repositorio OCI central, como Amazon ECR, para su revisión y auditoría.

Obtenga más información sobre cómo proteger su cadena de suministro de software consultando la guía de mejores prácticas de la cadena de suministro de software de la CNCF.

Escanee las imágenes en busca de vulnerabilidades con regularidad

Al igual que sus homólogas de máquinas virtuales, las imágenes de los contenedores pueden contener archivos binarios y bibliotecas de aplicaciones con vulnerabilidades o desarrollar vulnerabilidades con el tiempo. La mejor forma de protegerse contra las vulnerabilidades es escanear las imágenes con regularidad con un escáner de imágenes. Las imágenes almacenadas en Amazon ECR se pueden escanear de forma automática o bajo demanda (una vez durante un período de 24 horas). Actualmente, el ECR admite dos tipos de digitalización: básica y mejorada. El escaneo básico aprovecha Clair, una solución de escaneo de imágenes de código abierto sin costo alguno. El escaneado mejorado utiliza Amazon Inspector para ofrecer escaneos continuos automáticos con un coste adicional. Una vez escaneada una imagen, los resultados se registran en el flujo de eventos para que se registre el ECR. EventBridge También puede ver los resultados de un escaneo desde la consola de ECR. Las imágenes con una vulnerabilidad ALTA o CRÍTICA deben borrarse o reconstruirse. Si una imagen que se ha implementado presenta una vulnerabilidad, debe sustituirse lo antes posible.

Saber dónde se han desplegado las imágenes con vulnerabilidades es esencial para mantener su entorno seguro. Si bien podría crear una solución de seguimiento de imágenes usted mismo, ya existen varias ofertas comerciales que ofrecen esta y otras funciones avanzadas listas para usar, entre las que se incluyen:

También se podría utilizar un webhook de validación de Kubernetes para validar que las imágenes estén libres de vulnerabilidades críticas. Los webhooks de validación se invocan antes que la API de Kubernetes. Por lo general, se utilizan para rechazar solicitudes que no cumplen con los criterios de validación definidos en el webhook. Este es un ejemplo de un webhook sin servidor que llama a la API ECR describeImageScan Findings para determinar si un módulo está extrayendo una imagen con vulnerabilidades críticas. Si se encuentran vulnerabilidades, se rechaza el pod y se devuelve un mensaje con la lista de CVEs como evento.

Usa atestaciones para validar la integridad del artefacto

Una certificación es una «declaración» firmada criptográficamente en la que se afirma que algo (un «predicado», por ejemplo, un oleoducto o la SBOM o el informe de análisis de vulnerabilidades) es cierto sobre otra cosa, un «sujeto», es decir, la imagen del contenedor.

Las atestaciones ayudan a los usuarios a validar que un artefacto proviene de una fuente confiable de la cadena de suministro del software. Por ejemplo, podemos usar una imagen contenedora sin conocer todos los componentes o dependencias del software que se incluyen en esa imagen. Sin embargo, si confiamos en lo que diga el productor de la imagen del contenedor sobre el software presente, podemos usar la certificación del productor para basarnos en ese artefacto. Esto significa que podemos proceder a utilizar el artefacto de forma segura en nuestro flujo de trabajo en lugar de haber realizado el análisis nosotros mismos.

Cree políticas de IAM para los repositorios de ECR

Hoy en día, no es raro que una organización tenga varios equipos de desarrollo que operen de forma independiente dentro de una cuenta de AWS compartida. Si estos equipos no necesitan compartir activos, puede crear un conjunto de políticas de IAM que restrinjan el acceso a los repositorios con los que cada equipo puede interactuar. Una buena forma de implementar esto es mediante el uso de espacios de nombres ECR. Los espacios de nombres son una forma de agrupar repositorios similares. Por ejemplo, todos los registros del equipo A pueden ir precedidos del team-a/, mientras que los del equipo B pueden usar el prefijo team-b/. La política para restringir el acceso podría tener el siguiente aspecto:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPushPull",
      "Effect": "Allow",
      "Action": [
        "ecr:GetDownloadUrlForLayer",
        "ecr:BatchGetImage",
        "ecr:BatchCheckLayerAvailability",
        "ecr:PutImage",
        "ecr:InitiateLayerUpload",
        "ecr:UploadLayerPart",
        "ecr:CompleteLayerUpload"
      ],
      "Resource": [
        "arn:aws:ecr:<region>:<account_id>:repository/team-a/*"
      ]
    }
  ]
}

Considere la posibilidad de utilizar puntos finales privados de ECR

La API de ECR tiene un punto final público. En consecuencia, se puede acceder a los registros del ECR desde Internet siempre que la solicitud haya sido autenticada y autorizada por el IAM. Para aquellos que necesiten operar en un entorno aislado en el que la VPC del clúster carece de Internet Gateway (IGW), pueden configurar un punto de conexión privado para ECR. La creación de un punto final privado le permite acceder de forma privada a la API de ECR a través de una dirección IP privada en lugar de enrutar el tráfico a través de Internet. Para obtener información adicional sobre este tema, consulte Puntos de enlace de VPC de la interfaz Amazon ECR.

Implemente políticas de puntos finales para ECR

La política de puntos finales predeterminada permite el acceso a todos los repositorios de ECR de una región. Esto podría permitir attacker/insider a una persona filtrar datos empaquetándolos como una imagen de contenedor y enviándolos a un registro de otra cuenta de AWS. Para mitigar este riesgo, es necesario crear una política de puntos finales que limite el acceso de la API a los repositorios de ECR. Por ejemplo, la siguiente política permite que todos los principios de AWS de su cuenta realicen todas las acciones contra sus repositorios de ECR y solo contra los suyos:

{
  "Statement": [
    {
      "Sid": "LimitECRAccess",
      "Principal": "*",
      "Action": "*",
      "Effect": "Allow",
      "Resource": "arn:aws:ecr:<region>:<account_id>:repository/*"
    }
  ]
}

Puede mejorarlo aún más si establece una condición que utilice el nuevo PrincipalOrgID atributo, lo que impedirá la aparición pushing/pulling de imágenes según un principio de IAM que no forme parte de su organización de AWS. Consulte aws: PrincipalOrg ID para obtener más información. Recomendamos aplicar la misma política tanto a los puntos de conexión com.amazonaws.<region>.ecr.dkr como a los com.amazonaws.<region>.ecr.api. Dado que EKS extrae imágenes de kube-proxy, coredns y aws-node del ECR, tendrá que añadir el ID de cuenta del registro, por ejemplo, a la lista de recursos de la política de puntos finales o modificar la política 602401143452.dkr.ecr.us-west-2.amazonaws.com/ para permitir la extracción de datos y restringir los envíos a su ID de cuenta. En la siguiente tabla se muestra el mapeo entre las cuentas de AWS desde las que se venden las imágenes de EKS y la región del clúster.

Account Number (Número de cuenta) Región

602401143452

Todas las regiones comerciales, excepto las que se indican a continuación

—

—

800184023465

ap-east-1 - Asia-Pacífico (Hong Kong)

558608220178

me-south-1 - Oriente Medio (Baréin)

918309763551

cn-north-1 - China (Pekín)

961992271922

cn-northwest-1 - China (Ningxia)

Para obtener más información sobre el uso de políticas de puntos de conexión, consulte Uso de políticas de puntos de conexión de VPC para controlar el acceso a Amazon ECR.

Implemente políticas de ciclo de vida para la ECR

La Guía de seguridad de contenedores de aplicaciones del NIST advierte sobre el riesgo de que se produzcan «imágenes obsoletas en los registros» y señala que, con el tiempo, las imágenes antiguas con paquetes de out-of-date software vulnerables deberían eliminarse para evitar su despliegue y exposición accidentales. Cada repositorio de ECR puede tener una política de ciclo de vida que establezca reglas sobre cuándo caducan las imágenes. La documentación oficial de AWS describe cómo configurar las reglas de prueba, evaluarlas y luego aplicarlas. Hay varios ejemplos de políticas de ciclo de vida en los documentos oficiales que muestran diferentes formas de filtrar las imágenes de un repositorio:

  • Filtrar por antigüedad o recuento de imágenes

  • Filtrar por imágenes etiquetadas o sin etiquetar

  • Filtrar por etiquetas de imagen, ya sea en varias reglas o en una sola regla

??? + advertencia Si la imagen de una aplicación de ejecución prolongada se purga del ECR, se pueden producir errores al extraer la imagen cuando la aplicación se vuelva a implementar o se escale horizontalmente. Cuando utilices políticas sobre el ciclo de vida de las imágenes, asegúrate de contar con CI/CD las mejores prácticas para mantener actualizadas las implementaciones y las imágenes a las que hacen referencia, y crea siempre reglas de caducidad para [imágenes] que tengan en cuenta la frecuencia con la que realizas las versiones o despliegues.

Crear un conjunto de imágenes mantenidas

En lugar de permitir que los desarrolladores creen sus propias imágenes, considere la posibilidad de crear un conjunto de imágenes verificadas para los distintos grupos de aplicaciones de su organización. De este modo, los desarrolladores pueden prescindir de aprender cómo componer Dockerfiles y concentrarse en escribir código. A medida que los cambios se fusionan en Master, una CI/CD canalización puede compilar automáticamente el activo, almacenarlo en un repositorio de artefactos y copiar el artefacto en la imagen correspondiente antes de enviarlo a un registro de Docker, como ECR. Como mínimo, deberías crear un conjunto de imágenes base a partir de las cuales los desarrolladores puedan crear sus propios Dockerfiles. Lo ideal sería evitar extraer imágenes de Dockerhub porque 1/ no siempre se sabe lo que hay en la imagen y 2/ aproximadamente una quinta parte de las 1000 imágenes principales tienen vulnerabilidades. Puedes encontrar una lista de esas imágenes y sus vulnerabilidades aquí.

Añada la directiva USER a sus Dockerfiles para ejecutarlos como un usuario no root

Como se mencionó en la sección de seguridad del pod, debes evitar ejecutar el contenedor como root. Si bien puedes configurarlo como parte del PodSpec, es una buena costumbre usar la USER directiva en tus Dockerfiles. La USER directiva establece el UID que se utilizará cuando se ejecute RUN o la CMD instrucción que aparece ENTRYPOINT después de la directiva USER.

Borra tus Dockerfiles

Puedes usar Linting para comprobar que tus Dockerfiles cumplen una serie de directrices predefinidas, por ejemplo, la inclusión de la USER directiva o el requisito de etiquetar todas las imágenes. dockerfile_lint es un proyecto de código abierto RedHat que verifica las mejores prácticas comunes e incluye un motor de reglas que puedes usar para crear tus propias reglas para lintar Dockerfiles. Se puede incorporar a una canalización de CI, ya que las compilaciones con Dockerfiles que infrinjan una regla fallarán automáticamente.

Cree imágenes desde cero

Reducir la superficie de ataque de las imágenes de sus contenedores debe ser el objetivo principal al crear imágenes. La forma ideal de hacerlo es crear un mínimo de imágenes sin archivos binarios que puedan utilizarse para aprovechar las vulnerabilidades. Afortunadamente, Docker tiene un mecanismo a partir del cual crear imágenes. scratch Con lenguajes como Go, puedes crear un binario enlazado estático y hacer referencia a él en tu Dockerfile, como en este ejemplo:

############################
# STEP 1 build executable binary
############################
FROM golang:alpine AS builder# Install git.
# Git is required for fetching the dependencies.
RUN apk update && apk add --no-cache gitWORKDIR $GOPATH/src/mypackage/myapp/COPY . . # Fetch dependencies.
# Using go get.
RUN go get -d -v# Build the binary.
RUN go build -o /go/bin/hello

############################
# STEP 2 build a small image
############################
FROM scratch# Copy our static executable.
COPY --from=builder /go/bin/hello /go/bin/hello# Run the hello binary.
ENTRYPOINT ["/go/bin/hello"]

Esto crea una imagen de contenedor que consiste en tu aplicación y nada más, lo que la hace extremadamente segura.

Utilice etiquetas inmutables con ECR

Las etiquetas inmutables obligan a actualizar la etiqueta de la imagen cada vez que se envía al repositorio de imágenes. Esto puede impedir que un atacante sobrescriba una imagen con una versión maliciosa sin cambiar las etiquetas de la imagen. Además, permite identificar una imagen de forma sencilla y exclusiva.

Firme las imágenes SBOMs, los procesos de ejecución y los informes de vulnerabilidad

Cuando se introdujo Docker por primera vez, no existía un modelo criptográfico para verificar las imágenes de los contenedores. Con la versión 2, Docker agregó resúmenes al manifiesto de imágenes. Esto permitía aplicar un hash a la configuración de una imagen y utilizar el hash para generar un identificador para la imagen. Cuando la firma de imágenes está habilitada, el motor Docker verifica la firma del manifiesto y se asegura de que el contenido proviene de una fuente confiable y de que no se ha producido ninguna alteración. Tras descargar cada capa, el motor verifica el resumen de la capa y se asegura de que el contenido coincide con el contenido especificado en el manifiesto. La firma de imágenes permite crear de forma eficaz una cadena de suministro segura mediante la verificación de las firmas digitales asociadas a la imagen.

Podemos usar AWS Signer o Sigstore Cosign para firmar imágenes de contenedores, crear atestaciones para SBOMs informes de análisis de vulnerabilidades e informes de ejecución de proyectos. Estas certificaciones garantizan la fiabilidad e integridad de la imagen, que, de hecho, ha sido creada por un canal de confianza sin interferencias ni manipulaciones y que solo contiene los componentes de software que están documentados (en la SBOM) y que el editor de la imagen ha verificado y en los que confía. Estas atestaciones se pueden adjuntar a la imagen del contenedor y enviarse al repositorio.

En la siguiente sección veremos cómo utilizar los artefactos certificados para las auditorías y la verificación del controlador de admisiones.

Verificación de la integridad de la imagen mediante el controlador de admisión de Kubernetes

Podemos verificar las firmas de las imágenes y comprobar los artefactos de forma automática antes de implementar la imagen en el clúster de Kubernetes de destino mediante un controlador de admisión dinámico y admitir los despliegues solo cuando los metadatos de seguridad de los artefactos cumplan con las políticas del controlador de admisión.

Por ejemplo, podemos redactar una política que verifique criptográficamente la firma de una imagen, una SBOM certificada, un informe de ejecución de un proceso certificado o un informe de escaneo CVE certificado. Podemos incluir condiciones en la política para comprobar los datos del informe, por ejemplo, un escaneo CVE no debería contener ningún dato crítico. CVEs Solo se permite el despliegue de imágenes que cumplan estas condiciones y el controlador de admisiones rechazará todos los demás despliegues.

Algunos ejemplos de controladores de admisión son:

Actualiza las imágenes de los paquetes de tu contenedor

Deberías incluir RUN apt-get update && apt-get upgrade en tus Dockerfiles para actualizar los paquetes de tus imágenes. Aunque la actualización requiere que se ejecute como root, esto ocurre durante la fase de creación de la imagen. No es necesario que la aplicación se ejecute como root. Puede instalar las actualizaciones y, a continuación, cambiar a otro usuario con la directiva USER. Si la imagen base se ejecuta como usuario no root, cámbiese a root y viceversa; no confíe únicamente en los responsables del mantenimiento de la imagen base para instalar las actualizaciones de seguridad más recientes.

Ejecute apt-get clean para eliminar los archivos del instalador. /var/cache/apt/archives/ También puede ejecutarlo rm -rf /var/lib/apt/lists/* después de instalar los paquetes. Esto elimina los archivos de índice o las listas de paquetes que están disponibles para su instalación. Tenga en cuenta que estos comandos pueden ser diferentes para cada administrador de paquetes. Por ejemplo:

RUN apt-get update && apt-get install -y \
    curl \
    git \
    libsqlite3-dev \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

Herramientas y recursos