Compartir comentarios
Las respuestas se generan en base a la documentación.

Usar una Docker Hardened Image

Tabla de contenidos

Puedes usar una Docker Hardened Image (DHI) al igual que cualquier otra imagen en Docker Hub. Las DHI siguen los mismos patrones de uso familiares. Descárgalas con docker pull, haz referencia a ellas en tu Dockerfile y ejecuta contenedores con docker run.

La diferencia clave es que las DHI se centran en la seguridad y son intencionadamente mínimas para reducir la superficie de ataque. Esto significa que algunas variantes no incluyen una shell ni un gestor de paquetes, y pueden ejecutarse como usuario no root por defecto.

Important

Debes autenticarte en el registro de Docker Hardened Images (dhi.io) para descargar imágenes de DHI Community. Puedes autenticarte usando cualquiera de las siguientes opciones:

Ejecuta docker login dhi.io para autenticarte.

Consideraciones al adoptar DHI

Las Docker Hardened Images son intencionadamente mínimas para mejorar la seguridad. Si estás actualizando Dockerfiles o frameworks existentes para usar DHI, ten en cuenta que las imágenes de tiempo de ejecución no incluyen shells ni gestores de paquetes, se ejecutan como usuarios no root por defecto y pueden tener configuraciones diferentes a las de las imágenes con las que estás familiarizado.

Para obtener una lista de verificación completa de las consideraciones de migración y orientación detallada, consulta Migrar a Docker Hardened Images.

Descargar, ejecutar y hacer referencia a DHI

Las Docker Hardened Images utilizan diferentes referencias de imagen según tu suscripción:

SuscripciónReferencia de imagenAutenticación
Communitydhi.io/<image>:<tag>docker login dhi.io
Select y Enterprise<your-org>/<image>:<tag>docker login

Los usuarios de Select y Enterprise deben replicar los repositorios en su organización de Docker Hub para acceder a las variantes de cumplimiento y a las funciones de personalización.

Después de autenticarte, usa la referencia de la imagen en los comandos estándar de Docker y en los Dockerfiles. Por ejemplo:

$ docker pull dhi.io/python:3.13
$ docker run --rm dhi.io/python:3.13 python -c "print('Hola desde DHI')"

FROM dhi.io/python:3.13
COPY . /app
CMD ["python", "/app/main.py"]

Para compilaciones multi-stage:

Para aprender a buscar variantes disponibles, consulta Buscar y evaluar imágenes.

Usar una DHI en pipelines de CI/CD

Las Docker Hardened Images funcionan igual que cualquier otra imagen en tus pipelines de CI/CD. Puedes hacer referencia a ellas en Dockerfiles, descargarlas como parte de un paso de pipeline o ejecutar contenedores basados en ellas durante las compilaciones y pruebas.

A diferencia de las imágenes de contenedor típicas, las DHI también incluyen atestaciones firmadas, como SBOM y metadatos de procedencia. Puedes incorporarlas en tu pipeline para respaldar la seguridad de la cadena de suministro, las comprobaciones de políticas o los requisitos de auditoría si tus herramientas lo admiten.

Para fortalecer tu cadena de suministro de software, considera añadir tus propias atestaciones al compilar imágenes a partir de DHI. Esto te deja documentar cómo se compiló la imagen, verificar su integridad y habilitar la validación y el cumplimiento de políticas en fases posteriores utilizando herramientas como Docker Scout.

Para aprender a adjuntar atestaciones durante el proceso de compilación, consulta Atestaciones de Docker Build.

Descubrir atestaciones con ORAS

Puedes usar ORAS para descubrir e inspeccionar las atestaciones adjuntas a las Docker Hardened Images. Esto es especialmente útil en pipelines de CI/CD para la validación de la seguridad de la cadena de suministro y las comprobaciones de cumplimiento.

Para flujos de trabajo automatizados, autentícate utilizando un token de acceso de organización (OAT). Los OAT pertenecen a la organización en lugar de a un usuario individual, lo que los hace más adecuados para los pipelines de CI/CD.

Para descubrir atestaciones con ORAS:

  1. Genera un token de acceso de organización con el alcance Read public repositories.

    El siguiente ejemplo muestra cómo descubrir atestaciones en imágenes DHI community directamente desde dhi.io. Si estás descubriendo atestaciones en imágenes replicadas en tu organización, genera un OAT con alcance para leer desde tu repositorio replicado en lugar de Read public repositories.

  2. Inicia sesión en dhi.io usando el nombre de tu organización como usuario y el OAT como contraseña.

    Warning

    Los siguientes ejemplos exportan las credenciales directamente en la línea de comandos con fines de demostración. Esto expone tokens sensibles en el historial de la shell y en la lista de procesos. En entornos de producción, utiliza métodos seguros como leer desde archivos con permisos restringidos, archivos de entorno cargados en tiempo de ejecución o herramientas de gestión de secretos.

    $ oras login dhi.io -u <YOUR_ORGANIZATION_NAME>

    O de forma no interactiva en un pipeline de CI/CD, establece el nombre de tu organización y el token:

    $ export DOCKER_ORG="YOUR_ORGANIZATION_NAME"
$ export OAT="YOUR_ORGANIZATION_ACCESS_TOKEN"
$ echo $OAT | oras login dhi.io -u "$DOCKER_ORG" --password-stdin

  3. Descubre las atestaciones en una imagen DHI:

    $ oras discover dhi.io/node:24-dev --platform linux/amd64
    Note

    La opción --platform es obligatoria. Sin ella, oras discover resuelve el índice de la imagen multiarquitectura, que devuelve solo una firma a nivel de índice en lugar del conjunto completo de atestaciones por plataforma.

    Una respuesta exitosa muestra la lista de las atestaciones adjuntas a la imagen, incluyendo SBOM, procedencia, informes de vulnerabilidades y metadatos de historial de cambios (changelog).

