Entrevista Backend: ¿Cómo utilizarías OCI Referrers para firmas de imágenes y SBOMs?

Consigna y Contexto

Tu plataforma almacena imágenes en un registro OCI, mientras que el pipeline de publicación debe adjuntar firmas, SBOMs e informes de vulnerabilidades. Diseña un servicio de descubrimiento y verificación: dado un repositorio y un digest de imagen, devuelve los artefactos adjuntos, filtra por artifactType, admite registros que carecen de la API de Referrers y bloquea imágenes no verificadas antes del despliegue. Dirígete a un ingeniero backend o de plataforma; concéntrate en el protocolo del registro y los límites del servicio en lugar de un único SDK de nube.

Qué Evalúa el Entrevistador

Una respuesta sólida trata el digest de la imagen como el subject inmutable, no el tag. Comprende que subject crea la asociación, artifactType describe el propósito y la API de Referrers devuelve un OCI Index. También cubre los tags de fallback heredados, la paginación, la consistencia de caché y el hecho de que descubrir un artefacto es independiente de verificar una firma. "Leer el tag de la imagen" o "un SBOM prueba la confianza" revela un modelo de seguridad incompleto.

Aclaraciones para Preguntar Primero

1. ¿La entrada es un tag o un digest? Si es un tag, resuélvelo y fija el digest antes de la verificación.
2. ¿Se deben admitir registros que devuelven 404? En caso afirmativo, implementa el tag de fallback de OCI y maneja actualizaciones concurrentes.
3. ¿El resultado condicionará el despliegue? En caso afirmativo, verifica la firma, la identidad del publicador y el digest dentro del límite de confianza.
4. ¿Puede la lista de asociaciones exceder una página? En caso afirmativo, transmite el nextToken opaco sin interpretarlo.

Estructura de Respuesta en 30 Segundos

"Primero resuelvo un tag a un digest y uso ese digest como el subject para cada asociación. Llamo a /v2/{name}/referrers/{digest} y filtro firmas, SBOMs o informes por tipo de artefacto. Un 404 de un registro más antiguo activa el tag de fallback derivado del digest. Al descubrimiento le sigue la verificación de la firma y del publicador antes de que una política decida si se permite el despliegue. La API de listado está paginada y en caché con un TTL corto con una clave que incluye el digest y el filtro."

Análisis Detallado Paso a Paso

OCI 1.1 utiliza un manifiesto subject para apuntar al manifiesto que se está referenciando, mientras que artifactType describe el artefacto adjunto. La API de Referrers devuelve un OCI Index cuyos descriptores incluyen digest, tipo de medio y tipo de artefacto:

GET /v2/{name}/referrers/{subject-digest}?artifactType={type}

Rechaza las solicitudes de verificación sin un digest. Un tag es un puntero mutable y no puede ser la clave primaria para la verificación de firmas. Resuélvelo una vez, registra el digest resultante y pasa ese digest a través del descubrimiento, el almacenamiento en caché y la admisión.

Con un registro que admite la API, una respuesta 200 que contiene un Index vacío significa que no hay artefactos adjuntos. Con una implementación más antigua que devuelve 404, el cliente lee el tag de fallback formado reemplazando sha256: con sha256-. Los clientes mantienen ese tag de fallback, por lo que agregar un nuevo referente es una condición de carrera de lectura-modificación-escritura. Los escritores necesitan escrituras condicionales, reintentos optimistas o una cola de un solo escritor; los lectores no deben tratar el fallback como fuertemente consistente.

Procesa las firmas, SBOMs e informes de escaneo descubiertos en tres etapas: filtra por artifactType y política; obtén el manifiesto y contenido referenciados; verifica que la firma cubra el digest objetivo, que el publicador sea confiable y que el estado del artefacto esté permitido. La guía de Microsoft separa la integridad, la autenticidad y el bloqueo antes del consumo, por lo que "se encontró una firma" no es lo mismo que "la imagen es de confianza".

La API puede paginar. Conserva y transmite el nextToken opaco, limita el tamaño de la página e incluye registro, repositorio, digest del subject, tipo de artefacto y contexto de autorización en la clave de caché. Dado que un digest es inmutable, los resultados del descubrimiento se pueden almacenar en caché brevemente; la revocación y los cambios de estado aún requieren un TTL explícito y una política de reverificación. En una ruta de admisión, la caché puede acelerar el descubrimiento, pero no debe omitir la verificación final.

Respuesta de Muestra de Alta Calidad

Haría que el digest fuera la única identidad del subject. El cliente resuelve un tag, llama a la API de OCI Referrers y utiliza artifactType para separar firmas, SBOMs e informes de escaneo. Un registro compatible devuelve un OCI Index; un 404 de un registro más antiguo activa el tag de fallback derivado del digest con reintentos para actualizaciones concurrentes. El descubrimiento por sí solo nunca concede el despliegue. El servicio de admisión verifica el digest objetivo de la firma, la identidad del publicador y la raíz de confianza, y luego aplica la política. El endpoint transmite tokens de paginación opacos y almacena en caché por digest y filtro, mientras que cada despliegue vuelve a verificar en lugar de tratar una entrada de caché como una decisión de confianza.

Errores Comunes

• Error → usar un tag como clave de firma → Por qué falla: los tags pueden ser reasignados → Solución: resolver y fijar el digest primero.
• Error → tratar cada 404 como "sin artefactos adjuntos" → Por qué falla: un registro antiguo podría no implementar Referrers → Solución: leer el tag de fallback de la especificación.
• Error → permitir el despliegue tan pronto como se encuentra una firma → Por qué falla: la identidad del publicador, la cobertura y el digest objetivo permanecen sin verificar → Solución: separar el descubrimiento de la verificación criptográfica.
• Error → analizar o construir nextToken → Por qué falla: el token es un cursor opaco del servidor → Solución: transmitirlo sin cambios y limitar el tamaño de página y los tiempos de espera.

Preguntas de Seguimiento y Respuestas

Pregunta de seguimiento 1: Dos compilaciones actualizan el tag de fallback simultáneamente. ¿Qué haces?

Trata el Index de fallback como una transacción de lectura-modificación-escritura. Utiliza una escritura condicional del registro, reintento optimista o una cola de un solo escritor. En caso de conflicto, lee el Index más reciente y fusiona el nuevo descriptor; nunca sobrescribas la asociación de otra compilación.

Pregunta de seguimiento 2: La firma existe, pero el SBOM hace referencia a un digest anterior. ¿Qué sucede?

Comprueba la consistencia contra el digest del subject actual. Las firmas, SBOMs e informes deben hacer referencia cada uno al mismo digest. Marca una referencia anterior como no aplicable y bloquea la admisión; hacer coincidir solo el tag de la imagen es inseguro.

Pregunta de seguimiento 3: El registro devuelve miles de referentes. ¿Cómo proteges el servicio?

Limita maxResults, transmite el token opaco y usa una caché con TTL corto cuya clave sean el digest y el tipo de artefacto. Consulta solo los tipos requeridos por la política en la ruta de admisión. La indexación en segundo plano puede precalentar los resultados, pero el despliegue aún verifica el digest del manifiesto devuelto y el estado de confianza.