OCI mínimas y seguras para ISVs: rocks de Canonical

septiembre 19, 2026 Alfonso Moreno | Sysadmin Senior 36 Visitas 8 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

El problema real: imágenes grandes, mucho ruido, visibilidad rota

Si te dedicas a entregar software contenedorizado a clientes enterprise, probablemente ya topaste con este dilema: cada imagen base gorda suma paquetes que no usas, y cada paquete extra arrastra CVEs. Los scanners de tu cliente (Trivy, Grype, Snyk, OSV-Scanner) empiezan a gritar sobre paquetes que ni siquiera están en tu binario final. Lo opuesto también duele: si vas a una imagen “distroless” minimalista, los scanners pierden metadata de paquetes y reportan false negatives críticos.

El artículo de Canonical del 11 de septiembre de 2026 (“Cut bloat, not features”) apunta exactamente a esa tensión y propone un webinar técnico para el 23 de septiembre donde muestran cómo resolverlo con rocks (imágenes OCI basadas en Ubuntu) construidos con Chisel y Rockcraft. Acá te desgloso qué cambia, qué herramientas ya puedes usar hoy y dónde están las trampas reales que el anuncio no discute.

Por qué el enfoque “top-down” de las distroless falla

La mayoría de las imágenes distroless se construyen inflando una base completa (Ubuntu, Debian, Alpine) y después borrando a mano lo que sobra. Esto parece lógico, pero rompe la trazabilidad:

El binario queda, pero el archivo var/lib/dpkg/status queda mutilado o vacío.
Trivy y Grype leen ese archivo para mapear binarios → paquetes → CVEs.
Sin metadata, el scanner o marca todo como “unrecognized” o reporta que el SO base no tiene parches aplicados.

Resultado: tu cliente enterprise ve 200 alertas en una imagen minimalista de 12 MB, o cero alertas en una imagen que en realidad tiene glibc desactualizado. Ambos escenarios son inviables en producción.

El webinar de Canonical propone exactamente lo opuesto: partir de un set mínimo de slices de paquetes, declarativamente, y conservar la metadata que los scanners necesitan.

Qué son rocks, Chisel y Rockcraft en concreto

Tres componentes, con roles separados:

Chisel: package slicer escrito en Go. “Corta” paquetes Ubuntu a nivel de archivos (slices), no a nivel de paquete entero. Por ejemplo, en lugar de instalar openssl entero, instalas solo openssl_config + ca-certificates_data si eso es lo único que tu app necesita. Vive en github.com/canonical/chisel y se distribuye como binario estático (1.2.0 al cierre de este post).
Rockcraft: CLI que toma un rockcraft.yaml declarativo (mismo modelo de Charmcraft/Snapcraft) y orquesta Chisel + skopeo para producir una imagen OCI empaquetada. Repositorio en github.com/canonical/rockcraft, última release 1.20.0 documentada en documentation.ubuntu.com/rockcraft.
Rocks: la imagen final. Cumple OCI spec, se puede pushear a cualquier registry (Docker Hub, GHCR, ECR, Harbor), arranca con UID no-root por default, hereda el LTS de Ubuntu (5 años standard, hasta 15 años con Ubuntu Pro).

La diferencia clave con Alpine o distroless genéricos: las rocks mantienen el árbol de metadata de paquetes completo. Esto significa que Snyk, OSV-Scanner y Trivy pueden mapear cada binario a su CVE real sin reconstruir contexto.

Cómo se ve un rockcraft.yaml real

El formato declarativo es el primer shock si vienes de Dockerfiles imperativos. Acá un ejemplo mínimo para una app Python:

name: mi-api-flask
summary: API REST minimalista para isv-demo
description: |
  Rock minimalista basado en Ubuntu 24.04 con Python 3.12 y solo
  las librerías ssl/cert que la app necesita para hablar HTTPS.
version: '0.1.0'
base: [email protected]
platforms:
  amd64:
    build-on: [amd64]
    build-for: [amd64]
parts:
  runtime-deps:
    plugin: nil
    stage-packages:
      - python3.12_libs
      - libssl3_libs
      - ca-certificates_data
services:
  api:
    override: replace
    command: /usr/bin/python3 -m mi_app
    user: _nobody
    group: _nobody

