Autenticación ascendente sin llave para puertas de enlace AI API: un patrón de federación de identidades de carga de trabajo

Los trabajadores de la puerta de enlace de producción no deben llevar claves API ascendentes de larga duración cuando el proveedor puede autenticar la carga de trabajo. El patrón más seguro es intercambiar una identidad existente de nube, Kubernetes, CI o SPIFFE por una credencial de proveedor de corta duración, almacenar en caché esa credencial correctamente y restringirla al límite de autorización útil más pequeño.

La parte difícil no es el intercambio de tokens. Maneja soporte desigual de proveedores, actualizaciones simultáneas, mapeo de identidades, excepciones del plano de control, interrupciones y migración sin crear un recurso oculto a una clave compartida con amplios privilegios.

Comience con capacidades de autenticación, no con una configuración global sin llave

Hecho: La compatibilidad con la autenticación difiere según el proveedor y la operación. OpenAI y Anthropic admiten la federación de identidades de cargas de trabajo para API cargas de trabajo. Azure OpenAI admite Microsoft Entra ID e identidades administradas. Google La nube admite cuentas de servicio adjuntas, credenciales predeterminadas de aplicaciones y federación de identidades de cargas de trabajo para cargas de trabajo externas. Sin embargo, las API administrativas y de inferencia en tiempo de ejecución no aceptan necesariamente los mismos tipos de credenciales.

Por ejemplo, los tokens de identidad de carga de trabajo OpenAI actualmente no pueden llamar a los puntos finales del administrador API. Por lo tanto, una puerta de enlace no puede representar de forma segura la autenticación como un campo a nivel de proveedor como auth_mode: federated.

Recomendación: Cree una matriz de capacidades codificada por cuenta de proveedor, familia de terminales, entorno y clase de operación:

Almacene esta matriz como configuración versionada. La admisión de ruta debe rechazar una operación cuando su identidad configurada no puede satisfacer la capacidad de autenticación requerida. Esto pertenece a un plano de control AI API para equipos de desarrolladores, no a variables de entorno no documentadas en trabajadores individuales.

Colocar un intermediario de credenciales entre los adaptadores de enrutamiento y de proveedor

Los adaptadores de proveedor no deben recuperar credenciales de metadatos, crear aserciones ni administrar la actualización de tokens de forma independiente. Introduzca un intermediario de credenciales con una interfaz estrecha:

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

El valor de la credencial es confidencial y debe permanecer en la memoria o en una caché efímera aprobada. El contexto de autorización registra el proyecto del proveedor, la cuenta de servicio, los ámbitos, las funciones o las restricciones de implementación representadas por el token. La procedencia identifica cómo se adquirió, como oidc_exchange, managed_identity, adc o break_glass.

Este contrato mantiene el proveedor de enrutamiento neutral al mismo tiempo que conserva los detalles necesarios para las verificaciones de autorización y la telemetría. También evita que una puerta de enlace multimodelo API para equipos trate cada token de portador como intercambiable.

Usar adaptadores de adquisición específicos del proveedor

Cada adaptador de adquisición debe realizar solo los pasos requeridos por su proveedor:

• Obtener una aserción externa de la fuente de identidad local, como un token de cuenta de servicio proyectado de Kubernetes, un servicio de metadatos en la nube o una carga de trabajo SPIFFE API.
• Solicitar la audiencia exacta esperada por el proveedor o la regla de federación configurada.
• Intercambiar la aserción cuando el proveedor requiera un intercambio de token.
• Devolver el resultado tiempo de caducidad de credenciales y autoridad.
• Clasifique las fallas como errores de identidad local, intercambio, autorización, configuración o disponibilidad del proveedor.

El punto final compatible con OpenAI de Vertex AI es un ejemplo útil de separación: una aplicación puede obtener un token de acceso Google a través de las credenciales predeterminadas de la aplicación y proporcionar ese token como la credencial del cliente OpenAI. El adaptador de protocolo sigue siendo compatible con OpenAI, mientras que la adquisición de credenciales sigue siendo específica de Google.

Hacer que la caché de token tenga en cuenta la autorización

