Golden Images: Imágenes Base Certificadas

En el contexto tecnológico actual, la agilidad y la seguridad son pilares fundamentales para la competitividad. El uso de contenedores Docker ha acelerado el desarrollo de software, pero su adopción sin control puede generar riesgos de seguridad e ineficiencias operativas. La implementación de Golden Images es una estrategia corporativa diseñada para estandarizar la base de todos los contenedores desplegados en HERA, garantizando que cada aplicación se ejecute sobre una imagen certificada, segura y optimizada.

¿Qué es una Golden Image?

Una Golden Image es una imagen Docker base construida, endurecida y certificada por el equipo de Plataforma de HERA. Contiene el sistema operativo mínimo, las dependencias del runtime y las configuraciones de seguridad necesarias, sin código de aplicación. Los equipos de desarrollo la utilizan como base (FROM) en sus Dockerfiles.

---

¿Por Qué Usar Golden Images?

Mitigación de Riesgos y Cumplimiento

Al utilizar imágenes públicas no curadas, la organización se expone a vulnerabilidades de día cero, malware oculto o configuraciones inseguras. Las Golden Images son auditadas por el equipo de seguridad antes de su distribución, garantizando el cumplimiento de las políticas de seguridad de HERA.

Reducción de Costos Operativos

Se elimina la duplicidad de esfuerzos. Los equipos de desarrollo ya no invierten tiempo configurando y parcheando ambientes base; en su lugar, se enfocan al 100% en la creación de valor y desarrollo de nuevas funcionalidades. Esto se alinea con el Modelo de Responsabilidad Compartida: la base segura la provee Plataforma, el código de negocio lo construye Desarrollo.

Reducción del Error Humano

Según el índice IBM Cyber Security Intelligence, el 95% de las brechas son causadas por errores humanos como malas configuraciones, sistemas sin parches o controles de acceso deficientes. Tener una plantilla predefinida y probada reduce el riesgo de que el error humano genere un contenedor vulnerable.

Gestión Centralizada de Vulnerabilidades

Si se detecta una vulnerabilidad a nivel de sistema, el equipo de Plataforma actualiza únicamente la Golden Image. Inmediatamente, todos los despliegues posteriores heredarán el parche de seguridad de forma automatizada a través del pipeline CI/CD de HERA (ver GitLab Workflow).

Continuidad del Negocio

Al estandarizar los ambientes, se elimina el clásico problema de “funciona en mi máquina, pero no en producción”. La consistencia entre los ambientes de DEV, QA y PRD reduce drásticamente las interrupciones del servicio.

Configuration Drift

La deriva de configuración ocurre cuando sistemas que deberían ser idénticos comienzan a diferir con el tiempo debido a cambios manuales, actualizaciones no controladas o configuraciones inconsistentes. El uso de Golden Images como línea base asegura que todos los ambientes se construyan de forma consistente, evitando modificaciones no controladas y facilitando la detección de desviaciones.

---

Ciclo de Vida de las Golden Images

El modelo operativo de Golden Images en HERA se basa en cuatro pilares:

Ciclo de Vida — Golden Images Docker

1

Crear y Endurecer

Equipo de Plataforma

• Seleccionar imagen base mínima
• Aplicar hardening de seguridad
• Configurar usuario no-root
• Eliminar paquetes innecesarios

2

Escanear y Certificar

Seguridad + Plataforma

• Escaneo con Docker Scout
• Validación con Hadolint
• Certificación de seguridad
• Aprobación para publicación

3

Publicar en Registry

Equipo de Plataforma

• Push a Artifact Registry privado
• Versionamiento semántico
• Documentación de cambios
• Notificación a equipos

4

Consumir en Proyectos

Equipos de Desarrollo

• FROM en Dockerfile del proyecto
• Pipeline valida origen de imagen
• Herencia de seguridad base
• Foco en código de negocio

Ciclo mensual de actualización o cuando surjan parches críticos de seguridad

Mensaje clave Golden Images centralizadas. Los equipos tienen 60 días para adoptar cada nueva versión.

---

Catálogo de Golden Images

El equipo de Plataforma mantiene y publica las siguientes imágenes base certificadas, alineadas con el GitLab Workflow de HERA:

