Riepilogo

Stiamo esaminando un problema segnalato nell'autenticazione di Kulinaryos. Questo è un aggiornamento diagnostico, non una conclusione sulla causa principale né un annuncio di ripristino. Dobbiamo ancora confermare quali flussi e utenti siano stati coinvolti, quando sia iniziato il problema e se sia ancora presente.

Cosa abbiamo verificato

Il codice e la configurazione di produzione mostrano che l'API Kulinaryos, scritta in Go, gestisce già registrazione, verifica delle password ed emissione dei token. Le interfacce, però, non condividono una sola sessione di accesso: l'applicazione web usa un cookie di sessione protetto, mentre CRM e Command Center mantengono flussi e token propri nel browser. Questa differenza amplia i percorsi da esaminare, ma non dimostra di per sé la causa del problema segnalato.

Nella verifica pubblica del 29 settembre, le pagine di autenticazione hanno risposto e gli endpoint di salute dell'API erano disponibili. Questo dimostra la raggiungibilità in quel momento, non il buon esito di un accesso reale. Senza una prova autenticata e la correlazione dei log, non possiamo stabilire tasso di errore, portata o causa dell'incidente.

Indagine in corso

  • Riprodurre l'errore in ogni interfaccia, registrando ora, risposta e identificativo della richiesta.
  • Correlare i log della rete perimetrale, dell'API e dell'archivio delle sessioni con accessi, rinnovi e uscite.
  • Verificare separatamente credenziali, cookie, rinnovo dei token e permessi dopo l'autenticazione.
  • Pubblicare finestra temporale, impatto, causa confermata e ripristino quando le prove saranno sufficienti.

Direzione prevista

L'obiettivo è un accesso centrale per i prodotti Food Process, con ZITADEL ospitato nel cluster Food Process come provider di identità e un backend Go come livello di integrazione con le applicazioni. Il flusso previsto usa OpenID Connect Authorization Code con PKCE. ZITADEL autentica la persona e fornisce l'identità; il backend Go la convalida, crea la sessione applicativa e applica le regole di organizzazione e autorizzazione di Kulinaryos. La migrazione dovrà preservare account e accessi con verifiche controllate per ciascun prodotto e un piano di rollback.

Due modi per accedere, una sola identità

L'accesso centrale dovrà offrire nome utente e password gestiti da ZITADEL e accesso con Google tramite un provider esterno configurato in ZITADEL. Il backend Go non riceverà la password Google né dovrà conservare una seconda password per lo stesso utente.

Un identificativo locale può essere diverso dall'email dell'account Google: per esempio, ana@empresa.com per l'accesso locale e ana@gmail.com su Google. Nome utente ed email sono attributi di accesso e contatto, non la chiave definitiva della persona. Il collegamento a un account esistente richiederà la prova di controllo di quell'account e una conferma esplicita. Email uguali o diverse non dovranno unire automaticamente gli account né concedere accesso alle organizzazioni solo perché il testo coincide. Dopo il collegamento, entrambi i metodi dovranno corrispondere alla stessa identità ZITADEL e allo stesso utente interno in PostgreSQL.

Prima del rilascio, verificheremo come la versione scelta di ZITADEL presenta entrambe le opzioni agli account già collegati e testeremo email diverse, recupero dell'accesso e scollegamento.

ZITADEL è importante per l'ecosistema perché riunisce criteri di identità, autenticazione a più fattori e metodi moderni di accesso in un servizio condiviso. I nuovi prodotti potranno usare lo stesso protocollo e le modifiche di sicurezza potranno essere applicate in modo coerente. Un'esperienza di accesso unificata richiederà anche l'integrazione di ogni applicazione e una politica comune per le sessioni: installare il provider, da solo, non basta.

Gestire il servizio nel nostro cluster comporta responsabilità dirette per disponibilità, aggiornamenti, protezione delle chiavi, osservabilità e backup verificati. Questi sono requisiti del progetto di migrazione, non risultati automatici della scelta di ZITADEL.

Email di sicurezza con Brevo

Abbiamo scelto Brevo per le email transazionali di Food Process, compresi i link di recupero della password. Nel modello attuale, l'API Go gestisce i link di recupero ed è predisposta per inviarli tramite SMTP cifrato quando il servizio sarà attivato. Quando ciascun account passerà all'identità centrale, ZITADEL dovrà inviare tramite Brevo i propri messaggi di verifica e recupero: una password gestita da ZITADEL non va reimpostata direttamente nel database del prodotto.

La verifica della rete ha rilevato che le porte SMTP 587 e 465 non sono disponibili dal Droplet; la porta 2525 di Brevo ha accettato una connessione STARTTLS con certificato valido. Brevo documenta questa alternativa. Abbiamo pubblicato i record di autenticazione nella zona DNS autoritativa: Brevo segnala kulinaryos.com come autenticato e info@kulinaryos.com come mittente verificato. Un test SMTP dal server di produzione risulta inviato e consegnato nel log transazionale di Brevo. La credenziale resta fuori dal codice, nel vault operativo e nel Secret del backend. L'evento di consegna del provider non dimostra ancora l'arrivo nella casella né il funzionamento del recupero password nell'API; proveremo il link e il suo utilizzo unico dopo la promozione dell'immagine.

Stato attuale

La promozione della nuova immagine dell'API è stata integrata, ma la produzione usa ancora l'immagine precedente: ArgoCD ha l'applicazione radice e non può leggere il repository privato senza una credenziale dedicata di sola lettura. ZITADEL non è stato installato e gli utenti restano nel flusso di accesso attuale. Il database dedicato ora usa l'accesso privato con TLS verificato; il primo backup è stato copiato fuori dal server, controllato e ripristinato in isolamento. Il DNS dell'issuer auth.kulinaryos.com punta all'ingresso di produzione. Il manifesto di identità resta fuori dalla riconciliazione automatica finché le dipendenze non saranno convalidate. L'email reale di recupero password dell'API e l'accesso con Google non sono ancora stati verificati.

L'indagine resta aperta. Il merge del codice non equivale al ripristino dell'accesso. Questo aggiornamento non stabilisce una causa principale, un impatto quantificato o una data di ripristino confermata. Aggiorneremo il registro quando questi dati saranno verificati.