Docker
Uso seguro de secretos, SSH y caches durante la construcción.
Los secretos de build son credenciales que una construcción necesita para acceder a recursos privados, pero que no deben formar parte de la imagen, sus capas, metadata, logs ni cache exportada.
secreto autorizado
→ mount temporal durante un RUN
→ acceso a recurso privado
→ mount desaparece
→ artefacto final sin credencialBuildKit ofrece secret mounts y SSH mounts para separar la credencial del resultado. Esta separación reduce exposición, pero no garantiza seguridad por sí sola: el comando que consume el secreto todavía puede copiarlo, imprimirlo o incorporarlo al artefacto.
Un patrón inseguro:
ARG NPM_TOKEN
RUN npm config set //registry.npmjs.org/:_authToken "$NPM_TOKEN" \
&& npm ciAunque ARG no quede disponible como variable normal de runtime, puede aparecer en historial, logs, metadata de build o comandos. También puede afectar caches exportadas.
Más grave:
COPY .npmrc /root/.npmrc
RUN npm ci
RUN rm /root/.npmrcBorrar el archivo en una capa posterior no lo elimina de la capa anterior. El token puede recuperarse inspeccionando blobs.
ENV es todavía menos apropiado:
ENV NPM_TOKEN=secretPersiste como metadata de la imagen y puede verse con docker image inspect.
Dockerfile:
# syntax=docker/dockerfile:1
FROM node:22-slim AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc,required=true \
npm ciBuild:
docker build \
--secret id=npmrc,src="$HOME/.npmrc" \
-t my-api:build .Durante esa instrucción, el archivo está disponible en /root/.npmrc. Después desaparece. No se incorpora automáticamente a la capa.
Según el flujo y tooling, el secret puede suministrarse desde una variable del entorno del cliente. La idea sigue siendo la misma: el valor se entrega mediante el canal de secrets del builder, no como build arg ordinario.
Hace que el build falle claramente si el secreto no fue suministrado. Sin esta opción, el comando puede fallar después con un error ambiguo de autenticación.
Este Dockerfile sigue siendo inseguro:
RUN --mount=type=secret,id=token \
cp /run/secrets/token /app/token.txtEl mount es temporal, pero el comando copió su contenido al filesystem resultante.
Otros escapes posibles:
La garantía correcta es limitada: BuildKit no persiste el mount por defecto. No puede impedir que el proceso lo filtre.
Para dependencias privadas por SSH:
# syntax=docker/dockerfile:1
FROM alpine:3.22 AS source
RUN apk add --no-cache git openssh-client
RUN --mount=type=ssh \
git clone git@github.com:organization/private-repository.git /srcBuild:
docker build --ssh default -t private-build .El builder utiliza el agente SSH disponible sin copiar la private key a la imagen.
No desactives verificación de host con soluciones como:
StrictHostKeyChecking noEso facilita ataques de intermediario. Proporciona known_hosts confiable o utiliza mecanismos soportados por el entorno.
El socket o agente se presenta temporalmente durante la instrucción. No debe quedar accesible en la imagen final.
Los cache mounts no son secretos, pero suelen aparecer junto a ellos:
RUN --mount=type=cache,target=/root/.npm,sharing=locked \
--mount=type=secret,id=npmrc,target=/root/.npmrc \
npm ciAquí existen dos fronteras distintas:
Debes comprobar que el package manager no escriba credenciales dentro del cache. Una cache exportada a un registry o backend remoto puede tener un alcance mucho mayor que el builder local.
Una cache externa debe tratarse como input de supply chain.
Riesgos:
Controles:
Cambiar el valor de un secret mount no siempre invalida automáticamente una operación cacheada. El secreto no forma parte ordinaria de la clave porque incluirlo filtraría información y reduciría utilidad.
Si una credencial nueva cambia el resultado esperado, utiliza un input no sensible para controlar invalidación:
ARG PRIVATE_REGISTRY_GENERATION=1
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc \
echo "$PRIVATE_REGISTRY_GENERATION" >/dev/null \
&& npm ciNo pongas el token como valor del argumento. Usa una versión o generación pública.
Son problemas distintos.
Necesario para producir la imagen:
Necesario cuando la aplicación se ejecuta:
Un runtime secret no debería incorporarse durante build. La misma imagen debe poder ejecutarse en distintos ambientes y recibir el secreto en runtime mediante secret manager, file mount u otro canal controlado.
Dockerfile:
# syntax=docker/dockerfile:1
FROM node:22-bookworm-slim AS dependencies
WORKDIR /app
COPY package.json package-lock.json ./
RUN --mount=type=secret,id=npmrc,target=/root/.npmrc,required=true \
--mount=type=cache,target=/root/.npm,sharing=locked \
npm ci
FROM node:22-bookworm-slim AS runtime
ENV NODE_ENV=production
WORKDIR /app
COPY --from=dependencies /app/node_modules ./node_modules
COPY . .
USER node
CMD ["node", "server.js"]Controles adicionales:
.npmrc está fuera del build context.docker image history --no-trunc my-api:build
docker image inspect my-api:buildBusca valores, comandos o variables sospechosas.
En un entorno controlado:
container_id=$(docker create my-api:build)
docker export "$container_id" -o rootfs.tar
docker rm "$container_id"
tar -tf rootfs.tar | grep -Ei 'npmrc|token|credential|secret'Esto inspecciona el filesystem combinado, pero no todas las capas históricas. Un secreto copiado y borrado puede no aparecer allí.
Utiliza herramientas de análisis de imágenes y escaneo de secretos capaces de revisar blobs individuales. Ninguna herramienta garantiza encontrar todos los formatos; combina prevención y revisión.
Ejecuta el build sin el secret:
docker build -t my-api:test .Debe fallar claramente en la instrucción que requiere acceso privado, no utilizar accidentalmente credenciales copiadas desde el host.
No basta con borrar el tag.
Procedimiento:
Un blob puede permanecer cacheado en hosts, registries secundarios o mirrors. Por eso la rotación es obligatoria.
Puede filtrarse por historial, logs o comandos. Usa secret mount.
Las capas son inmutables. El secreto puede permanecer en blobs.
Expone más claves y configuración de la necesaria. Usa agent forwarding y permisos mínimos.
Resuelve el síntoma sacrificando autenticidad del servidor.
Una etapa anterior no llega al runtime automáticamente, pero un output puede copiar el secreto y la cache/build system puede conservar contenido. Multi-stage no reemplaza secret mounts.
Package managers y scripts pueden imprimir URLs con tokens. Configura redacción y revisa logs de CI.
ARG, ENV y COPY no son canales seguros para credenciales.Optimización de imágenes, donde se evalúa tamaño, compatibilidad, superficie de ataque y operabilidad sin reducir el problema a elegir la base más pequeña.