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 Kubernetes

Use o Kubernetes como provedor de identidade de cargas de trabalho, trocando um token projetado de conta de serviço do Kubernetes por um token de acesso da OpenAI de curta duração.

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

Configuração do Kubernetes

Este guia pressupõe que a projeção de tokens de contas de serviço do Kubernetes esteja habilitada, um recurso disponível por padrão nas versões modernas do Kubernetes. A federação de identidades de cargas de trabalho da OpenAI exige tokens projetados de contas de serviço compatíveis com OIDC. Tokens legados de contas de serviço do Kubernetes armazenados em Secrets não são compatíveis.

Use uma ServiceAccount do Kubernetes para a carga de trabalho que precisa chamar a API da OpenAI. Se você ainda não tiver uma, crie-a:

kubectl create serviceaccount openai-wif --namespace default

Obtenha o emissor OIDC do seu cluster Kubernetes:

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

Mesmo que você envie o JWKS e a OpenAI não realize a descoberta de JWKS no emissor OIDC, esse emissor deve corresponder ao emissor configurado no provedor de identidade de cargas de trabalho.

Obtenha o JWKS do cluster e salve o conjunto de chaves retornado. Você precisará dele ao configurar o provedor de identidade de cargas de trabalho:

kubectl get --raw /openid/v1/jwks

Configure o token projetado de conta de serviço com o público-alvo esperado pela OpenAI e um prazo de expiração adequado à sua carga de trabalho. A OpenAI valida o emissor, a assinatura, o público-alvo e a expiração do token. Neste exemplo, o arquivo de token é montado em /var/run/secrets/tokens/token, usa o público-alvo https://api.openai.com/v1 e expira após 3600 segundos. Você pode usar outro público-alvo, desde que o público-alvo do token projetado corresponda ao público-alvo do provedor de identidade de cargas de trabalho da 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

Verifique o token

Antes de configurar a federação de identidades de cargas de trabalho, decodifique localmente um token projetado de conta de serviço de exemplo e inspecione suas declarações. Em um pod em execução com o token projetado montado, obtenha o token e exporte-o como TOKEN:

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

Em seguida, execute 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 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.

Um token projetado de conta de serviço do Kubernetes decodificado terá uma aparência semelhante a esta:

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

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 e sub antes de 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 emissor do Kubernetes e, em seguida, adicione um mapeamento de conta de serviço que corresponda aos atributos do token projetado.

