For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegación principal
Theme

Configurar la federación de identidades de cargas de trabajo para Kubernetes

Para usar Kubernetes como proveedor de identidades de cargas de trabajo, intercambia un token proyectado de una cuenta de servicio de Kubernetes por un token de acceso de corta duración de OpenAI.

Configurar Kubernetes

Esta guía supone que la proyección de tokens de cuentas de servicio está habilitada en Kubernetes. Esta función está disponible de forma predeterminada en las versiones modernas de Kubernetes. La federación de identidades de cargas de trabajo de OpenAI requiere que los tokens proyectados de las cuentas de servicio sean compatibles con OIDC. OpenAI no admite los tokens de cuentas de servicio de Kubernetes que se almacenan en objetos Secret con el mecanismo anterior.

Usa un ServiceAccount de Kubernetes para la carga de trabajo que necesita llamar a la API de OpenAI. Si aún no tienes uno, créalo:

kubectl create serviceaccount openai-wif --namespace default

Obtén el emisor OIDC de tu clúster de Kubernetes:

kubectl get --raw /.well-known/openid-configuration | jq -r .issuer

El emisor OIDC del clúster debe coincidir con el que configuraste en el proveedor de identidades de cargas de trabajo, incluso si subes el JWKS y OpenAI no consulta al emisor para obtenerlo.

Obtén el JWKS del clúster y guarda el conjunto de claves que devuelve el comando. Lo necesitarás al configurar el proveedor de identidades de cargas de trabajo:

kubectl get --raw /openid/v1/jwks

Configura el token proyectado de la cuenta de servicio con la audiencia que espera OpenAI y un plazo de vencimiento adecuado para tu carga de trabajo. OpenAI valida el emisor, la firma, la audiencia y el vencimiento del token. En este ejemplo, el archivo del token se monta en /var/run/secrets/tokens/token. El token usa la audiencia https://api.openai.com/v1 y vence después de 3600 segundos. Puedes usar otra audiencia siempre que la del token proyectado coincida con la del proveedor de identidades de cargas de trabajo de OpenAI:

apiVersion: v1
kind: Pod
metadata:
  name: openai-wif-app
  namespace: default
spec:
  serviceAccountName: openai-wif
  containers:
    - name: app
      image: my-image
      volumeMounts:
        - name: ksa-token
          mountPath: /var/run/secrets/tokens
          readOnly: true
  volumes:
    - name: ksa-token
      projected:
        sources:
          - serviceAccountToken:
              path: token
              audience: "https://api.openai.com/v1"
              expirationSeconds: 3600

Verificar el token

Antes de configurar la federación de identidades de cargas de trabajo, decodifica localmente un token proyectado de ejemplo de una cuenta de servicio y revisa sus declaraciones. Obtén el token de un pod en ejecución que tenga montado el archivo del token proyectado y expórtalo como TOKEN:

TOKEN=$(kubectl exec -n default openai-wif-app -- cat /var/run/secrets/tokens/token)
export TOKEN

Luego ejecuta este script:

const parts = process.env.TOKEN?.split(".") ?? [];
if (parts.length !== 3) {
  throw new Error("Expected a compact JWT with three segments");
}
if (!/^[A-Za-z0-9_-]+$/.test(parts[1]) || parts[1].length % 4 === 1) {
  throw new Error("JWT payload is not valid Base64URL");
}

const bytes = Buffer.from(parts[1], "base64url");
if (bytes.toString("base64url") !== parts[1]) {
  throw new Error("JWT payload is not valid Base64URL");
}
const decoded = new TextDecoder("utf-8", { fatal: true }).decode(bytes);
const claims = JSON.parse(decoded);
if (claims === null || Array.isArray(claims) || typeof claims !== "object") {
  throw new Error("JWT payload is not a JSON object");
}
console.log(decoded);

Este comando decodifica la carga útil del JWT sin verificar la firma del token. Usa un decodificador local para los tokens de producción y evita pegarlos en herramientas de terceros.

Al decodificar un token proyectado de una cuenta de servicio de Kubernetes, verás algo similar a lo siguiente:

{
  "iss": "https://kubernetes.example.com",
  "aud": ["https://api.openai.com/v1"],
  "sub": "system:serviceaccount:default:openai-wif",
  "iat": 1716235422,
  "exp": 1716239022,
  "kubernetes.io": {
    "namespace": "default",
    "serviceaccount": {
      "name": "openai-wif",
      "uid": "11111111-2222-3333-4444-555555555555"
    }
  }
}

Compara los valores de la carga útil decodificada con el emisor, la audiencia y los valores de la asignación que configuraste en OpenAI. Puedes detectar la mayoría de los problemas de configuración en las declaraciones iss, aud y sub antes de intercambiar el token.

Configurar la federación de identidades de cargas de trabajo

Crea en OpenAI un proveedor de identidades de cargas de trabajo para el emisor de Kubernetes. Luego agrega una asignación de cuenta de servicio que coincida con los atributos del token proyectado.

Primero configura el proveedor de identidades de cargas de trabajo y luego crea la asignación de cuenta de servicio.

Configurar el proveedor de identidades de cargas de trabajo

  1. Crea el proveedor de identidades de cargas de trabajo. En Nombre, ingresa un valor único, como kubernetes-prod. En Descripción, ingresa un texto que ayude a los administradores a identificar el clúster, como Production Kubernetes cluster.

  2. Configura el emisor y la audiencia. En URL del emisor OIDC, ingresa el emisor que devuelve kubectl get --raw /.well-known/openid-configuration | jq -r .issuer. Este valor debe coincidir con la declaración iss del token proyectado. En Audiencia, ingresa la misma cadena opaca que configuraste como audiencia en el volumen del token proyectado de la cuenta de servicio. En este ejemplo, el valor es https://api.openai.com/v1.

  3. Sube el JWKS de Kubernetes. Activa Usar el JWKS cargado para verificar los tokens y, en JSON del JWKS, ingresa el resultado de kubectl get --raw /openid/v1/jwks. OpenAI usa este conjunto de claves públicas para verificar los tokens proyectados de cuentas de servicio de Kubernetes. Sube el conjunto de claves completo, incluido el campo keys que las contiene.

    Nota: para los clústeres de Kubernetes que alojas en tu propia infraestructura, OpenAI solo admite el modo JWKS local. Sube el JWKS que devuelve tu clúster. OpenAI no realiza el descubrimiento OIDC a través del emisor configurado, pero sí compara ese emisor con el campo iss del token.

    Si tu clúster rota las claves de firma de las cuentas de servicio, actualiza el JWKS cargado en la configuración del proveedor de identidades de cargas de trabajo. OpenAI rechaza los tokens firmados con claves que no figuran en el JWKS configurado. Si el JWKS contiene varias claves públicas activas, incluye el arreglo keys completo.

  4. Agrega transformaciones de atributos solo si necesitas atributos derivados para la asignación. Puedes usar las declaraciones del token sin transformar, como sub, aud e iss, directamente en las condiciones de la asignación. Si vas a comprobar coincidencias con atributos transformados en lugar de usar las declaraciones originales del token, el panel aplica automáticamente el prefijo openai.. Por ejemplo, ingresa workload_subject con la expresión assertion.sub para crear openai.workload_subject. Las declaraciones originales del token que ya empiezan con openai. se ignoran al evaluar claves de asignación que empiezan con openai., a menos que configures la transformación correspondiente.

Configurar la asignación de cuenta de servicio

  1. Crea una asignación de cuenta de servicio. En Nombre, ingresa un valor único dentro del proveedor de identidades de cargas de trabajo, como openai-mapping-kubernetes. En Descripción, indica qué carga de trabajo puede usar la asignación, por ejemplo, Workload Identity Provider Mapping for Kubernetes Workloads.

  2. Configura la coincidencia con el sujeto de la cuenta de servicio de Kubernetes. En Clave, ingresa sub y, en Valor, ingresa system:serviceaccount:default:openai-wif. Para las cuentas de servicio de Kubernetes, el formato del sujeto es system:serviceaccount:<namespace>:<service-account-name>.

  3. Elige el destino en OpenAI. En Proyecto, selecciona el proyecto de OpenAI al que pertenece la cuenta de servicio de destino. En Cuenta de servicio, selecciona la cuenta de servicio de OpenAI que puede usar la carga de trabajo de Kubernetes, como kubernetes-prod-openai-wif. Marca Create a new service account in this project si quieres crear una cuenta de servicio para esta asignación en lugar de reutilizar una existente.

  4. Limita los permisos de la API si es necesario. En Permisos, selecciona los que correspondan, como api.model.request y api.vector_store.read, para limitar aún más el alcance de los tokens de acceso que se emitan a partir de esta asignación. Deja los permisos en blanco para evitar agregar una restricción de alcance específica de WIF. El token seguirá autorizando el acceso con los permisos de la cuenta de servicio asignada.