Golden Image	Base	Runtime	Uso recomendado	Pipeline HERA
hera/node-golden:20-alpine	Alpine 3.19	Node.js 20 LTS	Frontends, BFFs, APIs Node	GitLab Workflow
hera/python-golden:3.12-slim	Debian Slim	Python 3.12	APIs Python, workers, ML	GitLab Workflow
hera/java-golden:21-jre-alpine	Alpine 3.19	Eclipse Temurin 21	APIs Java, Spring Boot	GitLab Workflow
hera/php-golden:8.3-fpm-alpine	Alpine 3.19	PHP 8.3 FPM	APIs PHP, Laravel	GitLab Workflow
hera/dotnet-golden:8.0-alpine	Alpine 3.19	.NET 8.0 ASP.NET	APIs .NET, Blazor	GitLab Workflow
hera/nginx-golden:1.25-alpine	Alpine 3.19	Nginx 1.25	Reverse proxy, serving estático	—

Características comunes de todas las Golden Images

Cada imagen del catálogo incluye las siguientes configuraciones de seguridad preconfiguradas:

Característica	Detalle
Sistema operativo mínimo	Basadas en Alpine o Debian Slim — superficie de ataque reducida
Usuario no-root	Preconfigurado appuser:appgroup (UID 1001)
Paquetes innecesarios eliminados	Sin compiladores, shells interactivos ni herramientas de debug
Actualizaciones de seguridad	Parches del SO aplicados al momento de la construcción
Healthcheck incluido	Configuración base de healthcheck para Kubernetes
Labels estándar	com.grupoherdez.image.version, com.grupoherdez.image.maintainer, com.grupoherdez.security.scan-date
Configuración TZ	Zona horaria configurada a America/Mexico_City

---

Cómo Usar una Golden Image

Dockerfile de proyecto (ejemplo Node.js)

Los equipos de desarrollo referencian la Golden Image como base en sus Dockerfiles multi-stage:

# =============================================
# Stage 1: Builder (solo para compilación)
# =============================================
FROM hera/node-golden:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

# =============================================
# Stage 2: Runtime (Golden Image como base final)
# =============================================
FROM hera/node-golden:20-alpine
WORKDIR /app

# Copiar solo artefactos necesarios del builder
COPY --from=builder --chown=appuser:appgroup /app/dist ./dist
COPY --from=builder --chown=appuser:appgroup /app/node_modules ./node_modules
COPY --chown=appuser:appgroup package.json .

# Usar el usuario no-root preconfigurado
USER appuser
EXPOSE 3000
CMD ["node", "dist/index.js"]

Obligatoriedad

