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 GitHub Actions

Usa GitHub Actions como proveedor de identidades de cargas de trabajo. Para ello, intercambia un token OIDC emitido por GitHub por un token de acceso de OpenAI de corta duración. Así, los flujos de trabajo pueden autenticarse en la API de OpenAI sin almacenar una clave de API de larga duración en los secretos de GitHub.

GitHub puede emitir un JWT OIDC firmado para un trabajo de un flujo si ese trabajo tiene el permiso id-token: write y solicita un token de identidad. Antes de emitir un token de acceso, OpenAI valida el emisor, la audiencia, la firma y los atributos de asignación del token de GitHub.

Configurar GitHub Actions

Dale al flujo de trabajo o al trabajo individual permiso para solicitar un token OIDC de GitHub:

permissions:
  id-token: write
  contents: read

El permiso id-token: write permite que el trabajo solicite un JWT OIDC. No otorga acceso de escritura al contenido del repositorio. El permiso contents: read es necesario para usar actions/checkout.

Solicita el token con la audiencia exacta que configuraste en tu proveedor de identidades de cargas de trabajo de OpenAI. Las acciones personalizadas de JavaScript pueden llamar a core.getIDToken("your-wif-audience"). Los pasos de shell pueden enviar la solicitud directamente a la URL que GitHub proporciona para solicitar tokens OIDC. Si el valor de la audiencia contiene caracteres reservados en las URL, como en https://api.openai.com/v1, aplica la codificación de URL al valor antes de añadirlo a la URL de la solicitud:

AUDIENCE="https://api.openai.com/v1"
ENCODED_AUDIENCE=$(jq -rn --arg audience "$AUDIENCE" '$audience | @uri')

TOKEN=$(curl -sSf -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
  "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=${ENCODED_AUDIENCE}" | jq -r .value)
export TOKEN

Entre las principales declaraciones OIDC de GitHub se encuentran las siguientes:

  • iss: el emisor del token. Para GitHub Actions, es https://token.actions.githubusercontent.com.
  • aud: el valor de audiencia que solicita el flujo de trabajo. Configura OpenAI para que exija el valor exacto que solicitas, como your-wif-audience o https://api.openai.com/v1.
  • sub: la cadena que identifica al sujeto principal. GitHub la construye a partir de metadatos del flujo de trabajo, como el repositorio, la rama, la etiqueta, el pull request o el entorno.
  • repository: el repositorio donde se ejecuta el flujo de trabajo, como my-org/my-repo.
  • repository_owner: la organización o el usuario propietario del repositorio, como my-org.
  • ref: la referencia de Git que activó el flujo de trabajo, como refs/heads/main o refs/tags/v1.0.0.
  • workflow: la declaración que indica el nombre del flujo de trabajo. Usa el valor exacto que emite GitHub, como deploy si ese es el valor de la declaración en tu trabajo.
  • workflow_ref: la ruta del archivo del flujo de trabajo y su referencia de Git, como my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main.
  • environment: el nombre del entorno de GitHub, como production, cuando el trabajo usa un entorno.
  • run_id, run_number, run_attempt y job_workflow_ref: identificadores de ejecución y de trabajo que pueden servir para auditorías o reglas de confianza más avanzadas.

Para ver la lista completa de declaraciones y los formatos del sujeto, consulta la referencia de OpenID Connect de GitHub.

Verificar el token

Antes de configurar la federación de identidades de cargas de trabajo, exporta el token OIDC de GitHub como TOKEN. Luego, ejecuta este script en el runner del flujo de trabajo para inspeccionar las declaraciones del token:

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. Nunca escribas en los registros el token OIDC de GitHub sin procesar ni el token de acceso de OpenAI obtenido en el intercambio.

Al decodificar un token OIDC de GitHub Actions, verás algo similar a lo siguiente:

{
  "iss": "https://token.actions.githubusercontent.com",
  "aud": "https://api.openai.com/v1",
  "sub": "repo:my-org/my-repo:environment:production",
  "repository": "my-org/my-repo",
  "repository_owner": "my-org",
  "ref": "refs/heads/main",
  "workflow": "deploy",
  "workflow_ref": "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main",
  "environment": "production",
  "run_id": "1234567890",
  "run_attempt": "1"
}

Usa la carga útil decodificada para comparar los valores del token que recibiste con el emisor, la audiencia y los valores de asignación configurados en OpenAI. Antes de intercambiar el token, puedes detectar la mayoría de los problemas de configuración en las declaraciones iss, aud, repository, ref y workflow_ref.

