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 Kubernetes

Para usar o Kubernetes como provedor de identidade de carga de trabalho, troque um token projetado de uma conta de serviço do Kubernetes por um token de acesso da OpenAI de curta duração.

Configure o Kubernetes

Este guia pressupõe que a projeção de tokens de contas de serviço esteja habilitada no Kubernetes. Esse recurso está disponível por padrão nas versões recentes do Kubernetes. A federação de identidades de carga de trabalho da OpenAI exige que os tokens projetados de contas de serviço sejam compatíveis com OIDC. A OpenAI não aceita tokens legados de contas de serviço do Kubernetes armazenados em Secrets.

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

kubectl create serviceaccount openai-wif --namespace default

Obtenha o emissor OIDC do cluster Kubernetes com o seguinte comando.

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

Mesmo que você envie o JWKS e a OpenAI não consulte o emissor OIDC para descobrir o JWKS, esse emissor deve corresponder ao configurado no provedor de identidade de carga de trabalho.

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

kubectl get --raw /openid/v1/jwks

Configure o token projetado da conta de serviço com o público esperado pela OpenAI e um prazo de validade adequado à carga de trabalho. A OpenAI valida o emissor, a assinatura, o público e a expiração do token. Neste exemplo, o arquivo do token é montado em /var/run/secrets/tokens/token. O token tem como público https://api.openai.com/v1 e expira após 3600 segundos. Você pode usar outro público, desde que o público do token projetado corresponda ao configurado no provedor de identidade de carga 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 carga de trabalho, decodifique localmente um token projetado de uma conta de serviço e examine suas declarações. Obtenha o token de um pod em execução no qual o arquivo do token projetado esteja montado 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);

Esse comando decodifica o conteúdo do JWT sem verificar a assinatura do token. Para tokens de produção, use um decodificador local e evite colar esses tokens em ferramentas de terceiros.

Depois de decodificado, um token projetado de uma conta de serviço do Kubernetes terá uma estrutura semelhante à do exemplo a seguir.

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

Compare o conteúdo decodificado do token recebido com o emissor, o público e os valores de mapeamento configurados na OpenAI. É possível identificar a maioria dos problemas de configuração nas declarações iss, aud e sub antes de trocar o token.

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

Crie um provedor de identidade de carga de trabalho na OpenAI para o emissor do Kubernetes. Em seguida, adicione um mapeamento de conta de serviço que corresponda aos atributos do token projetado.

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

Configure 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 kubernetes-prod. Em Descrição, insira um texto como Production Kubernetes cluster para ajudar os administradores a identificar o cluster.

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

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

    Observação: Para clusters Kubernetes auto-hospedados, a OpenAI oferece suporte apenas ao modo JWKS local. Envie o JWKS retornado pelo cluster. A OpenAI não consulta o emissor configurado para realizar a descoberta OIDC, mas ainda compara esse emissor com o campo iss do token.

    Se o cluster fizer a rotação das chaves de assinatura das contas de serviço, atualize o JWKS enviado na configuração do provedor de identidade de carga de trabalho. A OpenAI rejeita tokens assinados com chaves ausentes do JWKS configurado. 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. Você pode usar declarações originais do token como sub, aud e iss diretamente nas asserções de mapeamento. Se quiser usar atributos transformados como critérios de correspondência em vez das declarações originais do token, o painel adicionará o prefixo openai. automaticamente. Por exemplo, insira workload_subject com a expressão assertion.sub para criar openai.workload_subject. A OpenAI ignora as declarações originais do token que já começam com openai. ao avaliar chaves de mapeamento com o prefixo openai., a menos que você configure uma transformação correspondente.

Configure o mapeamento de conta de serviço

  1. Crie um mapeamento de conta de serviço. Em Nome, insira um valor exclusivo para esse provedor de identidade de carga de trabalho, como openai-mapping-kubernetes. Em Descrição, insira um texto como Workload Identity Provider Mapping for Kubernetes Workloads para indicar qual carga de trabalho pode usar o mapeamento.

  2. Use o identificador de sujeito da conta de serviço do Kubernetes como critério de correspondência. Em Chave, insira sub. Em Valor, insira system:serviceaccount:default:openai-wif. Para contas de serviço do Kubernetes, o identificador de sujeito tem o formato system:serviceaccount:<namespace>:<service-account-name>.

  3. Escolha a conta de 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 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 conta de serviço para esse mapeamento em vez de reutilizar uma existente.

  4. Restrinja as permissões da API, se necessário. Em Permissões, selecione as permissões adequadas, como api.model.request e api.vector_store.read, para restringir ainda mais o acesso concedido pelos tokens emitidos com base nesse mapeamento. Deixe as permissões em branco para evitar uma restrição de escopo específica da federação de identidades de carga de trabalho. O token continua autorizando o acesso com as permissões da conta de serviço mapeada.

Use o token no código

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

Use o caminho do arquivo montado, como /var/run/secrets/tokens/token, como origem do token de sujeito para o provedor de federação de identidades de carga 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 as requisições à API.

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

Autenticação com um token projetado de uma 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);

Boas práticas para Kubernetes

  • Use um emissor OIDC estável. A URL do emissor deve corresponder à declaração iss do token projetado da conta de serviço. É recomendável manter essa URL estável durante atualizações e operações de manutenção do cluster.
  • Proteja as chaves de assinatura com cuidado. Qualquer pessoa com acesso às chaves de assinatura das contas de serviço do cluster pode emitir tokens que a OpenAI poderá aceitar.
  • Use contas de serviço dedicadas às integrações com a OpenAI. Evite reutilizar contas de serviço que também dão acesso a infraestrutura ou aplicativos sem relação com essas integrações.
  • Mantenha o JWKS enviado atualizado. No modo JWKS local, a OpenAI usa o JWKS configurado para validar tokens de identidade de carga de trabalho. Atualize o provedor de identidade de carga de trabalho antes de passar a usar novas chaves de assinatura.
  • Mantenha as declarações personalizadas simples. Prefira usar como critérios de correspondência declarações padrão, como sub e aud, ou atributos transformados derivados diretamente dessas declarações.
  • Leve em conta quem controla cada namespace no seu modelo de segurança. Se os administradores de namespaces puderem criar contas de serviço, verifique se o escopo dos mapeamentos está delimitado corretamente para evitar elevações de privilégio indesejadas.
  • Monitore as 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 carga de trabalho pode causar falhas na troca de tokens.