Resumen

  • La revisión 07 establece que un JWT no debe contener más de una audiencia, salvo que no puedan obtenerse varias credenciales o que la carga de trabajo no pueda influir en aud; la revisión 06 solo recomendaba una audiencia.
  • El mecanismo es la suplantación entre receptores: cada parte que recibe el mismo bearer token puede llevarlo a cualquier otra parte que también lo acepte.
  • Un recibo de excepción por capacidad debería registrar la causa, el grafo de receptores, la vida y el alcance del token, la validación, los controles compensatorios, la próxima revisión y la salida prevista.

Un Pod presenta un token proyectado de cuenta de servicio al servidor API de Kubernetes. Después lo reutiliza para federarse con un proveedor de identidad externo. No hay un destinatario fraudulento en la escena: ambos sistemas son legítimos. Pero ambos conservan el mismo bearer token. Si la audiencia permite los dos usos, el proveedor externo puede presentarlo al servidor API y hablar como la carga de trabajo.

No hace falta robar el token durante el tránsito, extraerlo de un registro ni comprometer al emisor. La capacidad de suplantación nace en el acto normal de entrega. Un receptor autorizado obtiene una credencial reutilizable que otro receptor también considera válida.

Esa es la frontera que draft-ietf-wimse-workload-identity-practices-07, subido el 22 de septiembre de 2026, vuelve explícita. El documento sigue siendo un Internet-Draft activo con estatus previsto Informational. Datatracker muestra AD Evaluation::AD Followup y a Charles Eckel como responsable de la acción. No es una aprobación, no es un RFC y no demuestra ni despliegue ni incumplimiento de una plataforma concreta.

De orientación a requisito

La revisión 06 ya pedía reducir el alcance de las credenciales y, cuando la plataforma permitiera obtener varias, usar una distinta para cada recurso o proveedor de identidad. En su sección de audiencia decía que cada JWT debería contener una sola audiencia.

La revisión 07 cambia la carga de la decisión. Las credenciales MUST limitarse tanto como sea posible. La credencial para una función de plataforma MUST quedar destinada a ese recurso. La credencial de federación MUST tener como audiencia única al proveedor de identidad. Cada JWT MUST NOT llevar más de una audiencia, salvo la excepción de capacidad.

El salto de SHOULD a MUST no es una diferencia tipográfica. La separación deja de ser una buena práctica que puede omitirse sin dejar rastro; se convierte en el estado por defecto y obliga a explicar el desvío. El texto añade el mecanismo que faltaba: una relying party incluida en aud puede presentar el mismo token a otra relying party incluida allí y conseguir acceso no previsto.

Una audiencia no es solo metadato para elegir un validador. Enumera los lugares donde la credencial puede hablar. Cada receptor añadido a esa lista es también un nuevo tenedor con capacidad de reproducción.

La regla se repite en Kubernetes, SPIFFE y la nube

Kubernetes puede emitir varios tokens proyectados, cada uno con audiencia y duración propias. La revisión 07 separa el servidor API, un recurso interno y el proveedor de identidad externo: los tokens deben ser diferentes y sus audiencias también.

Comprobar aud en cada sistema no repara un grafo mal diseñado. El proveedor externo puede validar correctamente firma, emisor, caducidad y audiencia, y aun así quedarse con una credencial aceptable para el servidor API. Todos los controles locales pueden dar verde mientras la separación global falla.

SPIFFE presenta la misma geometría: el JWT-SVID de un recurso interno y el de federación externa deben ser tokens distintos con audiencias distintas. En el patrón de proveedor cloud, la revisión 06 decía SHOULD y SHOULD NOT al separar acceso interno y federación con un STS externo; la revisión 07 dice MUST y MUST NOT. La tecnología cambia, pero el objeto de control sigue siendo el conjunto de receptores.

Una carencia reconocida no equivale a aislamiento

Algunas plataformas solo emiten una credencial por carga de trabajo. Otras no permiten que la carga influya en la audiencia. La revisión 07 admite que la regla de audiencia única no pueda cumplirse en esos dos casos.

La excepción no convierte la reutilización en una alternativa equivalente. El despliegue ya no puede confiar en aud para contener una pérdida. Debe usar la vida más corta que permita la plataforma, restringir qué componentes alcanzan la credencial y tratar a cada receptor como capaz de suplantar la carga ante todos los demás.

El control se desplaza desde el aislamiento criptográfico hacia el tiempo, el acceso a componentes, la red, la disciplina de validación y la detección. Son compensaciones, no una prueba de que la frontera exista. La revisión 07 refuerza de igual modo la ausencia de proof of possession: duración menor, audiencia más estricta y controles de red pasan de recomendados a obligatorios. Un bearer token de vida corta sigue siendo reutilizable por quien lo tenga.

El recibo de excepción por capacidad

El registro mínimo debería contener:

Campo Evidencia
Capacidad del emisor Plataforma, emisor, versión exacta y emisión de varias credenciales
Control de audiencia Si la carga puede solicitar o influir en aud, con prueba de API o configuración
Uso previsto API de plataforma, recurso interno, federación o recurso externo
Identidad de credencial Huella no secreta o generación; nunca el valor del bearer token
Grafo de receptores Todos los aceptantes y cada ruta de presentación entre ellos
Vida TTL solicitado y emitido, renovación e invalidación
Alcance Componentes, montajes, sidecars, proxys, registros y salidas que pueden verla
Validación Emisor, audiencia, tipo, PoP y condiciones de red en cada receptor
Excepción Capacidad ausente y causa por la que no puede separarse
Compensación Vida menor, acceso restringido, red, observación y alertas
Revisión Responsable, fecha, próxima revisión, disparador de corrección y salida

La huella debe ser un identificador unidireccional y no secreto. El recibo no autoriza a copiar la credencial en un ticket. Su función es unir una decisión de riesgo a la generación, los receptores y los controles que realmente abarcó.

También debe distinguir «no se puede» de «no se hizo». Si el emisor ofrece credenciales separadas pero una integración reutiliza una por comodidad, no existe excepción de capacidad. Si una versión futura incorpora control de audiencia, llega la condición de salida. Una excepción sin fecha de revisión termina convertida en arquitectura.

El artículo anterior de BTW, A Workload Credential Is Not the Workload, describe ocho pruebas entre el arranque y el resultado. Este análisis se queda en una pregunta más estrecha: ¿en qué receptores puede hablar este bearer token exacto y cuáles pueden volver a presentarlo?

Fuentes y límites

Las fuentes primarias son la ficha de la revisión 07, el historial de Datatracker, el texto inmutable de la revisión 07 y el texto de la revisión 06. La separación entre documento de coordinación y realidad operativa sigue la disciplina de Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption.

Estas fuentes prueban el estado documental, el lenguaje normativo y el mecanismo de riesgo. No prueban un incidente, no ofrecen un censo completo de implementaciones y no establecen el incumplimiento de ningún operador nombrado. El recibo es una propuesta editorial de Daniel Kade, no una obligación del borrador WIMSE.