Lo importante: stage-packages lista slices de paquetes (nota el sufijo _libs), no paquetes enteros. Rockcraft se encarga de invocar Chisel para cortar exactamente esos archivos. Sin apt install, sin rm -rf /var/lib/apt/lists/* en un RUN final.

Construir y pushear el rock en 4 comandos

Instalación de Rockcraft (Ubuntu 22.04+):

sudo snap install rockcraft --classic
rockcraft version
# rockcraft 1.20.0

Build local y empaquetado OCI:

cd mi-proyecto
rockcraft pack
# Empaqueta como .rock (OCI tarball)
ls *.rock
# mi-api-flask_0.1.0_amd64.rock

Importar el rock a Docker (o skopeo copy a cualquier registry):

sudo snap install docker
docker load --input mi-api-flask_0.1.0_amd64.rock
docker images | grep mi-api-flask
# mi-api-flask   0.1.0   <none>   <none>   18MB

El tamaño importa: una app Python estándar con Flask + requests + urllib3 normalmente pesa 180-220 MB en python:3.12-slim. Un rock equivalente, con solo los slices que tu código importa, cae típicamente a 15-25 MB. En entornos donde cada pull/pull-scale se repite miles de veces al día, ese delta se nota en ancho de banda y en tiempo de cold-start de pods Kubernetes.

Verificar que el scanner ve la metadata correcta

El punto crítico es que después de buildear, los scanners populares puedan mapear binarios a CVEs. Acá la prueba con Trivy, que es el más estricto con metadata de Debian/Ubuntu:

trivy image --severity HIGH,CRITICAL mi-api-flask:0.1.0
# Esperado: lista de CVEs reales mapeadas a paquetes Ubuntu
# NO "unrecognized" ni "OS package not found"

Si Trivy reporta “unrecognized” en paquetes que sí instalaste vía slice, hay tres causas probables:

El slice que elegiste no es el correcto (ej: libssl3_data en lugar de libssl3_libs). El sufijo importa: _libs, _bins, _data, _config cada uno trae archivos distintos.
El base es Ubuntu pero el scanner espera Debian. Forza --format table --output table y revisa la columna OS Family.
Falta el archivo /var/lib/dpkg/status dentro del rootfs. Rockcraft lo incluye automáticamente, pero si reescribes la imagen con un FROM scratch adicional lo pierdes.

Lo que el webinar NO te dice: las trampas reales

El pitch oficial suena limpio, pero hay fricciones que vas a descubrir en producción:

Debuggear dentro del rock es más difícil. Sin shell, sin apt, sin ps, sin netstat, necesitas otra imagen paralela con esas herramientas para hacer troubleshooting en vivo. Para Kubernetes, sidecar containers con netshoot o kubectl debug son obligatorios.
El ecosistema de slices todavía está verde. No todos los paquetes Ubuntu tienen slices bien definidos al día de hoy. Vas a toparte con paquetes donde chisel cut devuelve slices vacíos o donde la dependencia implícita entre slices no está documentada. La lista de slices disponibles está en https://github.com/canonical/chisel-releases por release de Ubuntu.
LTS de 15 años aplica solo con Ubuntu Pro. La imagen rock base trae los 5 años standard de LTS. Si tu cliente enterprise necesita 10 o 15 años de soporte para un sistema regulado, tienes que sumar la suscripción Pro. El post no aclara pricing; el webinar del 23-sept probablemente sí.
El “non-root default” no es inviolable. Si en tu rockcraft.yaml sobreescribes el user: del service o lo cambias en runtime con docker run -u 0, el principio de least privilege se va al piso. Es la misma discusión que con distroless genéricos: la seguridad por default solo funciona si la respetas.

Cuándo SÍ conviene y cuándo todavía NO

Conviene rocks si: vendes software a clientes enterprise que pasan scanners de CVE automáticamente en CI/CD, tienes apps Python/Go/Node con dependencias claras, quieres bajar 70-90% el tamaño de tus imágenes y aceptar el costo de debugging-sidecar, o tu SLA regulatorio exige base Ubuntu con LTS largo.

Todavía NO conviene si: tu equipo DevOps no tiene experiencia con el ecosistema Snap/Charmcraft (el modelo declarativo de Rockcraft tiene curva de aprendizaje), necesitas imágenes para arquitecturas no-amd64 con paquetes propietarios raros (algunos slices aún no se generan para arm64 o riscv64 en todos los releases), o estás en una etapa donde Dockerfile + docker buildx multi-stage ya te funciona sin quejas. Migrar por migrar suma complejidad sin retorno.

Si tu caso cae en el primer grupo, anótate para el webinar del 23 de septiembre: el link de registración está en el artículo de Canonical. Si no puedes esperar, la doc de Rockcraft 1.19+ tiene tutoriales paso a paso para armar tu primer rock end-to-end.

Preguntas frecuentes

¿Por qué OCI mínimas y seguras para ISVs: rocks de Canonical es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con OCI mínimas y seguras para?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con OCI mínimas y seguras para?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar OCI mínimas y seguras para y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a OCI mínimas y seguras para?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.