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
Theme

Como configurar a federação de identidades de carga de trabalho para o GitHub Actions

Para usar o GitHub Actions como provedor de identidade de carga de trabalho, troque um token OIDC emitido pelo GitHub por um token de acesso de curta duração da OpenAI. Assim, os fluxos de trabalho podem se autenticar na API da OpenAI sem armazenar uma chave de API de longa duração nos segredos do GitHub.

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

Configurar o GitHub Actions

Conceda ao fluxo de trabalho ou ao job a permissão necessária para solicitar um token OIDC do GitHub:

permissions:
  id-token: write
  contents: read

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

Solicite o token com o valor exato do público-alvo configurado no provedor de identidade de carga de trabalho da OpenAI. Ações personalizadas em JavaScript podem chamar core.getIDToken("your-wif-audience"). Em etapas de shell, você pode solicitar o token diretamente pela URL que o GitHub fornece para solicitações OIDC. Se o valor do público-alvo contiver caracteres reservados em URLs, como em https://api.openai.com/v1, aplique a codificação de URL ao valor antes de acrescentá-lo à URL da 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

Entre as principais declarações do token OIDC do GitHub estão:

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

Para consultar a lista completa de declarações e os formatos de identificação do sujeito, veja a referência do OpenID Connect do GitHub.

Verificar o token

Antes de configurar a federação de identidades de carga de trabalho, exporte o token OIDC do GitHub na variável TOKEN. Em seguida, execute este script no executor do fluxo de trabalho para inspecionar as declarações do 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);

Esse comando decodifica o conteúdo 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 nos logs o token OIDC original do GitHub nem o token de acesso da OpenAI obtido na troca.

Veja um exemplo do conteúdo decodificado de um token OIDC do GitHub Actions:

{
  "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 conteúdo decodificado para comparar o emissor, o público-alvo e os valores de mapeamento do token recebido com os valores configurados na OpenAI. Antes de trocar o token, você pode identificar a maioria dos problemas de configuração nas declarações iss, aud, repository, ref e workflow_ref.

Configurar a federação de identidades de carga de trabalho

Crie na OpenAI um provedor de identidade de carga de trabalho para o GitHub Actions. Em seguida, adicione um mapeamento de conta de serviço que corresponda às declarações de fluxos de trabalho do GitHub em que você confia.

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

Configurar o provedor de identidade de carga de trabalho

  1. Crie o provedor de identidade de carga de trabalho. Em Nome, insira um valor exclusivo, como github-actions-prod. Em Descrição, insira um texto como Production GitHub Actions workflows para ajudar os administradores a identificar o provedor.

  2. Defina o emissor e o público-alvo. Em URL do emissor OIDC, insira https://token.actions.githubusercontent.com. Em Público-alvo, insira exatamente o valor solicitado pelo fluxo de trabalho, como your-wif-audience ou https://api.openai.com/v1.

  3. Use a descoberta OIDC do GitHub. Deixe desativada a opção Usar o JWKS enviado para verificar o token. 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 somente se precisar de atributos derivados para o mapeamento. Você pode usar declarações originais do GitHub, como repository, ref e workflow, diretamente nas condições do mapeamento. Quando você cria atributos derivados, o painel aplica automaticamente o prefixo openai.. Por exemplo, insira github_repository com a expressão assertion.repository para criar openai.github_repository. O mapeamento ignora declarações originais do token que já começam com openai. ao avaliar chaves com o prefixo openai., a menos que você configure uma transformação correspondente.

Configurar o mapeamento da conta de serviço

  1. Crie um mapeamento de conta de serviço. Em Nome, insira um valor exclusivo dentro do provedor de identidade de carga de trabalho, como github-actions-main-deploy. Em Descrição, insira um texto como Production deploy workflow on main para indicar qual fluxo de trabalho pode usar o mapeamento.

  2. Adicione condições que exijam correspondência exata das declarações. Adicione uma linha com Chave e Valor para cada declaração do GitHub que precisa corresponder ao valor configurado. A OpenAI só emite um token de acesso quando todas as linhas configuradas correspondem às declarações do token. Para um fluxo de trabalho de implantação em produção, use condições como estas:

    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"

    Em mapeamentos privilegiados, prefira workflow_ref a workflow, pois os administradores geralmente querem confiar em um arquivo de fluxo de trabalho com um caminho e uma referência específicos. Os nomes dos fluxos de trabalho podem mudar, e vários arquivos de fluxo de trabalho podem usar o mesmo nome.

    Na interface de mapeamento, insira cada par de chave e valor em uma linha. Por exemplo, use a Chave repository com o Valor my-org/my-repo, a Chave ref com o Valor refs/heads/main e a Chave workflow_ref com o Valor my-org/my-repo/.github/workflows/deploy.yml@refs/heads/main. Se o job usar um ambiente do GitHub, adicione também a Chave environment com o Valor production.

    Cuidado: Evite mapeamentos muito amplos, como confiar apenas em repository_owner == "my-org", a menos que todos os repositórios desse proprietário devam poder gerar tokens de acesso da OpenAI.

  3. Escolha o destino na OpenAI. Em Projeto, selecione o projeto da OpenAI ao qual pertence a conta de serviço de destino. Em Conta de serviço, selecione 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. Em Permissões, selecione permissões adequadas, como api.model.request e api.vector_store.read, para restringir ainda mais o acesso concedido pelos tokens emitidos com esse mapeamento. Deixe o campo de permissões em branco se não quiser acrescentar uma restrição de escopo específica da federação de identidades de carga de trabalho. O token continua autorizando o acesso com a identidade da conta de serviço mapeada.

Usar o token em um fluxo de trabalho

Configure o cliente do SDK da OpenAI 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 da federação de identidades de carga de trabalho para o código que usa o SDK. O SDK solicita o token OIDC do GitHub usando as variáveis de ambiente ACTIONS_ID_TOKEN_REQUEST_URL e ACTIONS_ID_TOKEN_REQUEST_TOKEN que o GitHub disponibiliza ao job. 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 em 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 do tipo bearer.

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 na federação de identidades de carga de trabalho.

Autenticar 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);

Boas práticas para o GitHub Actions

  • Use regras de proteção de ambiente nas implantações em produção. Exija aprovações ou aplique restrições de branch antes de permitir que os fluxos de trabalho acessem recursos de produção da OpenAI.
  • Restrinja os mapeamentos por repositório. Sempre que possível, exija correspondência com declarações específicas do repositório em vez de permitir o acesso de todos os repositórios da organização.
  • Restrinja os mapeamentos por branch ou fluxo de trabalho. Para limitar a emissão de tokens, considere exigir correspondência com declarações como repository, ref, environment ou workflow_ref.
  • Use contas de serviço distintas da OpenAI para CI/CD e para cargas de trabalho de produção. Pipelines de build geralmente exigem permissões diferentes das que os aplicativos usam após a implantação.
  • Evite conceder acesso a pull requests de forks não confiáveis. Pull requests de forks podem executar código controlado por invasores e não devem receber credenciais de produção.
  • Use tokens de curta duração nas trocas. Os tokens OIDC do GitHub se destinam à autenticação temporária e só devem ser trocados quando necessário.
  • Audite mudanças de titularidade 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 das declarações. Exija correspondência com declarações como repository, ref e environment em vez de depender de relações de confiança que abranjam toda a organização.