Autenticação upstream sem chave para gateways AI API: um padrão de federação de identidade de carga de trabalho

Os trabalhadores do gateway de produção não devem carregar chaves upstream API de longa duração quando o próprio provedor puder autenticar a carga de trabalho. O padrão mais seguro é trocar uma identidade existente de nuvem, Kubernetes, CI ou SPIFFE por uma credencial de provedor de curta duração, armazenar em cache essa credencial corretamente e restringi-la ao menor limite de autorização útil.

A parte difícil não é a troca de tokens. Ele está lidando com suporte irregular de provedores, atualizações simultâneas, mapeamento de identidade, exceções de plano de controle, interrupções e migração sem criar um substituto oculto para uma chave compartilhada amplamente privilegiada.

Comece com recursos de autenticação, não com uma configuração global sem chave

Fato: O suporte à autenticação difere de acordo com o provedor e a operação. OpenAI e Anthropic oferecem suporte à federação de identidade de carga de trabalho para API cargas de trabalho. O Azure OpenAI dá suporte ao Microsoft Entra ID e identidades gerenciadas. Google O Cloud oferece suporte a contas de serviço anexadas, credenciais padrão do aplicativo e federação de identidade de carga de trabalho para cargas de trabalho externas. No entanto, a inferência de tempo de execução e as APIs administrativas não aceitam necessariamente os mesmos tipos de credenciais.

Por exemplo, OpenAI tokens de identidade de carga de trabalho atualmente não podem chamar pontos de extremidade Admin API. Portanto, um gateway não pode representar com segurança a autenticação como um campo no nível do provedor, como auth_mode: federated.

Recomendação: Crie uma matriz de recursos codificada por conta do provedor, família de endpoints, ambiente e classe de operação:

Armazene esta matriz como configuração versionada. A admissão de rota deverá rejeitar uma operação quando sua identidade configurada não puder satisfazer a capacidade de autenticação necessária. Isso pertence a um plano de controle AI API para equipes de desenvolvedores, e não a variáveis de ambiente não documentadas em trabalhadores individuais.

Coloque um agente de credenciais entre os adaptadores de roteamento e de provedor

Os adaptadores do provedor não devem buscar credenciais de metadados, construir asserções ou gerenciar a atualização do token de forma independente. Apresente um corretor de credenciais com uma interface estreita:

Credential acquire(CredentialRequest request)

CredentialRequest {
  provider_account_id
  workload_identity_id
  operation_class
  target_service_account
  audience
  scopes
}

Credential {
  value
  expires_at
  authorization_context
  provenance
}

O valor da credencial é confidencial e deve permanecer na memória ou em um cache temporário aprovado. O contexto de autorização registra o projeto do provedor, a conta de serviço, os escopos, as funções ou as restrições de implantação representadas pelo token. A procedência identifica como foi adquirido, como oidc_exchange, managed_identity, adc ou break_glass.

Este contrato mantém o roteamento neutro em termos de provedor, preservando os detalhes necessários para verificações de autorização e telemetria. Ele também evita que um gateway multimodelo API para equipes trate cada token de portador como intercambiável.

Use adaptadores de aquisição específicos do provedor

Cada adaptador de aquisição deve executar apenas as etapas exigidas pelo seu provedor:

• Obtenha uma asserção externa da fonte de identidade local, como um token de conta de serviço projetado do Kubernetes, serviço de metadados de nuvem ou carga de trabalho SPIFFE API.
• Solicite o público exato esperado pelo provedor ou pela regra de federação configurada.
• Troque a asserção quando o provedor exigir a troca de token.
• Retorne o resultado credencial e tempo de expiração oficial.
• Classifique as falhas como erros de identidade local, troca, autorização, configuração ou disponibilidade do provedor.

O endpoint compatível com OpenAI da Vertex AI é um exemplo útil de separação: um aplicativo pode obter um token de acesso Google por meio de credenciais padrão do aplicativo e fornecer esse token como a credencial do OpenAI cliente. O adaptador de protocolo permanece OpenAIcompatível, enquanto a aquisição de credenciais permanece Googleespecífica.

Tornar o cache de token ciente da autorização