Configurar la federación de identidades de cargas de trabajo

Crea en OpenAI un proveedor de identidades de cargas de trabajo para GitHub Actions. Luego, agrega una asignación de cuenta de servicio que coincida con las declaraciones de los flujos de trabajo de GitHub en los que confías.

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 github-actions-prod. En Descripción, ingresa un texto como Production GitHub Actions workflows para que los administradores puedan identificar al proveedor.

  2. Configura el emisor y la audiencia. En URL del emisor OIDC, ingresa https://token.actions.githubusercontent.com. En Audiencia, ingresa la audiencia exacta que solicita tu flujo de trabajo, como your-wif-audience o https://api.openai.com/v1.

  3. Usa el mecanismo de descubrimiento OIDC de GitHub. Deja desactivada la opción Usar el JWKS cargado para verificar el token. OpenAI usa los metadatos de descubrimiento OIDC y el JWKS de GitHub para verificar el token firmado por GitHub.

  4. Agrega transformaciones de atributos solo si necesitas atributos de asignación derivados. Puedes usar las declaraciones de GitHub sin transformar, como repository, ref y workflow, directamente en las condiciones de la asignación. Si creas atributos derivados, el panel aplica automáticamente el prefijo openai.. Por ejemplo, ingresa github_repository con la expresión assertion.repository para crear openai.github_repository. Las declaraciones originales del token que ya empiezan con openai. se ignoran al evaluar las claves de asignación que empiezan con openai., salvo que se configure 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 github-actions-main-deploy. En Descripción, ingresa un texto como Production deploy workflow on main para indicar qué flujo de trabajo puede usar la asignación.

  2. Exige coincidencias exactas en las declaraciones. Agrega una fila con Clave y Valor por cada declaración de GitHub que deba coincidir. OpenAI exige que coincidan los valores de todas las filas configuradas antes de emitir un token de acceso. Para un flujo de despliegue en producción, usa condiciones como las siguientes:

    iss == "https://token.actions.githubusercontent.com"
    aud == "https://api.openai.com/v1"
    repository == "my-org/my-repo"
    ref == "refs/heads/main"
    workflow_ref == "my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main"

    En las asignaciones con privilegios, da preferencia a workflow_ref sobre workflow, porque los administradores suelen querer autorizar un archivo de flujo de trabajo con una ruta y una referencia de Git específicas. El nombre de un flujo de trabajo puede cambiar y varios archivos pueden definir flujos de trabajo con el mismo nombre.

    En la interfaz de asignación, ingresa estas condiciones en filas de clave y valor. Por ejemplo, usa Clave repository con Valor my-org/my-repo, Clave ref con Valor refs/heads/main y Clave workflow_ref con Valor my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main. Si el trabajo usa un entorno de GitHub, agrega también Clave environment con Valor production.

    Precaución: evita las asignaciones demasiado amplias, como confiar únicamente en repository_owner == "my-org", salvo que todos los repositorios del espacio de nombres de ese propietario deban poder generar tokens de acceso de OpenAI.

  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 el flujo de trabajo de GitHub, como github-actions-prod-deploy.

  4. Limita los permisos de la API si es necesario. Selecciona los Permisos adecuados, 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 con esta asignación. Deja los permisos en blanco si quieres evitar una restricción de alcance específica de la federación de identidades de cargas de trabajo. El token seguirá dando acceso con los permisos de la cuenta de servicio asignada.

Usar el token en un flujo de trabajo

Configura tu cliente del SDK de OpenAI para que solicite un token OIDC de GitHub y lo intercambie por un token de acceso emitido por OpenAI.

El flujo de trabajo debe otorgar el permiso id-token: write y pasar la configuración de la federación de identidades de cargas de trabajo al código que usa el SDK. El SDK solicita el token OIDC de GitHub mediante las variables de entorno ACTIONS_ID_TOKEN_REQUEST_URL y ACTIONS_ID_TOKEN_REQUEST_TOKEN que GitHub pone a disposición del trabajo. Luego usa el token de acceso de OpenAI obtenido en el intercambio para autenticar las solicitudes a la API.

Por ejemplo, ejecuta el código de tu aplicación desde un flujo de trabajo como este:

name: deploy