Usar una imagen static para ejecutables compilados

Las Docker Hardened Images incluyen un repositorio de imágenes static diseñado específicamente para ejecutar ejecutables compilados en un entorno de ejecución extremadamente mínimo y seguro. A diferencia de una imagen FROM scratch no securizada, la imagen static de DHI incluye atestaciones y paquetes esenciales como ca-certificates.

Usa una imagen -dev u otra imagen de compilación (builder) para compilar tu binario y luego copia el resultado en una imagen static:

FROM dhi.io/golang:1.22-dev AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o myapp

FROM dhi.io/static:20230311
COPY --from=build /app/myapp /myapp
ENTRYPOINT ["/myapp"]

Para ver más patrones de compilación multi-stage, consulta el ejemplo de migración de Go.

Usar variantes dev para aplicaciones basadas en frameworks

Si estás desarrollando aplicaciones con frameworks que requieren gestores de paquetes o herramientas de compilación (como Python, Node.js o Go), usa una variante -dev durante la etapa de desarrollo o compilación. Estas variantes incluyen utilidades esenciales como shells, compiladores y gestores de paquetes para dar soporte a la iteración local y a los flujos de trabajo de CI.

Usa imágenes -dev en tu ciclo de desarrollo interno o en etapas de CI aisladas para maximizar la productividad. Una vez que estés listo para generar artefactos para producción, cambia a una variante de tiempo de ejecución más pequeña para reducir la superficie de ataque y el tamaño de la imagen.

Para ver ejemplos detallados de Dockerfiles multi-stage que utilizan variantes dev, consulta los ejemplos de migración:

Usar variantes de cumplimiento y ELS

Suscripción: Docker Hardened Images Select o Enterprise

Con una suscripción a DHI Select o DHI Enterprise, puedes acceder a variantes de imágenes adicionales:

  • Variantes de cumplimiento: Imágenes habilitadas para FIPS y listas para STIG para requisitos normativos.
  • Variantes ELS (Soporte de Ciclo de Vida Extendido) (requiere complemento): Parches de seguridad para versiones de imágenes al final de su vida útil (EOL).

Para acceder a estas variantes, replica el repositorio en tu organización de Docker Hub. Para ELS, habilita la opción Mirror end-of-life images al configurar la réplica. Una vez replicado, usa las etiquetas de cumplimiento o EOL como cualquier otra etiqueta de imagen.

Usar con Kubernetes

Al desplegar Docker Hardened Images en Kubernetes, el proceso es similar al uso de cualquier otra imagen de contenedor con una diferencia clave: debes configurar secretos de descarga de imágenes para autenticarte en el registro de DHI. Esto se aplica tanto si realizas la descarga directamente desde dhi.io, desde una réplica en Docker Hub o desde tu propio registro de terceros.

Crear un secreto de descarga de imagen

Puedes crear un secreto de descarga de imagen utilizando un token de acceso o las credenciales de Docker Desktop.

Para el valor de --docker-server:

  • Usa dhi.io para imágenes comunitarias descargadas directamente de Docker Hardened Images.
  • Usa docker.io para repositorios replicados en Docker Hub.
  • Usa el nombre de host de tu registro para registros de terceros.

Uso de un token de acceso

Crea un secreto utilizando un token de acceso personal (PAT) o un token de acceso de organización (OAT). Asegúrate de que el token tenga al menos acceso de solo lectura a los repositorios.

$ kubectl create -n <kubernetes namespace> secret docker-registry <secret name> --docker-server=<registry server> \
        --docker-username=<registry user> --docker-password=<access token> \
        --docker-email=<registry email>

Uso de las credenciales de Docker Desktop

Si ya te has autenticado con Docker Desktop, puedes crear un secreto utilizando tus credenciales almacenadas. Este método funciona para los registros en los que te has autenticado a través de Docker Desktop (usando docker login <registry>).

$ NS=<namespace>
$ kubectl create -n ${NS} secret docker-registry dhi-pull-secret \
    --docker-server=<registry server> \
    --docker-username=<registry user> \
    --docker-password="$(echo https://<registry server> | docker-credential-desktop get | jq -r .Secret)" \
    --docker-email=<registry email>

Este método extrae las credenciales del almacenamiento de credenciales de Docker Desktop, evitando la necesidad de crear un token de acceso independiente para el desarrollo local.

Probar el secreto de descarga de imagen

Después de crear el secreto, verifica que funcione desplegando un pod de prueba que haga referencia al secreto en su configuración imagePullSecrets.

Crea un pod de prueba:

kubectl apply --wait -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: dhi-test
  namespace: <kubernetes namespace>
spec:
  containers:
  - name: test
    image: bash:5
    command: [ "sh", "-c", "echo 'Hello from DHI in Kubernetes!'" ]
  imagePullSecrets:
  - name: <secret name>
EOF

Comprueba el estado del pod para asegurarte de que se completó correctamente:

$ kubectl get -n <kubernetes namespace> pods/dhi-test

Una prueba exitosa muestra el estado Completed:

NAME       READY   STATUS      RESTARTS     AGE
dhi-test   0/1     Completed   ...          ...

Si en su lugar ves el estado ErrImagePull, hay un problema con la configuración de tu secreto:

NAME       READY   STATUS         RESTARTS   AGE
dhi-test   0/1     ErrImagePull   0          ...

Verifica que la salida del pod coincida con el mensaje esperado:

$ kubectl logs -n <kubernetes namespace> pods/dhi-test
Hello from DHI in Kubernetes!

Limpia el pod de prueba:

$ kubectl delete -n <kubernetes namespace> pods/dhi-test