Registros y confianza en imágenes

Los registros proporcionan las imágenes que ejecutan los nodos Docker y los artefactos que publican los Build Workers. Opfield mantiene las credenciales de los registros y las decisiones de acceso separadas de la configuración de las cargas de trabajo que consumen una imagen. Esta separación permite a un operador rotar el acceso a un registro sin exponer una contraseña en un Container, un Deployment o una definición de origen.

Define la política de confianza en imágenes

La decisión clave no es solo dónde se guarda una imagen, sino qué pruebas se exigen antes de que pueda ejecutarse. Una política práctica identifica los registros aprobados, los digests inmutables obligatorios, quién puede publicar, el umbral de vulnerabilidades, los responsables de las credenciales y durante cuánto tiempo se conservan los artefactos de reversión.

Los equipos de aplicaciones eligen el artefacto de software. Los responsables de seguridad definen la admisión y el alcance de las credenciales. Los responsables de la plataforma mantienen la disponibilidad del registro y el acceso desde los nodos de destino. Opfield registra los mapeos, los secretos, la procedencia de los builds y los resultados de las políticas, pero no convierte en fiable una imagen desconocida solo porque se haya podido descargar.

El éxito significa que la carga de trabajo desplegada usa el digest revisado, que cada nodo necesario puede descargarlo a través de una ruta de credenciales aprobada y que el artefacto anterior que se sabe que funcionaba sigue disponible durante la ventana de reversión.

Configura un acceso de confianza

Guarda las credenciales de los registros privados en Opfield y limítalas a la ruta de build o de ejecución prevista. Configura un origen de servicio de tokens de confianza independiente solo cuando el registro delegue intencionadamente la autenticación Bearer en ese servicio. Confirma el endpoint del registro, el acceso al repositorio y la confianza en el certificado antes de un despliegue en producción.

No pongas nunca contraseñas de registros en referencias de imágenes, URL de Git, argumentos de build, logs, nombres de archivos o capturas de pantalla. Si la autenticación falla, diagnostica la credencial del registro, el permiso sobre el repositorio, la configuración del servicio de tokens y la accesibilidad desde el nodo de destino en lugar de reiniciar repetidamente la carga de trabajo.

Comportamiento del registro interno

El registro Distribution interno de Opfield guarda los artefactos de build aprobados por digest inmutable. Conserva los artefactos que necesitan las cargas de trabajo activas, los slots de reversión, las operaciones en curso, las referencias fijadas y los builds correctos recientes. No requiere un dominio público para el uso interno de Opfield. El registro informa del almacenamiento que realmente usa su volumen, actualizado aproximadamente cada 10 minutos.

Que una imagen esté en el registro interno no la convierte en una versión pública. Una carga de trabajo todavía tiene que configurarse para usar el digest, descargarlo correctamente en su nodo de destino y superar su verificación operativa.

Acceso opcional para clientes Docker externos

El acceso para clientes Docker externos es un derecho de plan y una configuración de ingress independientes, y funciona con nodos Ingress nginx estándar. Requiere una ubicación nginx seleccionada, un dominio, un certificado TLS y un token limitado por repositorio o por acción. Cuando termina el periodo de gracia de una licencia, el punto de entrada externo y sus ajustes se conservan, pero el endpoint de tokens no emite tokens nuevos hasta que se renueve el plan. Cada petición de token vuelve a comprobar la autorización y el derecho de plan vigentes, de modo que revocar cualquiera de ellos se aplica a los accesos siguientes.

Activa el acceso externo solo cuando lo requiera un flujo de trabajo real de un cliente. Valida TLS, la autenticación y los permisos mínimos de repositorio y acción con un cliente que no sea de producción antes de depender de él para la automatización. Eliminar la configuración de ingress detiene el acceso de los clientes, pero no elimina los artefactos conservados internamente.

Guía para incidentes y limpieza

Ante una descarga fallida, confirma primero el digest exacto de la imagen, el mapeo del registro, el alcance de la credencial y la ruta de red del nodo. Ante una imagen inesperada, compara su digest con el registro del build aprobado en lugar de fiarte de un tag. Antes de eliminar la configuración de un registro, identifica las cargas de trabajo y los candidatos de reversión que todavía la necesitan; cámbialos antes a una alternativa aprobada.

Ciclo de vida de las credenciales

Prefiere credenciales limitadas por repositorio y por acción a tokens amplios de administración del registro. Registra un responsable y un proceso de rotación para cada credencial, y prueba la sustituta antes de revocar el valor antiguo cuando la entrega continua dependa de ella. La revocación debe tener en cuenta por separado los Build Workers, los nodos Docker y los clientes externos, porque pueden usar rutas de acceso distintas.

Si una credencial queda expuesta, revócala en el registro, sustitúyela en Opfield e identifica los builds o las descargas realizados durante la ventana de exposición. Rotar solo la copia de Opfield no invalida el secreto original en el proveedor. Revisa los logs en busca de repositorios o digests inesperados sin copiar cabeceras con secretos en el registro del incidente.

Detalles para operadores: fallos de descarga y retención

Ante fallos de autenticación, separa la accesibilidad DNS/TLS, el mapeo del registro, el rechazo de la credencial, el origen del servicio de tokens, el permiso sobre el repositorio y el manifiesto inexistente. Prueba el repositorio y el digest exactos desde la ruta de ejecución afectada, no desde una estación de trabajo de administrador sin relación.

Antes de purgar el registro interno o eliminar el acceso externo, identifica los digests de las cargas de trabajo activas, los slots de reversión de los Deployments, los builds en curso, los artefactos fijados y las versiones recientes que se sabe que funcionan. Si se eliminó un artefacto necesario, vuelve a publicarlo o reconstrúyelo desde la revisión de código verificada antes de cambiar la carga de trabajo. No lo sustituyas por un tag sin verificar que casualmente tenga el mismo nombre.