El pipeline CI/CD de HERA (ver GitLab Workflow) valida automáticamente que la imagen base utilizada en el FROM del Dockerfile provenga del registro privado de Golden Images (hera/*-golden). Si un desarrollador intenta compilar una aplicación utilizando una imagen base que no sea la Golden Image oficial, el proceso de despliegue será bloqueado automáticamente.

Validación en el pipeline

El Golden Pipeline incluye un job validate-base-image en la etapa security que bloquea el pipeline si el Dockerfile del repo no usa una Golden Image certificada como base.

Contrato del job validate-base-image

Atributo	Valor
Stage	security
Regla de validación	El último FROM del Dockerfile debe matchear el prefijo hera/*-golden
Mensaje en fallo	Reporta la imagen detectada + lista las permitidas + enlace a esta página
allow_failure	false — bloqueante
Consecuencia de fallo	Pipeline se detiene; el deploy queda imposible hasta que el FROM apunte a una Golden Image

Implementación canónica en el Golden Pipeline

La definición exacta del job (script de validación, regex exacto, manejo de multi-stage Dockerfile, excepciones documentadas) vive en grupo-herdez/platform/pipelines/gitlab-ci/ bajo el stage security. El portal documenta el contrato observable; el código canónico vive en el template para evitar drift.

---

Almacenamiento Seguro: Registry Privado

Las Golden Images se alojan en Google Artifact Registry dentro del proyecto HERA, bloqueando el acceso no autorizado y evitando la descarga accidental de imágenes públicas externas:

Aspecto	Configuración
Registry	us-central1-docker.pkg.dev/hera-platform/golden-images
Acceso de escritura	Solo equipo de Plataforma (Service Account dedicado)
Acceso de lectura	Todos los pipelines HERA vía Workload Identity
Retención	Últimas 5 versiones de cada imagen; anteriores marcadas como deprecated
Escaneo automático	Vulnerability scanning habilitado en Artifact Registry

Integración con Workload Identity

Los pipelines de HERA acceden al registry de Golden Images mediante Workload Identity, sin necesidad de credenciales estáticas. La autenticación es automática y auditada.

---

Versionamiento Semántico

Las Golden Images siguen un esquema de versionamiento claro que permite a los equipos controlar cuándo adoptar actualizaciones:

Versionamiento Semantico — Golden Images

Anatomia de una version

hera/node-golden:20-alpine-1.3.2

Variante

Version del runtime + SO

Major

Cambio de runtime o SO base

Minor

Actualizaciones de paquetes

Patch

Parches de seguridad del SO

Ciclo de obsolescencia

Publicacion

Dia 0 Nueva version disponible en Artifact Registry

Adopcion

0 - 60 dias Equipos actualizan su FROM en Dockerfile

Deprecacion

Dia 30 Version anterior marcada como deprecated

Bloqueo

Dia 90 Pipeline bloquea despliegues con version deprecated

Patch Inmediato (CVE critico)

Minor Mensual (1er lunes)

Major Semestral o por EOL del runtime

Mensaje clave Los equipos tienen maximo 60 dias para adoptar la nueva version. Pasado ese plazo, el pipeline bloquea despliegues con versiones deprecated. Esto garantiza que ningun contenedor en produccion use una base con vulnerabilidades conocidas.

Política de obsolescencia

Acción	Plazo	Responsable
Nueva versión patch (seguridad)	Inmediato cuando hay CVE crítico	Plataforma
Nueva versión minor	Mensual (primer lunes del mes)	Plataforma
Nueva versión major	Semestral o por EOL del runtime	Plataforma
Deprecación de versión anterior	30 días después de publicar nueva versión	Plataforma
Bloqueo de versión deprecated	60 días después de deprecación	Pipeline HERA
Adopción de nueva versión	Máximo 60 días desde publicación	Desarrollo

Ventana de Actualización

Los equipos de desarrollo tienen un máximo de 60 días para actualizar su FROM a la versión más reciente de la Golden Image después de su publicación. Pasado este plazo, el pipeline bloqueará despliegues con versiones deprecated. Esto asegura que ningún contenedor en producción utilice una base con vulnerabilidades conocidas.

---

Responsabilidades en el Modelo Golden Images

Este modelo refuerza el Modelo de Responsabilidad Compartida con una separación clara:

Responsabilidad	Dueño	Detalle
Crear y endurecer Golden Images	Plataforma	Seleccionar SO base, hardening, configuración de seguridad
Escanear y certificar imágenes	Seguridad + Plataforma	Docker Scout, Hadolint, aprobación formal
Publicar en Artifact Registry	Plataforma	Versionamiento semántico, changelog, notificación
Mantener y parchar mensualmente	Plataforma	Actualización de SO y dependencias base
Usar Golden Image como FROM	Desarrollo	Referenciar imagen certificada en Dockerfile
Mantener código de aplicación	Desarrollo	Dependencias de app, tests, lógica de negocio
Actualizar a nueva versión en 60 días	Desarrollo	Adoptar versión más reciente de Golden Image
Remediar vulnerabilidades de app	Desarrollo	Según SLAs de remediación

Beneficio para Desarrollo

Con Golden Images, los equipos de desarrollo heredan automáticamente la seguridad base sin esfuerzo adicional. Su responsabilidad se concentra en el código de aplicación y sus dependencias, no en la gestión del sistema operativo del contenedor.

---

Proceso de Solicitud de Nueva Golden Image

Si un equipo necesita una Golden Image para un runtime que no está en el catálogo:

1. Solicitar vía Issue en GitLab al grupo hera/platform/ci-cd con el runtime requerido.
2. Evaluar: Plataforma evalúa viabilidad, demanda y soporte del runtime.
3. Construir: Plataforma crea la imagen siguiendo los estándares de hardening.
4. Certificar: Seguridad valida con Docker Scout y Hadolint.
5. Publicar: Se agrega al catálogo y se actualiza esta documentación.
6. Comunicar: Notificación a todos los equipos vía canales de Soporte HERA.

---

Beneficios Técnicos y Operativos

Dimensión	Beneficio
Time-to-Market	Ciclos CI/CD más rápidos con base pre-aprobada
Optimización de recursos	Docker reutiliza capas base compartidas, reduciendo almacenamiento y ancho de banda
Seguridad centralizada	Un parche en la Golden Image protege todos los proyectos automáticamente
Consistencia	Misma base en DEV, QA y PRD — sin drift de configuración
Compliance	Base certificada que satisface políticas de gobierno cloud
Auditoría	Trazabilidad completa: quién construyó, cuándo, qué parches incluye
Reducción de errores	Configuración de seguridad predefinida, no delegada al desarrollador
FinOps	Imágenes más pequeñas = menos almacenamiento = menor costo cloud