Hecho: Las credenciales federadas tienen una vida corta. OpenAI tokens de acceso a identidad de carga de trabajo no duran más de una hora, no pueden sobrevivir al token de sujeto externo o al certificado verificado y se emiten sin tokens de actualización. La carga de trabajo debe repetir el intercambio antes de que caduque.

Una clave de caché debe incluir todas las dimensiones que puedan cambiar la autoridad resultante:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

Omitir la cuenta, la audiencia o los ámbitos de destino puede hacer que un trabajador reutilice un token válido en el contexto de autorización incorrecto. Eso es más peligroso que un error de caché.

Actualizar antes de que caduque utilizando un margen de seguridad y fluctuación aleatoria. Una política práctica es:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

El margen exacto debe tener en cuenta el desfase del reloj, la latencia del intercambio, el tiempo de reintento y la solicitud esperada más larga. No actualice únicamente con un temporizador fijo separado de expires_at.

Evite las tormentas cambiarias con la actualización de un solo vuelo

Cuando muchas solicitudes encuentran el mismo token a punto de caducar, solo una ejecución debe realizar el intercambio. Otras personas que llaman deben continuar usando la credencial existente mientras permanezca dentro de la ventana permitida, o esperar brevemente el resultado de la actualización compartida.

Utilice un bloqueo de un solo tramo por clave de caché. En una implementación de múltiples procesos o nodos, decida si cada trabajador puede mantener su propia caché o si se debe distribuir la coordinación de actualización. Un caché local es más simple pero aumenta el volumen de intercambio. Una caché distribuida reduce los intercambios, pero amplía los límites de los tokens sensibles y requiere transporte cifrado, control de acceso estricto y desalojo cuidadoso.

Recomendación: Prefiera las cachés en proceso a menos que los límites del proveedor o el tamaño de la flota demuestren la necesidad de un servicio de token compartido. Primero coordine las actualizaciones dentro de cada proceso y luego mida el volumen de intercambio.

Vincular identidades a reclamaciones exactas de carga de trabajo

La federación traslada la confianza de una clave almacenada a reclamaciones de identidad. Por lo tanto, una asignación permisiva puede ser tan peligrosa como una credencial compartida filtrada.

Valide el emisor y el público objetivo y luego vincule la asignación a afirmaciones inmutables o estrictamente controladas. Para Kubernetes, incluya el espacio de nombres y la cuenta de servicio en lugar de confiar en cualquier carga de trabajo del clúster. Para CI, restrinja el repositorio, el flujo de trabajo, el entorno y la rama protegida o el contexto de implementación. Para las identidades de nube, asigne una entidad principal de carga de trabajo específica en lugar de un inquilino u organización completo.

Cree cuentas de servicio ascendentes independientes o identidades administradas para producción, preparación, trabajos en segundo plano y automatización administrativa. Restrinja cada identidad a los modelos, proyectos, espacios de trabajo, implementaciones y API operaciones que necesita.

Hecho: OpenAI puede restringir las asignaciones de identidades de cargas de trabajo con permisos API. Anthropic asocia las credenciales intercambiadas con una cuenta de servicio y advierte que la federación es tan segura como la configuración de identidad ascendente. Las identidades administradas y la IAM en la nube dependen de manera similar de asignaciones de roles con el alcance correcto.

Separar las credenciales de tiempo de ejecución de las credenciales administrativas

Un trabajador de inferencia nunca debe heredar un token de administrador de la organización simplemente porque alguna tarea del plano de control todavía lo necesita. Divida el sistema en dos límites de seguridad:

• Plano de ejecución: Maneja solicitudes de modelo y recibe solo credenciales federadas o administradas con alcance de inferencia.
• Plano de control: Realiza la administración de proyectos, espacios de trabajo, facturación o cuentas de servicio a través de trabajos aislados con credenciales almacenadas por separado y controles de aprobación más estrictos.

Las credenciales administrativas no deben tener acceso a variables del entorno de ejecución, especificaciones de pod, paquetes de depuración o cachés de tokens. Registre su uso en el mismo sistema de auditoría de solo anexos que se utiliza para los cambios de configuración.

Falla cerrada sin improvisar la recuperación

Recomendación: No reemplace automáticamente un intercambio de federación fallido con una clave estática compartida. El respaldo automático puede omitir una asignación revocada, ocultar una audiencia incorrecta o restaurar el acceso que un administrador de identidad eliminó intencionalmente.

