Resumo

Estamos investigando um problema relatado na autenticação do Kulinaryos. Esta é uma atualização de diagnóstico, não uma conclusão de causa raiz ou um anúncio de recuperação. Ainda precisamos confirmar quais fluxos e usuários foram afetados, quando o problema começou e se ele persiste.

O que confirmamos

O código e a configuração de produção mostram que a API do Kulinaryos, escrita em Go, já concentra o cadastro, a verificação de senhas e a emissão de tokens. As interfaces, porém, não compartilham uma sessão de login única: o aplicativo web usa um cookie de sessão protegido, enquanto CRM e Command Center mantêm seus próprios fluxos e tokens no navegador. Essa diferença aumenta os caminhos que precisam ser examinados, mas, por si só, não comprova a causa do problema relatado.

Na verificação pública de 29 de setembro, as páginas de autenticação responderam e os endpoints de saúde da API estavam disponíveis. Isso confirma alcançabilidade naquele momento, não o sucesso de um login real. Sem um teste autenticado e sem correlação de logs, não é possível afirmar a taxa de falhas, o alcance do incidente ou sua causa.

Investigação em curso

  • Reproduzir o erro em cada interface e registrar horário, resposta e identificador de requisição.
  • Correlacionar logs da borda, da API e do armazenamento de sessões com tentativas de login, renovação e saída.
  • Verificar separadamente credenciais, cookies, renovação de tokens e permissões após a autenticação.
  • Publicar a janela, o impacto, a causa confirmada e a recuperação quando houver evidência suficiente.

Para onde vamos

O objetivo é uma central de login para os produtos da Food Process, com ZITADEL autohospedado no cluster da Food Process como provedor de identidade e um backend Go como camada de integração com as aplicações. O fluxo planejado usa OpenID Connect com Authorization Code e PKCE. O ZITADEL autentica a pessoa e fornece a identidade; o backend Go valida essa identidade, estabelece a sessão da aplicação e aplica as regras de organização e permissão do Kulinaryos. A migração deve preservar contas e acesso de forma controlada, com testes por produto e plano de reversão.

Duas formas de entrar, uma identidade

A central deverá oferecer usuário e senha administrados pelo ZITADEL e login com Google por meio de um provedor externo configurado no ZITADEL. O backend Go não receberá a senha do Google nem precisará armazenar uma segunda senha para o mesmo usuário.

Um identificador local pode ser diferente do email da conta Google: por exemplo, ana@empresa.com no acesso local e ana@gmail.com no Google. Username e email são atributos de entrada e contato, não a chave definitiva da pessoa. O vínculo com a conta existente será feito após a pessoa comprovar controle dessa conta e confirmar a associação. Emails iguais ou diferentes não deverão unir contas automaticamente nem conceder acesso a organizações por coincidência de texto. Depois do vínculo, as duas formas de autenticação deverão apontar para a mesma identidade no ZITADEL e para o mesmo usuário interno no PostgreSQL.

Antes da liberação, verificaremos na versão escolhida do ZITADEL como as duas opções aparecem para contas já vinculadas, além dos casos de email diferente, recuperação de acesso e desvinculação.

O ZITADEL importa para o ecossistema porque reúne políticas de identidade, autenticação multifator e métodos modernos de acesso em um serviço comum. Isso permite que novos produtos usem o mesmo protocolo e que mudanças de segurança sejam aplicadas de maneira consistente. A experiência de login unificada dependerá também da integração de cada aplicação e de uma política de sessão comum; instalar o provedor, isoladamente, não a entrega.

Operar esse serviço no cluster próprio traz responsabilidade direta por disponibilidade, atualizações, proteção das chaves, observabilidade e cópias de segurança testadas. Esses requisitos fazem parte do projeto de migração, não são uma consequência automática da escolha do ZITADEL.

Emails de segurança com Brevo

Escolhemos o Brevo para emails transacionais da Food Process, inclusive links de recuperação de senha. No modelo atual, a API Go é responsável pelos links de recuperação e está preparada para enviá-los por SMTP com conexão criptografada quando o serviço for ativado. À medida que cada conta migrar para a identidade central, o ZITADEL deverá passar a emitir seus próprios emails de verificação e recuperação pelo Brevo: a senha administrada pelo ZITADEL não deve ser redefinida diretamente pelo banco do produto.

A verificação de rede encontrou as portas SMTP 587 e 465 indisponíveis no Droplet; a porta 2525 do Brevo aceitou conexão com STARTTLS e certificado válido. O Brevo documenta essa alternativa. Publicamos os registros de autenticação na zona DNS autoritativa, e o Brevo marcou kulinaryos.com como autenticado e info@kulinaryos.com como remetente verificado. Um teste SMTP originado no host de produção apareceu no log transacional do Brevo como enviado e entregue. A credencial ficou fora do código, no cofre operacional e no Secret do backend. A entrega registrada pelo provedor ainda não comprova a chegada à caixa postal nem o funcionamento do fluxo de recuperação da API; testaremos o link e seu uso único após a promoção da imagem.

Estado atual

As mudanças de base no backend Go e os manifestos de identidade foram integrados aos repositórios. A promoção da nova imagem da API foi mergeada, mas a API de produção ainda executa a imagem anterior: o ArgoCD recebeu a aplicação raiz e não consegue ler o repositório privado sem uma credencial exclusiva de leitura. O ZITADEL não foi instalado e os usuários continuam no fluxo atual. O banco dedicado já usa acesso privado com TLS verificado; seu primeiro backup foi copiado para fora do host, conferido e restaurado isoladamente. O DNS do emissor auth.kulinaryos.com já aponta para o ingresso de produção. O manifesto de identidade permanece fora da sincronização automática até a validação das dependências. O email real de recuperação da API e o login com Google ainda não foram validados.

A investigação continua aberta. Merge de código não equivale à recuperação do acesso. Não há, nesta atualização, causa raiz, impacto quantificado ou data de recuperação confirmados. Atualizaremos este registro quando esses dados forem verificados.