Resumen

  • draft-ietf-wimse-workload-identity-practices-06 describe credenciales emitidas por plataformas, breves y restringidas por audiencia como alternativa a secretos estáticos administrados por la aplicación.
  • Validar la credencial no demuestra por sí solo la instancia exacta, la custodia exclusiva de la clave, el agotamiento de copias antiguas, el permiso de la operación, su ejecución o el efecto buscado.

El comprobante no contiene toda la realidad

El borrador Workload Identity Practices parte de un problema operativo conocido. Una contraseña, una API key o un secreto OAuth instalado en la carga debe aprovisionarse, protegerse y rotarse. Si es robado, permite suplantación hasta que alguien logre retirarlo. Las plataformas modernas pueden observar la carga, emitir una credencial propia y permitir que se canjee ante un proveedor de identidad por otra adecuada al recurso externo.

El patrón aparece con formas distintas. Kubernetes proyecta tokens de service accounts. SPIFFE ofrece X509-SVID y JWT-SVID por una API local. Los proveedores cloud usan endpoints de metadatos y STS. Las mallas suelen entregar claves al proxy. La convergencia consiste en evitar el secreto duradero, no en borrar las diferencias de control.

También importa el estado del texto. El Datatracker registra la revisión 06 como Internet-Draft activo, con categoría pretendida Informational, remitido al IESG y en “AD Evaluation::Revised I-D Needed”. No es un RFC, una constatación de despliegue ni un recibo de resultados.

Primera prueba: la observación inicial

Antes de firmar nada, la plataforma decide qué identidad corresponde al solicitante. Esa decisión depende de los atributos observados: host, dirección, UID, proceso, metadatos del kernel, cgroup, etiquetas del orquestador o procedencia del trabajo. La fuerza de la identidad no puede superar la fuerza y actualidad de esa observación.

SPIFFE evita pedir un secreto previo a la Workload API. Identifica fuera de banda al proceso por su contexto. Es una solución elegante al arranque, pero no vuelve infalible al selector. Un identificador de máquina compartida permite un alcance mayor que un selector ligado a proceso e instancia. Hace falta un recibo con emisor, atributos vistos, versión del attestor, política, hora y decisión.

Segunda prueba: la instancia viva

La administración de service accounts de Kubernetes distingue tokens vinculados, TokenRequest y revisión. El kubelet puede pedir un token según la configuración del Pod y entregarlo a sus contenedores; los claims pueden nombrar namespace, cuenta, Pod y nodo.

Pero la firma es una fotografía. El Pod puede haber terminado, una réplica nueva puede compartir la cuenta o la política puede haber cambiado. La validación offline confirma firma y claims, no la existencia actual del objeto. El propio borrador señala que la invalidación por borrado solo se descubre mediante TokenReview.

La unión al runtime necesita una prueba fresca que nombre la instancia concreta, su ciclo de vida, el epoch de scheduling y política y el instante de evaluación. El sub de una cuenta compartida no ofrece esa precisión.

Tercera prueba: emisión y entrega

Emitir bytes correctos no asegura que el consumidor correcto los cargue. Para archivos, el borrador recomienda renovar antes de invalidar, reemplazar atómicamente y hacer flush. Para APIs locales, sockets Unix, loopback o direcciones link-local permiten entregar y actualizar credenciales. Las variables de entorno son estáticas y se filtran con facilidad en observabilidad y diagnóstico; no deben usarse si existe otra vía.

El rename atómico impide leer medio archivo, pero no obliga a reabrirlo ni elimina copias en memoria. Una respuesta de API confirma una entrega en una conexión, no la ausencia de SSRF, escucha privilegiada o desvío por una aplicación vulnerada. El recibo de entrega debe unir canal, instancia, hash de credencial y aceptación del consumidor.

Cuarta prueba: posesión, no exclusividad

Un bearer token robado se puede reproducir durante su validez. El borrador prefiere mecanismos de proof of possession. X.509 demuestra control de la clave en el handshake; un JWT ligado a clave exige prueba adicional. RFC 8705 define un ejemplo de access tokens OAuth ligados a certificados de TLS mutuo.

La prueba se limita al intercambio. No certifica que la clave jamás se copiara, que solo un proceso pueda invocarla ni que ese proceso siga siendo la carga observada al principio. Sidecars, agentes de nodo o interfaces HSM pueden usar la clave sin exportarla. La custodia exclusiva requiere controles y evidencia aparte.

Quinta prueba: audiencia frente a permiso

El borrador recomienda una credencial por recurso o proveedor de identidad y, en JWT, una sola audiencia. Un token para la API de Kubernetes no debería reutilizarse en federación externa. Separar audiencias limita el radio de abuso.

Sin embargo, aud dice quién puede aceptar el token, no qué acción concreta está permitida. RFC 7521 establece el marco de assertions OAuth y RFC 7523 el perfil JWT bearer. Procesar una assertion puede autenticar al cliente o sustentar un grant; el recurso aún debe evaluar el verbo, objeto, parámetros, estado actual y política.

Aquí se separa este trabajo del Artículo previo sobre OAuth para agentes. Aquel estudió quién autoriza los argumentos finales producidos por el modelo. Este estudia la cadena anterior y posterior de identidad: arranque, vínculo runtime, entrega, posesión, rotación y desaparición.

Sexta prueba: terminar la rotación

Una vida corta reduce tiempo de abuso, no revoca en el acto. Renovar antes de invalidar crea intencionadamente un periodo en que dos credenciales funcionan. Después de cambiar el archivo, una aplicación puede conservar la antigua en memoria, en un pool, en el proxy o en una cola de reintentos.

El borrador advierte que almacenamiento persistente, backups, snapshots e imágenes pueden retener copias. Un volumen de memoria reduce la exposición sin demostrar una limpieza total. Los emisores deberían invalidar por separado la credencial de cada instancia detenida o eliminada y ofrecer una consulta de estado; la mecánica concreta queda fuera de alcance.

“Rotado” necesita cuatro recibos: nueva emisión, adopción por consumidores, rechazo o expiración del valor anterior y drenaje de caches e instancias conocidos.

Séptima y octava pruebas: ejecutar y obtener el resultado

Los borradores WIMSE sobre arquitectura, credenciales, firmas HTTP y TLS mutuo fortalecen piezas de identidad y autenticación. Ninguna prueba que la operación de aplicación se completó.

El recurso puede validar emisor, tiempo, audiencia, tipo, clave y claims y aun negar la acción. Puede aceptarla y fallar antes del commit. Un proxy compartido puede autenticarse en nombre de varias cargas. Solo el servicio que produce el efecto puede emitir el recibo de solicitud canónica, decisión, transacción y commit. Solo un observador del estado final puede acreditar el resultado.

La distinción de Heng Lu entre capa real y capa simbólica permite ver el error: el token, la política y el mensaje de éxito tienen significado, pero la realidad es el estado ejecutado y observado. La especificación mínima con validación local y la primacía del código en funcionamiento recomiendan mantener cada comprobante cerca del sistema capaz de verificarlo.

La cadena completa formula ocho preguntas: qué observó la plataforma; qué instancia quedó vinculada; qué se emitió y entregó; qué clave se demostró; qué audiencia y operación fueron autorizadas; dónde dejó de funcionar la credencial anterior; si la solicitud se ejecutó; y si apareció el resultado esperado. No se necesita un token universal, sino recibos estrechos que permitan ubicar el fallo.