Harbor 2.14.4 frente a registry mínimo: costo y límite
Un registry privado evita descargas repetidas y deja roles, escaneo y salida documentada. Qué exige Harbor 2.14.4 antes de subir imágenes críticas.
Diez proyectos que empujan imágenes desde Docker Hub pueden gastar más tiempo esperando descargas que manteniendo un registry propio. Harbor 2.14.4, publicado en GitHub el 11 de mayo, permite guardar imágenes, escanear CVE, separar proyectos y crear cuentas robot. Esta guía compara el costo de seguir con un registry mínimo frente a instalar Harbor con permisos, respaldo y prueba de salida. ## Dónde aparece el costo del registry mínimo El sitio oficial de Harbor lo define por funciones concretas: guarda artefactos, aplica políticas, usa control de acceso por rol, escanea vulnerabilidades y firma contenido. La ficha de CNCF lo lista como proyecto graduado y muestra 5.466 contribuyentes. La escala global importa porque una pyme no adopta una herramienta aislada; adopta un componente mantenido por una comunidad amplia. El registry mínimo suele fallar por una imagen con etiqueta latest, subida por una cuenta compartida y sin registro de quién la promovió. Ese es el antagonista: la imagen anónima. En una municipalidad chica del Gran Mendoza, el detalle visible era un servidor torre con dos discos externos rotulados a mano. Cada despliegue dependía de recordar qué imagen había pasado por pruebas. Una etiqueta sin digest ya tomó una decisión. El release v2.14.4 corrige componentes y mantiene la línea 2.14. La decisión técnica no pasa por novedad; pasa por gobierno del artefacto. Si una aplicación municipal, un portal de turnos o un sistema de reclamos sale desde contenedores, el registro debe responder quién subió, qué CVE tenía, qué rol aprobó y cómo se recupera.
Cómo funciona por dentro
El flujo empieza cuando CI construye una imagen y la empuja a Harbor. Harbor recibe repositorio, etiqueta, digest, usuario y proyecto. El registry guarda capas de imagen en almacenamiento local o S3. PostgreSQL guarda proyectos, usuarios, repositorios, etiquetas, políticas, tareas y auditoría. Trivy recibe la imagen o el artefacto y entrega un reporte de vulnerabilidades por severidad. Keycloak, LDAP o usuarios internos entregan identidad. Los roles separan administrador de sistema, administrador de proyecto, desarrollador y usuario de lectura. Las cuentas robot reciben permisos acotados para CI; no entran a la interfaz. La política de retención borra etiquetas viejas según regla escrita. El backup copia base, blobs, configuración y secretos; la prueba restaura un proyecto y vuelve a hacer pull por digest. La documentación de cuentas robot permite separar automatización de personas. La sección de escaneo explica cómo Harbor se conecta con Trivy u otros scanners. La parte de replicación sirve cuando una sede necesita copia local o cuando el proveedor debe entregar una salida verificable.
Qué se instala o configura primero
La pila mínima usa Harbor 2.14.4, PostgreSQL, Redis, registry storage en disco o S3 compatible, Trivy, proxy HTTPS, backup y monitoreo. En una pyme con 20 a 80 repositorios, el costo mensual queda entre USD 160 y USD 340 si incluye servidor, almacenamiento, copia externa y alertas. Con dólar vendedor oficial de ARS 1.462, el rango mensual va de ARS 233.920 a ARS 497.080. La implementación inicial lleva 40 a 70 horas: instalación, proyectos, roles, robot accounts, escaneo, retención, replicación opcional y prueba de restauración. El primer entregable verificable es un proyecto con dos repositorios, una imagen escaneada, un robot de CI, política de retención y restauración de pull por digest. UMSA puede ordenar la adopción con un inventario simple: aplicación, repositorio, responsable, ambiente, regla de escaneo, política de retención y destino de backup. La organización conserva su pipeline; Harbor agrega evidencia sobre el artefacto que llega a producción. El costo debe decir qué incluye. Incluye servidor, almacenamiento, dominio, TLS, backups y monitoreo. No incluye reescribir pipelines, corregir Dockerfiles inseguros ni revisar secretos dentro de imágenes. Esa lista evita que el registry cargue con problemas que pertenecen al proceso de desarrollo.
Dónde se rompe y cómo probarlo
El primer riesgo es permitir tags mutables en producción. La señal aparece cuando dos imágenes distintas usan la misma etiqueta. La prueba sube dos builds con igual tag y verifica que la política rechace el segundo o exija aprobación. El segundo riesgo es la cuenta robot con permisos amplios. La señal aparece cuando CI puede borrar repositorios o leer proyectos ajenos. La prueba crea un robot por proyecto, intenta push, pull, delete y lectura cruzada. El tercer riesgo es el scanner sin metadatos actualizados. La señal aparece cuando los reportes quedan viejos o todos los artefactos figuran como pendientes. La prueba fuerza un escaneo, revisa fecha de base CVE y exporta el reporte. El cuarto riesgo es el backup sin blobs. La señal aparece cuando vuelve la base, pero el pull falla porque las capas no están. La prueba restaura base, configuración y almacenamiento, hace pull por digest y compara hash. El quinto riesgo es la salida incompleta. La señal aparece cuando el proveedor entrega usuarios y no entrega imágenes. La prueba exporta proyectos, reglas, robots revocados y artefactos necesarios para reconstruir el despliegue. Un registry sirve cuando una imagen puede salir, volver y explicar su historia.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.