For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
Navegação principal

Configuração da federação de identidades de cargas de trabalho para o GitHub Actions

Use o GitHub Actions como provedor de identidade de cargas de trabalho, trocando um token OIDC emitido pelo GitHub por um token de acesso da OpenAI de curta duração. Isso permite que os fluxos de trabalho se autentiquem na API da OpenAI sem armazenar uma chave de API de longa duração nos segredos do GitHub.

Para o Codex, use esta página para obter e inspecionar o token do GitHub. Depois, configure a identidade de cargas de trabalho do Codex para gravar esse token em um arquivo e indicar esse arquivo ao Codex. O mapeamento de contas de serviço e os exemplos de SDK desta página se aplicam à API da OpenAI.

O GitHub pode emitir um JWT OIDC assinado para um trabalho de fluxo de trabalho que tenha a permissão id-token: write e solicite um token de identidade. A OpenAI valida o emissor, o público-alvo, a assinatura e os atributos de mapeamento do token antes de emitir um token de acesso da OpenAI.

Configuração do GitHub Actions

Conceda ao fluxo de trabalho ou ao trabalho permissão para solicitar um token OIDC do GitHub:

permissions:
  id-token: write
  contents: read

A permissão id-token: write permite que o trabalho solicite um JWT OIDC. Ela não concede acesso de escrita ao conteúdo do repositório. A permissão contents: read é necessária para actions/checkout.

Solicite o token com o público-alvo exato configurado no seu provedor de identidade de cargas de trabalho da OpenAI. Ações JavaScript personalizadas podem chamar core.getIDToken("your-wif-audience"); etapas de shell podem chamar diretamente a URL de solicitação OIDC do GitHub. Valores de público-alvo que contenham caracteres reservados de URL, como https://api.openai.com/v1, devem ser codificados para URL antes de serem acrescentados à URL de solicitação:

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

As principais declarações OIDC do GitHub incluem:

  • iss: O emissor do token. Para o GitHub Actions, é https://token.actions.githubusercontent.com.
  • aud: O valor de público-alvo solicitado pelo fluxo de trabalho. Configure a OpenAI para exigir o valor exato que você solicita, como your-wif-audience ou https://api.openai.com/v1.
  • sub: A string principal que identifica o sujeito. O GitHub a constrói a partir de metadados do fluxo de trabalho, como repositório, branch, tag, pull request ou ambiente.
  • repository: O repositório que executa o fluxo de trabalho, como my-org/my-repo.
  • repository_owner: A organização ou o usuário proprietário do repositório, como my-org.
  • ref: A referência Git que acionou o fluxo de trabalho, como refs/heads/main ou refs/tags/v1.0.0.
  • workflow: A declaração do fluxo de trabalho. Use o valor real da declaração emitida pelo GitHub, como deploy, se essa for a declaração do fluxo de trabalho no seu trabalho.
  • workflow_ref: O caminho do arquivo do fluxo de trabalho e sua referência, como my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main.
  • environment: O nome do ambiente do GitHub, como production, quando o trabalho usa um ambiente.
  • run_id, run_number, run_attempt e job_workflow_ref: Identificadores de execução e de trabalho que podem ajudar em auditorias ou em regras de confiança mais avançadas.

Para ver a lista completa de declarações e os formatos de sujeito, consulte a referência do OpenID Connect do GitHub.

Verifique o token

Antes de configurar a federação de identidades de cargas de trabalho, exporte o token OIDC do GitHub como TOKEN e execute este script no executor do fluxo de trabalho para inspecionar suas declarações:

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 o payload do JWT sem verificar a assinatura do token. Use um decodificador local para tokens de produção e evite colá-los em ferramentas de terceiros. Nunca registre em logs o token OIDC bruto do GitHub nem o token de acesso da OpenAI obtido na troca.

Um token OIDC decodificado do GitHub Actions será semelhante a:

{
  "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"
}

Use o payload decodificado para comparar o token recebido com os valores de emissor, público-alvo e mapeamento configurados na OpenAI. A maioria dos problemas de configuração pode ser identificada nas declarações iss, aud, repository, ref e workflow_ref antes de você trocar o token.

Configuração da federação de identidades de cargas de trabalho

Crie um provedor de identidade de cargas de trabalho na OpenAI para o GitHub Actions e adicione um mapeamento de conta de serviço que corresponda às declarações de fluxo de trabalho do GitHub nas quais você confia.

Configure primeiro o provedor de identidade de cargas de trabalho e depois crie o mapeamento de conta de serviço.

Configure o provedor de identidade de cargas de trabalho

  1. Crie o provedor de identidade de cargas de trabalho. Defina Nome como um valor exclusivo, como github-actions-prod. Use Descrição, com um valor como Production GitHub Actions workflows, para ajudar os administradores a identificar o provedor.

  2. Defina o emissor e o público-alvo. Defina URL do emissor OIDC como https://token.actions.githubusercontent.com. Defina Público-alvo como o público-alvo exato que seu fluxo de trabalho solicita, como your-wif-audience ou https://api.openai.com/v1.

  3. Use a descoberta OIDC do GitHub. Mantenha Usar JWKS enviado para verificação de tokens desativado. A OpenAI usa os metadados de descoberta OIDC e o JWKS do GitHub para verificar o token assinado pelo GitHub.

  4. Adicione transformações de atributos apenas se precisar de atributos de mapeamento derivados. Declarações brutas do GitHub, como repository, ref e workflow, podem ser usadas diretamente nas asserções de mapeamento. Se você criar atributos derivados, o painel aplicará o prefixo openai. automaticamente; por exemplo, insira github_repository com a expressão assertion.repository para criar openai.github_repository. Declarações brutas do token que já começam com openai. são ignoradas para chaves de mapeamento openai., a menos que uma transformação correspondente esteja configurada.