Fato: As credenciais federadas têm vida curta. OpenAI os tokens de acesso à identidade da carga de trabalho não duram mais do que uma hora, não podem sobreviver ao token de assunto externo ou ao certificado verificado e são emitidos sem tokens de atualização. A carga de trabalho deve repetir a troca antes da expiração.

Uma chave de cache deve incluir todas as dimensões que podem alterar a autoridade resultante:

cache_key = hash(
  provider_account_id,
  workload_identity_id,
  target_service_account,
  audience,
  normalized_scopes,
  operation_class
)

A omissão da conta, público ou escopos de destino pode fazer com que um trabalhador reutilize um token válido no contexto de autorização errado. Isso é mais perigoso do que uma falha no cache.

Atualize antes de expirar usando uma margem de segurança e jitter aleatório. Uma política prática é:

refresh_at = expires_at
             - max(configured_margin, token_lifetime * 0.10)
             - random_jitter

A margem exata deve considerar a distorção do relógio, a latência da troca, o tempo de repetição e a solicitação mais longa esperada. Não atualize apenas em um cronômetro fixo separado de expires_at.

Evite tempestades de troca com atualização de voo único

Quando muitas solicitações encontram o mesmo token quase expirado, apenas uma execução deve realizar a troca. Outros chamadores devem continuar usando a credencial existente enquanto ela permanece dentro da janela permitida ou aguardar brevemente pelo resultado da atualização compartilhada.

Use um bloqueio de voo único por chave de cache. Em uma implantação de vários processos ou de vários nós, decida se cada trabalhador pode manter seu próprio cache ou se a coordenação de atualização deve ser distribuída. Um cache local é mais simples, mas aumenta o volume de troca. Um cache distribuído reduz as trocas, mas expande o limite do token sensível e requer transporte criptografado, controle de acesso rigoroso e remoção cuidadosa.

Recomendação: Prefira caches em processo, a menos que os limites do provedor ou o tamanho da frota demonstrem a necessidade de um serviço de token compartilhado. Coordene primeiro as atualizações dentro de cada processo e depois meça o volume de troca.

Vincular identidades a declarações exatas de carga de trabalho

A federação transfere a confiança de uma chave armazenada para declarações de identidade. Um mapeamento permissivo pode, portanto, ser tão perigoso quanto uma credencial compartilhada vazada.

Valide o emissor e o público-alvo e vincule o mapeamento a declarações imutáveis ou rigidamente controladas. Para Kubernetes, inclua o namespace e a conta de serviço em vez de confiar em qualquer carga de trabalho no cluster. Para CI, restrinja o repositório, o fluxo de trabalho, o ambiente e a ramificação protegida ou o contexto de implantação. Para identidades de nuvem, mapeie um principal de carga de trabalho específico em vez de um locatário ou organização inteira.

Crie contas de serviço upstream separadas ou identidades gerenciadas para produção, preparação, trabalhos em segundo plano e automação administrativa. Restrinja cada identidade aos modelos, projetos, espaços de trabalho, implantações e API operações necessárias.

Fato: OpenAI pode restringir mapeamentos de identidade de carga de trabalho com API permissões. Anthropic associa credenciais trocadas a uma conta de serviço e avisa que a federação é tão segura quanto a configuração de identidade upstream. Da mesma forma, as identidades gerenciadas e o Cloud IAM dependem de atribuições de funções com escopo correto.

Separar credenciais de tempo de execução das credenciais administrativas

Um trabalhador de inferência nunca deve herdar um token de administrador da organização simplesmente porque alguma tarefa do plano de controle ainda precisa de um. Divida o sistema em dois limites de segurança:

• Plano de tempo de execução: Processa solicitações de modelo e recebe apenas credenciais federadas ou gerenciadas com escopo para inferência.
• Plano de controle: Executa administração de projeto, espaço de trabalho, faturamento ou conta de serviço por meio de trabalhos isolados com credenciais armazenadas separadamente e controles de aprovação mais fortes.

As credenciais administrativas não devem ter caminho para variáveis de ambiente de tempo de execução, especificações de pod, pacotes de depuração ou caches de token. Registre seu uso no mesmo sistema de auditoria somente anexado usado para alterações de configuração.

