Packer 1.16 añade procedencia SLSA nativa para imágenes de máquinas

HashiCorp ha lanzado Packer v1.16.0, con soporte nativo para generar, firmar y verificar atestaciones de procedencia SLSA sobre cada imagen que construye. Se acabó confiar en registros de construcción dispersos: ahora el propio packer deja un rastro verificable del commit, pipeline e identidad que generó cada artefacto, sin herramientas externas de cadena de suministro.

El problema que resuelve es el de la propagación silenciosa: si una imagen se manipula o no se puede verificar, el problema se extiende a todas las instancias creadas a partir de ella. Hasta ahora, localizar el origen requería bucear en logs de build antiguos. La nueva versión añade un post-processor de provenance que genera declaraciones in-toto con predicado SLSA Provenance v1, formato neutral que se integra con las herramientas de seguridad existentes. Los atestados registran el commit de Git, el repositorio, la rama, el pipeline de CI que disparó la construcción y las marcas de tiempo. Para artefactos locales se enlazan al hash SHA-256; los artefactos de nube sin archivo local se asocian a un registro canónico con los IDs de builder y de artefacto.

Packer ofrece cuatro modos de firma: salida JSON sin firmar para uso interno, claves PEM locales para entornos aislados, KMS de nube o Vault para gestión centralizada, y Sigstore Fulcio para firma sin clave en pipelines de CI, pudiendo subir el registro a Rekor para transparencia. Con estos modos, la herramienta escala en los niveles de SLSA: el nivel L1 se consigue solo con el post-processor (firma opcional); el L2 añadiendo la ejecución en una plataforma de CI con firma sin clave, donde la identidad OIDC del trabajo actúa como firmante; y un patrón compatible con L3 separa la generación de provenance del trabajo de construcción, mediante un trabajo de firma independiente basado en slsa-framework/slsa-github-generator. HashiCorp señala que el patrón por sí solo no garantiza L3 completo, ya que depende del endurecimiento de la plataforma y el aislamiento de la construcción.

HashiCorp posiciona esta función para el control de despliegues y para correlacionar CVEs con commits e instancias, y como evidencia de apoyo (no prueba) en auditorías SOC 2 o FedRAMP. La versión incluye también mejoras menores en HCL2: el argumento continue_on_error para provisionadores no fatales, el soporte de optional() en valores por defecto de atributos de variables de tipo objeto, y nuevas funciones de plantilla rfc3339_parse() y unix_timestamp_parse(). Todo es opt-in: las plantillas existentes siguen funcionando sin cambios; basta añadir el post-processor al bloque de construcción. Para los patrones L2 o L3 hay workflows de referencia en el directorio examples/ci del repositorio.

Packer se apoya en métodos ya probados en el mundo de los contenedores (in-toto, SLSA, Sigstore, Rekor), y los lleva a imágenes de máquina como AMIs, QCOW2 o VHD. Frente a las soluciones de AWS, como los watermarks de AMI o la atestación NitroTPM, Packer cubre un hueco distinto: los watermarks rastrean identidad y lineage, pero no garantizan procedencia criptográfica; NitroTPM certifica que una instancia en ejecución coincide con una medición de referencia al arrancar, pero no cómo o dónde se construyó originalmente la imagen. Para gobernanza completa de imágenes, ambas herramientas son complementarias, no sustitutas.

Con esto, Packer ofrece a los equipos de infraestructura una trazabilidad que antes solo estaba disponible en el mundo de los contenedores, y de forma nativa, sin encadenar utilidades.