Configure o mapeamento de conta de serviço

  1. Crie um mapeamento de conta de serviço. Defina Nome como um valor exclusivo dentro do provedor de identidade de cargas de trabalho, como github-actions-main-deploy. Use Descrição, com um valor como Production deploy workflow on main, para explicar qual fluxo de trabalho pode usar o mapeamento.

  2. Adicione asserções de correspondência exata de declarações. Adicione uma linha com Chave e Valor para cada declaração do GitHub que deve corresponder. A OpenAI exige que todas as linhas configuradas correspondam antes de emitir um token de acesso. Para um fluxo de trabalho de implantação em produção, use asserções como:

    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"

    Prefira workflow_ref a workflow em mapeamentos privilegiados, pois os administradores geralmente pretendem confiar em um caminho de arquivo de fluxo de trabalho e em uma referência específicos. Os nomes dos fluxos de trabalho podem ser alterados, e vários arquivos de fluxo de trabalho podem ter o mesmo nome.

    Na interface de mapeamento, insira esses dados como linhas de chave/valor, como Chave repository com Valor my-org/my-repo, Chave ref com Valor refs/heads/main e Chave workflow_ref com Valor my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main. Se o trabalho usar um ambiente do GitHub, adicione também Chave environment com Valor production.

    Atenção: Evite mapeamentos amplos demais, como confiar apenas em repository_owner == "my-org", a menos que todos os repositórios no namespace desse proprietário devam poder emitir tokens de acesso da OpenAI.

  3. Escolha o destino na OpenAI. Defina Projeto como o projeto da OpenAI ao qual pertence a conta de serviço de destino. Defina Conta de serviço como a conta de serviço da OpenAI que o fluxo de trabalho do GitHub pode usar, como github-actions-prod-deploy.

  4. Restrinja as permissões da API, se necessário. Selecione as Permissões adequadas, como api.model.request e api.vector_store.read, para restringir ainda mais o acesso dos tokens emitidos a partir desse mapeamento. Deixe as permissões em branco para não adicionar uma restrição de escopo específica de WIF; o token ainda autoriza o acesso como a conta de serviço mapeada.

Uso do token em um fluxo de trabalho

Configure seu cliente do OpenAI SDK para solicitar um token OIDC do GitHub e trocá-lo por um token de acesso emitido pela OpenAI.

O fluxo de trabalho deve conceder a permissão id-token: write e passar as configurações de federação de identidades de cargas de trabalho ao código do SDK. O SDK solicita o token OIDC do GitHub usando as variáveis do ambiente ACTIONS_ID_TOKEN_REQUEST_URL e ACTIONS_ID_TOKEN_REQUEST_TOKEN que o GitHub disponibiliza ao trabalho e, em seguida, usa o token de acesso da OpenAI obtido na troca para autenticar as solicitações à API.

Por exemplo, execute o código do seu aplicativo a partir de um fluxo de trabalho 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

Armazene OPENAI_WIF_AUDIENCE, OPENAI_IDENTITY_PROVIDER_ID e OPENAI_SERVICE_ACCOUNT_ID como variáveis do GitHub Actions. Elas identificam o provedor e a conta de serviço, mas não são credenciais de portador.

Os exemplos a seguir inicializam um cliente da OpenAI com um provedor personalizado de tokens de sujeito. O provedor solicita um token OIDC do GitHub para o público-alvo configurado e o usa como token de sujeito para a federação de identidades de cargas de trabalho.

Autentique-se com um token OIDC do 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áticas recomendadas para o GitHub Actions

  • Use proteções de ambiente para implantações em produção. Exija aprovações ou restrições de branch antes que os fluxos de trabalho possam acessar recursos de produção da OpenAI.
  • Restrinja os mapeamentos por repositório. Sempre que possível, exija correspondência de declarações específicas do repositório, em vez de permitir acesso a partir de todos os repositórios de uma organização.
  • Restrinja os mapeamentos por branch ou fluxo de trabalho. Considere exigir correspondência de declarações como repository, ref, environment ou workflow_ref para limitar a emissão de tokens.
  • Use contas de serviço da OpenAI separadas para CI/CD e cargas de trabalho de produção. Pipelines de build geralmente exigem permissões diferentes das dos aplicativos implantados.
  • Evite conceder acesso a pull requests de forks não confiáveis. Pull requests originados de forks podem executar código controlado por invasores e não devem receber credenciais de produção.
  • Use trocas de tokens de curta duração. Os tokens OIDC do GitHub se destinam à autenticação efêmera e devem ser trocados apenas quando necessário.
  • Audite as mudanças de propriedade dos repositórios. Transferências de repositórios, alterações de nome e mudanças de permissões podem afetar as premissas de segurança dos mapeamentos existentes.
  • Prefira a correspondência exata de declarações. Exija correspondência de declarações como repository, ref e environment, em vez de depender de relações de confiança que abranjam toda a organização.