Falha fechada sem improvisar a recuperação

Recomendação: Não substitua automaticamente uma troca de federação com falha por uma chave estática compartilhada. O substituto automático pode ignorar um mapeamento revogado, ocultar um público incorreto ou restaurar o acesso que um administrador de identidade removeu intencionalmente.

Retorne um erro de autenticação upstream classificado, interrompa o envio para a conta do provedor afetado e permita que a política de roteamento normal selecione outro provedor somente quando essa alternativa for permitida para o locatário e a carga de trabalho. O substituto de modelo e o substituto de credencial são decisões diferentes.

Uma chave de segurança ainda pode ser justificada para interrupções graves do provedor de identidade. Mantenha-o desativado ou inacessível durante a operação normal. A ativação deve exigir aprovação autenticada, ter vencimento fixo, restringir a conta e as operações do provedor afetado e alertar sobre cada solicitação feita com ele. Sua procedência deve aparecer na telemetria da solicitação.

Migrar um pool de roteamento por vez

1. Tempo de execução do inventário e credenciais administrativas. Identifique quais processos podem ler cada um.
2. Crie uma identidade de carga de trabalho dedicada e uma conta de serviço do provedor com escopo restrito.
3. Configure mapeamentos exatos de emissor, público, assunto e permissão.
4. Adicione uma verificação de simulação que adquire um token e chama um endpoint permitido de baixo impacto.
5. Canary um pequeno pool de roteamento usando apenas federação. Não deixe o substituto automático de chave ativado durante o teste.
6. Compare falhas de autenticação, latência de troca, idade do token e resultados de autorização do provedor com o caminho existente.
7. Aumente o tráfego gradualmente e observe pelo menos um ciclo completo de atualização do token.
8. Remova a chave antiga do acesso ao tempo de execução e revogue-a após o período de observação definido.

Repita esse processo por conta do provedor e ambiente. Uma transição global torna difícil distinguir um erro de mapeamento de identidade de um comportamento de token específico do provedor.

Instrumente e teste os modos de falha

Registre a latência de troca de token, tentativas de atualização, falhas de atualização, idade da credencial, emissor, principal mapeado, conta do provedor, classe de operação e categoria de erro de autenticação. Nunca registre tokens de acesso, asserções externas, segredos do cliente ou cabeçalhos de autorização completos.

Antes que a federação se torne o único caminho de produção, teste:

• Desequilíbrio de relógio entre trabalhadores, provedores de identidade e serviços de token do provedor.
• Indisponibilidade de endpoint de identidade de carga de trabalho ou servidor de metadados.
• Afirmações expiradas e públicos incorretos.
• Remoção de função e desativação de regras de federação.
• Limitação de troca de token e provedor temporário erros.
• Atualização simultânea sob tráfego de pico.
• Rotação da chave de assinatura enquanto os tokens antigos permanecem válidos.

Para rotação do emissor OIDC, publique chaves de assinatura antigas e novas com sobreposição suficiente para caches de verificador e tokens emitidos. OpenAI documenta armazenamento em cache de 600 segundos para descoberta e dados JWKS remotos, com uma atualização JWKS quando um token faz referência a um ID de chave desconhecido. Não presuma que todos os verificadores se comportam de forma idêntica; teste a rotação com canários ativos.

Adote a autenticação de tempo de execução sem chave como uma migração limitada

O objetivo não é afirmar que o gateway não contém segredos. O objetivo é remover chaves de provedor de longa duração de trabalhadores de tempo de execução de alto volume e confinar credenciais administrativas inevitáveis a um limite menor do plano de controle.

Comece com a matriz de capacidade, faça a intermediação de credenciais por meio de uma interface, armazene em cache por contexto de autorização, use mapeamentos de identidade exatos e feche com falha em caso de erros de troca. Conclua a migração somente depois de observar testes bem-sucedidos de atualização, revogação, interrupção e rotação de chave de assinatura. Isso produz um caminho de tempo de execução sem chave cuja disponibilidade e comportamento de autorização são compreendidos em vez de assumidos.

Leitura relacionada

• verificando as credenciais do provedor antes de rotear o tráfego de produção