on:
  push:
    branches:
      - main
  workflow_dispatch:

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Run OpenAI SDK code
        env:
          OPENAI_WIF_AUDIENCE: ${{ vars.OPENAI_WIF_AUDIENCE }}
          OPENAI_IDENTITY_PROVIDER_ID: ${{ vars.OPENAI_IDENTITY_PROVIDER_ID }}
          OPENAI_SERVICE_ACCOUNT_ID: ${{ vars.OPENAI_SERVICE_ACCOUNT_ID }}
        run: node ./scripts/call-openai.js

Guarda OPENAI_WIF_AUDIENCE, OPENAI_IDENTITY_PROVIDER_ID y OPENAI_SERVICE_ACCOUNT_ID como variables de GitHub Actions. Estas variables identifican al proveedor y a la cuenta de servicio, pero no son credenciales de portador.

Los siguientes ejemplos inicializan un cliente de OpenAI con un proveedor personalizado de tokens de sujeto. El proveedor solicita un token OIDC de GitHub para la audiencia configurada y lo usa como token de sujeto para la federación de identidades de cargas de trabajo.

Autenticarse con un token OIDC de GitHub Actions
import OpenAI from "openai";

const identityProviderId = process.env.OPENAI_IDENTITY_PROVIDER_ID;
const serviceAccountId = process.env.OPENAI_SERVICE_ACCOUNT_ID;
const audience = process.env.OPENAI_WIF_AUDIENCE;
const requestURL = process.env.ACTIONS_ID_TOKEN_REQUEST_URL;
const requestToken = process.env.ACTIONS_ID_TOKEN_REQUEST_TOKEN;

if (
  !identityProviderId ||
  !serviceAccountId ||
  !audience ||
  !requestURL ||
  !requestToken
) {
  throw new Error(
    "Set OPENAI_IDENTITY_PROVIDER_ID, OPENAI_SERVICE_ACCOUNT_ID, OPENAI_WIF_AUDIENCE, and run inside GitHub Actions with id-token: write"
  );
}

function githubActionsOIDCTokenProvider(requestURL, requestToken, audience) {
  return {
    tokenType: "jwt",
    getToken: async () => {
      const url = new URL(requestURL);
      url.searchParams.set("audience", audience);

      const response = await fetch(url, {
        headers: { Authorization: `bearer ${requestToken}` },
      });

      if (!response.ok) {
        throw new Error(
          `Failed to request GitHub OIDC token: ${response.status} ${response.statusText}`
        );
      }

      const body = await response.json();
      if (!body.value) {
        throw new Error("GitHub OIDC token response did not include a value.");
      }

      return body.value;
    },
  };
}

const client = new OpenAI({
  workloadIdentity: {
    identityProviderId,
    serviceAccountId,
    provider: githubActionsOIDCTokenProvider(
      requestURL,
      requestToken,
      audience
    ),
  },
});

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

console.log(response.output_text);

Prácticas recomendadas para GitHub Actions

  • Usa reglas de protección del entorno para los despliegues en producción. Exige aprobaciones o aplica restricciones de rama antes de permitir que los flujos de trabajo accedan a los recursos de producción de OpenAI.
  • Restringe las asignaciones por repositorio. Siempre que sea posible, exige que coincidan las declaraciones específicas del repositorio en vez de permitir el acceso desde todos los repositorios de una organización.
  • Restringe las asignaciones por rama o por flujo de trabajo. Para limitar la emisión de tokens, considera exigir que coincidan declaraciones como repository, ref, environment o workflow_ref.
  • Usa cuentas de servicio de OpenAI distintas para CI/CD y para las cargas de trabajo de producción. Los procesos de compilación suelen requerir permisos diferentes de los que necesitan las aplicaciones desplegadas.
  • Evita conceder acceso a pull requests que provengan de forks que no sean de confianza. Estos pull requests pueden ejecutar código controlado por un atacante y no deben recibir credenciales de producción.
  • Usa tokens de corta duración para los intercambios. Los tokens OIDC de GitHub están diseñados para la autenticación temporal. Intercámbialos solo cuando sea necesario.
  • Audita los cambios de propietario de los repositorios. Las transferencias de repositorios, los cambios de nombre y las modificaciones de permisos pueden afectar los supuestos de seguridad en los que se basan las asignaciones existentes.
  • Da preferencia a las coincidencias exactas entre declaraciones. Exige que coincidan declaraciones como repository, ref y environment en vez de depender de relaciones de confianza que abarquen toda la organización.