Devolver un error de autenticación ascendente clasificado, detener el envío a la cuenta del proveedor afectado y permitir que la política de enrutamiento normal seleccione otro proveedor solo cuando esa alternativa esté permitida para el inquilino y la carga de trabajo. La reserva de modelo y la reserva de credenciales son decisiones diferentes.

Una llave de emergencia aún puede estar justificada en caso de interrupciones graves del proveedor de identidad. Manténgalo desactivado o inaccesible en funcionamiento normal. La activación debe requerir una aprobación autenticada, tener un vencimiento fijo, restringir la cuenta y las operaciones del proveedor afectado y alertar sobre cada solicitud realizada con él. Su procedencia debe aparecer en la telemetría de solicitud.

Migrar un grupo de enrutamiento a la vez

1. Tiempo de ejecución del inventario y credenciales administrativas. Identifique qué procesos pueden leer cada uno.
2. Cree una identidad de carga de trabajo dedicada y una cuenta de servicio de proveedor de alcance limitado.
3. Configure asignaciones exactas de emisor, audiencia, asunto y permisos.
4. Agregue una verificación previa que adquiera un token y llame a un punto final permitido de bajo impacto.
5. Canary un pequeño grupo de enrutamiento usando solo la federación. No deje habilitada la reserva automática de claves durante la prueba.
6. Compare los errores de autenticación, la latencia de intercambio, la antigüedad del token y los resultados de autorización del proveedor con la ruta existente.
7. Aumente el tráfico gradualmente y observe al menos un ciclo completo de actualización del token.
8. Elimine la clave anterior del acceso en tiempo de ejecución y luego revocarla después del período de observación definido.

Repita este proceso por cuenta de proveedor y entorno. Una transferencia global dificulta distinguir un error de asignación de identidad de un comportamiento de token específico del proveedor.

Instrumentar y probar los modos de fallo

Registrar la latencia del intercambio de tokens, los intentos de actualización, los errores de actualización, la antigüedad de las credenciales, el emisor, el principal asignado, la cuenta del proveedor, la clase de operación y la categoría de error de autenticación. Nunca registre tokens de acceso, afirmaciones externas, secretos de clientes ni encabezados de autorización completos.

Antes de que la federación se convierta en la única ruta de producción, pruebe:

• Desfase horario entre trabajadores, proveedores de identidad y servicios de token de proveedor.
• No disponibilidad del punto final de identidad de carga de trabajo o servidor de metadatos.
• Aserciones caducadas y audiencias incorrectas.
• Eliminación de funciones y desactivación de reglas de federación.
• Limitación de intercambio de tokens y proveedor temporal errores.
• Actualización simultánea en momentos de pico de tráfico.
• Rotación de claves de firma mientras los tokens antiguos siguen siendo válidos.

Para la rotación de emisores de OIDC, publique claves de firma nuevas y antiguas con suficiente superposición para las cachés de verificadores y los tokens emitidos. OpenAI documenta el almacenamiento en caché de 600 segundos para descubrimiento y datos JWKS remotos, con una actualización de JWKS cuando un token hace referencia a una ID de clave desconocida. No asuma que todos los verificadores se comportan de manera idéntica; Pruebe la rotación con canarios vivos.

Adoptar la autenticación en tiempo de ejecución sin clave como una migración limitada

El objetivo no es afirmar que la puerta de enlace no contiene secretos. Su objetivo es eliminar las claves de proveedor de larga duración de los trabajadores en tiempo de ejecución de gran volumen y limitar las credenciales administrativas inevitables a un límite de plano de control más pequeño.

Comience con la matriz de capacidades, intermediario de credenciales a través de una interfaz, almacene en caché por contexto de autorización, use asignaciones de identidad exactas y cierre fallido en caso de errores de intercambio. Complete la migración solo después de observar pruebas exitosas de actualización, revocación, interrupción y rotación de claves de firma. Esto produce una ruta de tiempo de ejecución sin clave cuyo comportamiento de disponibilidad y autorización se comprende en lugar de asumirse.

Lectura relacionada

• verificación de las credenciales del proveedor antes de enrutar el tráfico de producción