Harbor 2.15 en pymes: imágenes, firmas y borrado
Harbor ordena imágenes OCI con proyectos, permisos, cuentas robot, retención y backup. Guía técnica para decidir instalación y primera prueba.
Un registro privado de imágenes puede costar menos que una mañana perdida descargando capas desde repositorios externos. Harbor 2.15.2, publicado el 2 de julio de 2026, agrega gobierno sobre imágenes OCI: proyectos, permisos, cuentas robot, retención, firmas y backup. Esta guía muestra cuándo instalarlo, qué dato guarda cada componente, quién puede borrar una imagen y cómo probar que una restauración sirve.
Dónde aparece la imagen que nadie puede borrar
El problema operativo aparece cuando cada servidor descarga imágenes desde lugares distintos y nadie sabe qué versión está en producción. En una pyme con dos aplicaciones internas, el objeto visible es una etiqueta de versión escrita en una pizarra junto al rack: ayuda durante el despliegue, pero no dice quién subió la imagen ni qué vulnerabilidad quedó pendiente. Harbor pone ese control en un registro propio. La imagen vieja pesa. La cifra que corrige la decisión viene del repositorio oficial: goharbor/harbor registró 28.840 estrellas al chequeo de esta corrida. Esa tracción pública no reemplaza una prueba local, pero muestra actividad de mantenimiento. La documentación pública de Harbor 2.14 sigue siendo la referencia operativa para instalación y administración, mientras el release 2.15.2 marca la línea de producto más reciente. El dato global vuelve a la base. La Stack Overflow Survey 2025 ubicó a PostgreSQL con 55,6 % de uso entre quienes respondieron sobre bases de datos. Harbor puede usar una base para metadatos, proyectos, usuarios, artefactos y auditoría, mientras el almacenamiento conserva capas y manifiestos.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. Primero, desarrollo construye una imagen con nombre, tag y hash. Segundo, CI la sube a Harbor dentro de un proyecto. Tercero, Harbor valida usuario, cuenta robot, permiso y política del proyecto. Cuarto, el registro guarda manifiesto, capas, etiquetas y eventos de auditoría. Quinto, producción descarga solo desde el registro aprobado. Sexto, backup y restauración prueban base, configuración y storage. Harbor recibe imágenes OCI y entrega un registro consultable por equipos y servidores. PostgreSQL guarda registros estructurados, usuarios, proyectos, estados y auditoría. El almacenamiento de objetos o disco conserva capas y manifiestos. Las cuentas robot reciben permisos acotados para CI/CD y despliegue. La retención borra tags según reglas documentadas por el proyecto. El permiso de push queda en CI y equipos de desarrollo. El permiso de pull queda en servidores y operadores. El permiso de borrar imágenes queda en administración técnica. El permiso de cambiar retención queda en una persona distinta de quien despliega.
Qué se instala o configura primero
El primer entregable verificable es un proyecto con dos repositorios, una cuenta robot de solo lectura, una cuenta de CI con push, una regla de retención y un backup probado. Una pila inicial puede correr con Harbor 2.15.2, PostgreSQL, Redis, storage local o S3 compatible, TLS, métricas y un job de respaldo. El costo mensual estimado va de USD 45 a USD 90, entre $ 67.950 y $ 135.900 al dólar oficial vendedor de $ 1.510; quedan fuera horas de migración de imágenes y escaneo comercial si se contrata aparte. El tiempo razonable es de dos semanas para un piloto. UMSA puede usar este enfoque cuando una organización ya despliega contenedores, pero todavía descarga imágenes desde equipos personales o repositorios externos. La primera entrega debe mostrar una imagen firmada o etiquetada, un deploy que use cuenta robot, una regla de retención ejecutada y una restauración abierta en otro host. La documentación de cuentas robot permite separar automatización de usuarios humanos. Ese corte es el control que evita tokens compartidos en servidores.
Dónde se rompe y cómo probarlo
El primer riesgo es la cuenta robot con más permiso del necesario. La alerta aparece cuando un deploy puede hacer push o borrar. La prueba crea una cuenta de solo lectura, intenta subir una imagen y espera rechazo. El segundo riesgo es la retención mal escrita. La alerta llega cuando una regla borra tags usados por producción. La prueba marca imágenes protegidas, ejecuta una simulación de retención y compara tags antes de aplicar. El tercer riesgo es el storage sin backup. La alerta aparece cuando la base vuelve y las capas no aparecen. La prueba restaura base, configuración y storage siguiendo la guía oficial de backup y restauración, luego ejecuta un pull real. El cuarto riesgo es mantenimiento vencido. La alerta llega cuando la versión queda fuera de ramas mantenidas. La política de seguridad de Harbor indica soporte para ramas recientes; la prueba lista versión instalada, fecha y plan de actualización. Harbor se justifica cuando el equipo puede contestar cuatro preguntas sin buscar en chats: qué imagen corre, quién la subió, quién puede borrarla y cómo vuelve después de una falla.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.