Primeiro, configure o provedor de identidade de cargas de trabalho. 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 único, como kubernetes-prod. Use Descrição, por exemplo, Production Kubernetes cluster, para ajudar os administradores a identificar o cluster.

  2. Defina o emissor e o público-alvo. Defina URL do emissor OIDC como o emissor retornado por kubectl get --raw /.well-known/openid-configuration | jq -r .issuer. Esse valor deve corresponder à declaração iss no token projetado. Defina Público-alvo como a mesma string opaca de público-alvo configurada no volume do token projetado de conta de serviço. Neste exemplo, esse valor é https://api.openai.com/v1.

  3. Envie o JWKS do Kubernetes. Habilite Usar JWKS enviado para verificação de tokens e defina JSON do JWKS como a saída de kubectl get --raw /openid/v1/jwks. A OpenAI usa esse conjunto de chaves públicas para verificar tokens projetados de contas de serviço do Kubernetes. Envie o conjunto completo de chaves, incluindo o campo keys que o contém.

    Observação: Para clusters Kubernetes hospedados em infraestrutura própria, a OpenAI oferece suporte apenas ao modo JWKS local. Envie o JWKS retornado pelo seu cluster; a OpenAI não realiza a descoberta OIDC no emissor configurado. A OpenAI ainda compara o emissor configurado com o campo iss do token.

    Se o seu cluster fizer a rotação das chaves de assinatura de contas de serviço, atualize o JWKS enviado na configuração do provedor de identidade de cargas de trabalho. Tokens assinados por chaves que não estejam presentes no JWKS configurado são rejeitados. Se o JWKS contiver várias chaves públicas ativas, inclua o array keys completo.

  4. Adicione transformações de atributos somente se precisar de atributos derivados para o mapeamento. Declarações brutas do token, como sub, aud e iss, podem ser usadas diretamente nas asserções de mapeamento. Se você pretende verificar a correspondência com atributos transformados em vez de declarações brutas do token, o painel aplica o prefixo openai. automaticamente; por exemplo, insira workload_subject com a expressão assertion.sub para criar openai.workload_subject. 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 único dentro do provedor de identidade de cargas de trabalho, como openai-mapping-kubernetes. Use Descrição, por exemplo, Workload Identity Provider Mapping for Kubernetes Workloads, para explicar qual carga de trabalho pode usar o mapeamento.

  2. Configure a correspondência com o sujeito da conta de serviço do Kubernetes. Defina Chave como sub e Valor como system:serviceaccount:default:openai-wif. Para contas de serviço do Kubernetes, o formato do sujeito é system:serviceaccount:<namespace>:<service-account-name>.

  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 a carga de trabalho do Kubernetes pode usar, como kubernetes-prod-openai-wif. Marque Create a new service account in this project se quiser criar uma nova conta de serviço para esse mapeamento em vez de reutilizar uma existente.

  4. Restrinja as permissões da API, se necessário. Selecione Permissões apropriadas, como api.model.request e api.vector_store.read, para restringir ainda mais os tokens de acesso 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 continua autorizando o acesso como a conta de serviço mapeada.

Uso do token no código

Configure seu cliente do OpenAI SDK para ler o token projetado do Kubernetes e trocá-lo por um token de acesso emitido pela OpenAI.

Use o caminho do token montado, como /var/run/secrets/tokens/token, como a origem do token do sujeito para o provedor de federação de identidades de cargas de trabalho do SDK. O SDK troca esse token do Kubernetes por um token de acesso emitido pela OpenAI e usa o token da OpenAI para autenticar solicitações à API.

Os exemplos a seguir inicializam um cliente da OpenAI com um provedor personalizado de tokens do sujeito. O provedor lê o token projetado de conta de serviço do Kubernetes no caminho do arquivo montado e o usa como token do sujeito para a federação de identidades de cargas de trabalho.

Autentique-se com um token projetado de conta de serviço do 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);

Práticas recomendadas para Kubernetes

  • Use um emissor OIDC estável. A URL do emissor deve corresponder à declaração iss do token projetado de conta de serviço e deve permanecer estável durante atualizações do cluster e operações de manutenção.
  • Proteja cuidadosamente as chaves de assinatura. Qualquer pessoa com acesso às chaves de assinatura de contas de serviço do cluster pode emitir tokens que podem ser aceitos pela OpenAI.
  • Use contas de serviço dedicadas para integrações com a OpenAI. Evite reutilizar contas de serviço que também sejam usadas para acessar infraestruturas ou aplicativos sem relação com essas integrações.
  • Mantenha o JWKS enviado atualizado. A OpenAI usa o JWKS configurado para validar tokens de identidade de cargas de trabalho no modo JWKS local. Por isso, atualize o provedor de identidade de cargas de trabalho antes de fazer a rotação para novas chaves de assinatura.
  • Minimize a complexidade das declarações personalizadas. Prefira verificar a correspondência com declarações padrão, como sub e aud, ou com atributos transformados derivados diretamente dessas declarações.
  • Considere o controle sobre namespaces como parte do seu modelo de segurança. Se os administradores de namespaces puderem criar contas de serviço, garanta que os mapeamentos tenham escopos adequados para evitar a elevação não intencional de privilégios.
  • Monitore alterações no emissor e nas chaves de assinatura. Fazer a rotação das chaves de assinatura sem atualizar o JWKS do provedor de identidade de cargas de trabalho pode causar falhas na troca de tokens.