Questa guida introduce alcune best practice per l'utilizzo di Secret Manager. La guida non è un elenco esaustivo dei consigli. Ti consigliamo di consultare la panoramica della piattaforma per comprendere il panorama generale di Google Cloud e la panoramica di Secret Manager prima di leggere questa guida.
Controllo dell'accesso
L'accesso all'API Secret Manager è protetto da IAM. Segui il principio del privilegio minimo quando concedi le autorizzazioni ai secret.
- Limita la proprietà dell'organizzazione a un account super amministratore protetto.
- Segmenta le applicazioni e gli ambienti (gestione temporanea/produzione) in progetti separati come descritto in Decidere una gerarchia delle risorse per la zona di destinazione Google Cloud. Questo può aiutare a isolare gli ambienti con l'associazione IAM a livello di progetto e a garantire che le quote vengano applicate in modo indipendente.
- Scegli un ruolo selezionato con le autorizzazioni minime necessarie o crea un ruolo personalizzato, se necessario.
- Quando i secret per molti servizi si trovano in un singolo progetto, utilizza le associazioni IAM a livello di secret o le condizioni IAM per limitare l'accesso al sottoinsieme necessario di secret.
- Il motore per suggerimenti IAM può fornire ulteriore assistenza per identificare le associazioni IAM con privilegi.
Le credenziali sono necessarie per l'autenticazione all'API Secret Manager. Tutte le librerie client utilizzano una strategia simile per cercare le credenziali indicate come "Credenziali predefinite dell'applicazione".
- Per lo sviluppo locale, utilizza
gcloud auth application-default login. In questo modo viene creato un file con credenziali recuperate automaticamente dalle librerie client. - Su Compute Engine e altre piattaforme di computing di Google Cloud come Cloud Functions, le librerie client ricevono le credenziali tramite il server di metadati dell'istanza.
- In GKE, l'identità del carico di lavoro fornisce le credenziali anche tramite un servizio di metadati.
- Su altre piattaforme come Amazon Web Services o Microsoft Azure, valuta la possibilità di configurare la federazione delle identità per i carichi di lavoro, che utilizzi meccanismi di identità esistenti per l'autenticazione nelle API Google Cloud.
Tutti questi metodi sono preferiti per esportare le credenziali di un account di servizio, perché non richiedono l'archiviazione e l'accesso in modo sicuro a un secret aggiuntivo al di fuori dell'API Secret Manager.
Pratiche di programmazione
Il trasferimento dei secret alla tua applicazione tramite il file system o le variabili di ambiente è un comportamento comune, ma dovrebbe essere evitato quando possibile per i seguenti motivi:
- Quando un secret è accessibile nel file system, le vulnerabilità delle applicazioni, come gli attacchi da directory trasversale, possono aumentare la gravità, in quanto l'utente malintenzionato potrebbe acquisire la capacità di leggere il materiale del secret.
- Quando un secret viene utilizzato tramite variabili di ambiente, errori di configurazione, come l'attivazione degli endpoint di debug o l'inclusione di dipendenze nei dettagli dell'ambiente di processo di log, potrebbero comportare la divulgazione di secret.
- Quando sincronizzi il materiale segreto con un altro datastore (come i secret di Kubernetes), prendi in considerazione i controlli di accesso di quel datastore, ad esempio:
- Il datastore espande l'accesso al secret?
- È possibile controllare l'accesso al secret?
- Il datastore è conforme ai requisiti di crittografia dei dati at-rest e di regionalizzazione?
Ti consigliamo di utilizzare direttamente l'API Secret Manager (utilizzando una delle librerie client fornite o seguendo la documentazione REST o GRPC).
Tuttavia, per alcune integrazioni di prodotti come quelle serverless, puoi trasferire i secret attraverso il file system o le variabili di ambiente. Per informazioni, vedi Utilizzare Secret Manager con altri prodotti.
Amministrazione
Scegli il criterio di replica automatica durante la creazione di secret, a meno che il tuo carico di lavoro non abbia requisiti di località specifici (applicabili mediante il vincolo constraints/gcp.resourceLocations).
Fai riferimento ai secret in base al numero di versione anziché utilizzare l'alias più recente. Esegui il deployment degli aggiornamenti ai numeri di versione utilizzando i tuoi processi di rilascio esistenti. In genere, ciò significa configurare l'applicazione con una versione del secret specifica che viene letta all'avvio. Sebbene l'utilizzo dell'alias più recente possa essere pratico, in caso di problemi con la nuova versione del secret, il carico di lavoro potrebbe non essere in grado di utilizzare la versione del secret. Fissando un numero di versione, la configurazione può essere convalidata e sottoposta a rollback utilizzando i processi di release esistenti.
Disabilita le versioni dei secret prima di distruggerle o eliminare i secret. Ciò consente di evitare interruzioni mettendo il secret in uno stato che somiglia all'eliminazione, ma è reversibile. In altre parole, puoi disattivarlo e attendere una settimana in modo da essere sicuro che non ci siano dipendenze persistenti prima di eliminare definitivamente i dati.
Non impostare la expiration sui secret di produzione a meno che tu non abbia la certezza che debbano essere eliminati in modo irreversibile. La funzionalità di scadenza è l'ideale per la pulizia automatica degli ambienti temporanei. Considera le condizioni IAM basate sul tempo come alternativa ai secret in scadenza.
Ruota i tuoi segreti periodicamente per:
- Limita l'impatto in caso di divulgazione di un secret.
- Assicurati che gli utenti che non richiedono più l'accesso a un secret non possano continuare a utilizzare un secret a cui si è eseguito l'accesso in precedenza.
- Esegui continuamente il flusso di rotazione per ridurre la probabilità di interruzione.
Monitorare i secret in tutta la tua organizzazione utilizzando Cloud Asset Inventory per...
- Aiuta a identificare i secret nella tua organizzazione.
- Identifica la non conformità ai requisiti dell'organizzazione come la rotazione, la configurazione della crittografia e la località.
Abilita i log di accesso ai dati per ottenere e analizzare le informazioni delle richieste AccessSecretVersion. Abilita questa opzione a livello di cartella o organizzazione per applicare il logging senza doverlo configurare su ogni secret o progetto.
Oltre ai controlli IAM, puoi limitare l'accesso all'API Secret Manager con controlli basati sulla rete configurando un perimetro Controlli di servizio VPC per la tua organizzazione.
Il criterio dell'organizzazione constraints/iam.allowedPolicyMemberDomains può essere utilizzato per limitare le identità che possono essere aggiunte ai criteri IAM per i secret.
Stima l'utilizzo di picco dei secret (considerando un "gruppo di thundering" di richieste a causa dei deployment simultanei delle applicazioni o della scalabilità automatica del tuo servizio) e assicurati che il tuo progetto disponga di una quota sufficiente per gestire un evento di questo tipo. Se è necessaria una quota maggiore, richiedi un aumento.