Pular para conteúdo

0033 — Dois tokens de serviço para o central, um por escopo de rota

Status: Aprovado · Responsável: Gustavo Madruga · Atualizado em: 2026-09-14 · Decidido em: 2026-09-14

Contexto

A norma de segurança da casa nomeia o token pelo destino e pede um token por app chamado (Segurança, Segredos). O central aceita dois tokens de serviço de chamadores da integração:

  • CENTRAL_API_TOKEN, que todos os integrador-servers usam para /api/integrador/** (heartbeat do integrador-client, decisão 0028);
  • o shared secret do integrador (CENTRAL_INTEGRATOR_TOKEN, lido também como AUTH_INTEGRATOR_TOKEN pelo fallback do rename), que abre /api/admin/** para o sync de senhas pAbast.

A 0028 separou os dois de propósito, e a norma nova torna a separação uma exceção a declarar.

Decisão

O central mantém os dois tokens, cada um preso ao seu filtro e ao seu escopo de rota. O IntegradorAuthFilter aceita só o CENTRAL_API_TOKEN, e só em /api/integrador/**. O AdminAuthFilter aceita o shared secret do integrador em /api/admin/** e na rota de teste do GlitchTip (decisão 0032). Aqui a unidade do token é o escopo de rota, não o app chamado.

Consequências

  • O CENTRAL_API_TOKEN fica em todas as instalações de integrador-server. Com um token só, cada uma delas ganharia o CRUD admin do central.
  • A rotação tem dois alvos: grep CENTRAL_API_TOKEN não acha o shared secret do integrador. Os dois estão na tabela de variáveis de ambiente do README.
  • Os dois nomes seguem o prefixo do destino (CENTRAL_); o AUTH_* é só o fallback do rename (decisão 0020).
  • A norma de segurança da casa registra a exceção nominal, com dono (Segurança, Segredos); esta decisão guarda o porquê.

Alternativas consideradas

  • Unificar no CENTRAL_API_TOKEN: descartado. Daria /api/admin/** a todo integrador-server, o que a 0028 já tinha rejeitado, e exigiria mudança coordenada no integrador e nos envs do Coolify.