Dove conservare configurazioni e segreti

Tratta in modo diverso le impostazioni non sensibili, come URL dei servizi e flag delle funzionalità, e le credenziali come password, chiavi API e chiavi private. Non inserire credenziali reali nel codice e non eseguire il commit di file che le contengono in un repository condiviso. Verifica prima quali meccanismi di configurazione accetta l'applicazione.

Se gli strumenti lo consentono, conserva i valori locali di ogni sviluppatore in un file .env e condividi un .env.example con i soli nomi delle variabili e valori segnaposto. Aggiungi il file .env reale a .gitignore e verifica che Git non lo stia già tracciando. Una regola di esclusione di Git non è un archivio sicuro e non rimuove i valori dalla cronologia esistente.

Nei sistemi CI come GitHub Actions, registra le credenziali tramite la funzione di gestione dei segreti del provider, anziché inserirle nei file del workflow. Limita l'accesso ai repository, agli ambienti e ai job che ne hanno bisogno, concedi ai token solo i permessi necessari ed evita di stampare i valori. Il mascheramento dei log non garantisce che ogni valore trasformato o output dei comandi venga nascosto.

In produzione, preferisci il gestore dei segreti del provider di hosting o cloud e limita i deployment e i servizi autorizzati a leggere ciascun valore. Docker Compose può montare i segreti come file nei servizi autorizzati esplicitamente; funzionalità e limiti variano in base alla piattaforma. Consulta la documentazione dell'ambiente effettivamente usato. Se supportate, valuta credenziali di breve durata come OIDC al posto di chiavi valide a lungo.

Se un segreto potrebbe essere comparso in un commit, in un log CI o in una chat, eliminare la copia visibile non basta. Revoca o rinnova prima la chiave o il token interessato, poi esamina i log di accesso e gli eventuali utilizzi. In seguito, intervieni sulla cronologia del repository e sui log secondo necessità e rafforza i controlli di accesso per evitare che accada di nuovo.