Usar el token en el código

Configura tu cliente del SDK de OpenAI para que lea el token proyectado de Kubernetes y lo intercambie por un token de acceso emitido por OpenAI.

Configura la ruta del archivo montado, por ejemplo, /var/run/secrets/tokens/token, como origen del token de sujeto para el proveedor de federación de identidades de cargas de trabajo del SDK. El SDK intercambia ese token de Kubernetes por un token de acceso emitido por OpenAI y usa el token de OpenAI para autenticar las solicitudes a la API.

Los siguientes ejemplos inicializan un cliente de OpenAI con un proveedor personalizado de tokens de sujeto. El proveedor lee el token proyectado de la cuenta de servicio de Kubernetes desde el archivo montado y lo usa como token de sujeto para la federación de identidades de cargas de trabajo.

Autenticarse con un token proyectado de una cuenta de servicio de Kubernetes
import { readFile } from "node:fs/promises";
import OpenAI from "openai";

const tokenPath = "/var/run/secrets/tokens/token";
const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;

if (!identityProviderId || !serviceAccountId) {
  throw new Error(
    "Set OPENAI_IDENTITY_PROVIDER_ID and OPENAI_SERVICE_ACCOUNT_ID"
  );
}

function mountedServiceAccountTokenProvider(path) {
  return {
    tokenType: "jwt",
    getToken: async () => {
      const token = (await readFile(path, "utf8")).trim();
      if (!token) {
        throw new Error("The mounted service account token file is empty.");
      }
      return token;
    },
  };
}

const client = new OpenAI({
  workloadIdentity: {
    identityProviderId,
    serviceAccountId,
    provider: mountedServiceAccountTokenProvider(tokenPath),
  },
});

const response = await client.responses.create({
  model: "gpt-5.6-terra",
  input: "Say hello from Kubernetes workload identity federation.",
});

console.log(response.output_text);

Buenas prácticas para Kubernetes

  • Usa un emisor OIDC estable. La URL del emisor debe coincidir con la declaración iss del token proyectado de la cuenta de servicio y debería mantenerse estable durante las actualizaciones del clúster y las tareas de mantenimiento.
  • Protege con cuidado las claves de firma. Cualquier persona con acceso a las claves de firma de las cuentas de servicio del clúster puede emitir tokens que OpenAI podría aceptar.
  • Usa cuentas de servicio dedicadas para las integraciones con OpenAI. Evita reutilizar cuentas de servicio que también se usen para acceder a infraestructura o aplicaciones ajenas a la integración.
  • Mantén actualizado el JWKS cargado. En el modo JWKS local, OpenAI usa el JWKS configurado para validar los tokens de identidad de las cargas de trabajo. Por eso, actualiza el proveedor de identidades de cargas de trabajo antes de empezar a usar nuevas claves de firma.
  • Mantén simples las declaraciones personalizadas. Para comprobar coincidencias, da preferencia a las declaraciones estándar, como sub y aud, o a los atributos transformados que se deriven directamente de ellas.
  • Ten en cuenta quién controla cada espacio de nombres como parte de tu modelo de seguridad. Si los administradores de espacios de nombres pueden crear cuentas de servicio, asegúrate de que las asignaciones tengan el alcance adecuado para evitar una elevación de privilegios no intencional.
  • Supervisa los cambios en el emisor y las claves de firma. Si rotas las claves de firma sin actualizar el JWKS del proveedor de identidades de cargas de trabajo, el intercambio de tokens puede fallar.