04 - Accessi

Indice · Architettura · Sviluppo e rilascio

Il catalogo assegna a ogni componente gli accessi dichiarati; i grant personali, ereditati o legacy vanno verificati separatamente. Condividere progetto, rete o sistema non autorizza tutte le comunicazioni. Gli operatori amministrano il cloud; gli utenti delle applicazioni usano ruoli e dati gestiti dal prodotto.

Tipo	Chi e dove	Controllo e stato essenziale
Operatori cloud	Gruppi aziendali → risorse Google	Terraform assegna ruoli ai gruppi; i gestori aggiungono persone. Grant applicati. Ogni operatore verifica le azioni assegnate nel normale primo uso, distinguendo gruppi e privilegi personali: nessuna sessione dedicata di Lorenzo blocca il lavoro.
Build e deploy	Identità CI distinte → sorgenti, immagini e workload	Checker, publisher, preparazione, render e deploy hanno compiti separati. Rilascio Access e retry isolato SQL-free sono verificati entro il perimetro delle ricevute. Il publisher non approva il proprio rollout.
Database	Runtime/migratore → database del sistema	Servono rete privata, login IAM e privilegi PostgreSQL. Runtime senza DDL o ruolo owner; migratore separato. Access è verificato. Farm ha superato le verifiche delle due identità prima e dopo la migrazione, con runtime senza DDL/ledger e altri sei database negati a entrambe. Readonly esplicito.
Servizio → servizio	Service account chiamante → API destinataria	Token Google, audience corretta, invoker nominale e rete compatibile; il destinatario controlla operazioni e dati. Platform→Farm verificato su health/readiness: autorizzato 200, senza grant/token 403, audience errata 401, dopo revoca 403; sonda e grant rimossi. Il grant Console→Access non ne sostituisce il collaudo.
Archivi, segreti, firma	Componente → bucket, secret o chiave dichiarati	Lettura, creazione, cancellazione e firma sono capacità diverse. Access ha grant specifici; ogni nuovo componente richiede quelli necessari, senza ereditare tutto dal sistema.
Eventi e Job	Publisher/SA del trigger → topic, Service o Job	Pub/Sub usa push autenticato; Scheduler usa OIDC per HTTP e OAuth per avviare Job. Moduli predisposti, eventi generici inattivi; verificare anche esito dell'Execution, duplicati e retry.
Staff nelle app	Persona → ingresso IAP → applicazione	IAP ammette il gruppo; sessione e capacità applicative restano separate. Ingresso staff non attivo. Console è un'integrazione, non un prerequisito della piattaforma.
Client e agent	Utente/installazione → API prodotto	Token Access e autorizzazioni per organizzazione. Dal 10 novembre la doc prevede IAP anche sui percorsi client dello stage; in produzione quei percorsi non richiedono account Google dei clienti. Edge e sessioni restano da implementare/collaudare.

infra-admins amministra shared e ambienti attivati. stage-release-admins approva rilasci; stage-observers-admins legge metadata, log e metriche, senza ricevere accesso diretto ai dati SQL o ai valori Secret Manager. I log e le configurazioni leggibili possono però contenere informazioni scritte dalle applicazioni: i ruoli IAM non le oscurano. Occorre mantenere i log sanitizzati e i valori segreti fuori dalle configurazioni visibili.

I gruppi produzione restano riservati; non è previsto un gruppo amministratori stage separato. Le iscrizioni non sincronizzano i ruoli applicativi. I permessi per ripetere una fase fallita o tornare a una release precedente vanno verificati e collaudati separatamente: l'approvazione del rilascio non ne dimostra la disponibilità. Vedere la procedura di rilascio e recupero.

Il piano di recupero, applicato, aggiunge agli operatori lettura di release/rollout/JobRun e retryJob sulle pipeline dichiarate, più letture sui Service/Job già esistenti e dichiarati. Non aggiunge approvazione, creazione di release, modifica SQL, rollback o lettura delle Operations dell'intero progetto. Letture e retry reale sono provati con Jacopo; questo non certifica retroattivamente Lorenzo né la sufficienza dei soli gruppi rispetto ad altri privilegi personali. Il suo primo uso ordinario fornirà la verifica delle azioni effettive, senza richiedere una sessione dedicata. Recovery e limiti.

La separazione runtime/migratore è una regola già prevista, da mantenere per ogni nuovo componente. Un consumer aggiuntivo può ricevere scrittura sui dati necessari, non la capacità di modificare tabelle o assumere il ruolo del migratore. Gli accessi SQL da soli non ne abilitano la delivery: serve anche il percorso descritto nella scheda SQL.

Limiti reali: l'approvazione Cloud Build e alcuni accessi alle sorgenti hanno ambito progetto CI; il writer delle immagini ha ambito repository Artifact Registry, non singola immagine. Non promettiamo isolamento maggiore.

Per l'ingress ristretto attuale abbiamo applicato DNS privato run.app sulla Shared VPC con Private Google Access; il riscontro DNS è positivo. Il percorso completo è stato provato con un Job sonda in Platform verso Farm, senza aspettare Console. L'endpoint run.app rimane abilitato: la risoluzione DNS cambia il percorso di rete, non l'URL chiamato o l'audience del token. L'accesso rimane soggetto a ingress e IAM.

Il collaudo iniziale ha usato una sonda temporanea in Platform e il backend Farm reale, con private-ranges-only e Shared VPC coerente sia sul chiamante sia sulle revisioni destinatarie. Non richiede il prodotto Farm completo. Sono verificati il successo con l'identità autorizzata e i dinieghi prima del grant, senza token, con audience errata e dopo revoca; cinque Job e grant temporaneo sono rimossi. Una prova soltanto dentro Platform o la sola lettura DNS non certificano questo percorso. Collaudo e limiti.

È una scelta di rete, non un requisito universale di IAM. La sonda prova il percorso e i permessi cloud; le autorizzazioni sulle singole operazioni e sui dati richiedono anche test del servizio.

Durante lo sviluppo basta dichiarare identità, destinazioni e operazioni nel modello del servizio. Terraform prepara grant concreti quando servono; il codice applica il proprio RBAC. Prossimi passi · Collaudi · Fonti e limiti delle evidenze.

Apertura Access: profilo specifico, ancora separato

La prova Farm ha chiuso la comunicazione privata S2S. Non apre i percorsi esterni di Access e non certifica Console o client. La policy documentale del 10 novembre mette IAP davanti allo staff e, solo nello stage, anche ai percorsi dei client. Dopo IAP restano i token e i permessi del prodotto. In produzione i percorsi client non usano IAP; i clienti non diventano account aziendali Google.

Prima di aprire Access serve il suo profilo di ingresso: backend/percorsi esposti, identità ammessa, audience e sessione coerenti, nessun aggiramento dell'ingress interno o confusione con RPC fra servizi. Il modulo staff_edge attuale non prova che l'intero edge client-stage sia già pronto. L'onboarding di un altro servizio privato può procedere senza aspettare questa apertura.