Questa guida illustra alcune best practice per l'utilizzo di Secret Manager. La guida non è un elenco esaustivo di consigli. Ti consigliamo di esaminare la panoramica della piattaforma per comprendere il panorama generale di Google Cloud e la panoramica di Secret Manager prima di leggere questa guida.
Controllo degli accessi
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.
- Suddividi le applicazioni e gli ambienti (preparazione/produzione) in progetti distinti come descritto in Decidere una gerarchia delle risorse per la zona di destinazione Google Cloud. In questo modo, puoi isolare gli ambienti con l'associazione IAM a livello di progetto e assicurarti che le quote vengano applicate in modo indipendente.
- Scegli un ruolo selezionato con le autorizzazioni minime necessarie o, se necessario, crea un ruolo personalizzato.
- Quando i secret per molti servizi si trovano in un unico 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ò inoltre aiutarti a identificare associazioni IAM con privilegi eccessivi.
Le credenziali sono necessarie per autenticarsi nell'API Secret Manager. Le librerie client utilizzano tutte una strategia simile per cercare le credenziali indicate come "Credenziali predefinite dell'applicazione".
- Quando sviluppi in locale, utilizza
gcloud auth application-default login. Viene creato un file con le credenziali che vengono rilevate automaticamente dalle librerie client. - In Compute Engine e in altre piattaforme di calcolo Google Cloud come le funzioni Cloud Run, le librerie client ottengono le credenziali tramite il server di metadati dell'istanza.
- Su GKE, l'identità del workload fornisce le credenziali anche tramite un servizio di metadati.
- Su altre piattaforme come Amazon Web Services o Microsoft Azure, ti consigliamo di configurare la federazione delle identità di carico di lavoro, che utilizza i meccanismi di identità esistenti per autenticarsi nelle API Google Cloud.
Tutti questi metodi sono preferiti all'esportazione di una credenziale dell'account di servizio perché non richiedono l'archiviazione e l'accesso in sicurezza a un secret aggiuntivo al di fuori dell'API Secret Manager.
Pratiche di programmazione
È comune passare i secret all'applicazione tramite il file system o le variabili di ambiente, ma se possibile questa operazione deve essere evitata per i seguenti motivi:
- Quando un segreto è accessibile nel file system, le vulnerabilità delle applicazioni come gli attacchi di attraversamento della directory possono diventare più gravi poiché l'aggressore potrebbe acquisire la capacità di leggere il materiale segreto.
- Quando un segreto viene utilizzato tramite le variabili di ambiente, le configurazioni errate, come l'attivazione di endpoint di debug o l'inclusione di dipendenze che registrano i dettagli dell'ambiente di processo, possono causare la fuga di secret.
- Quando sincronizzi il materiale segreto con un altro datastore (ad esempio i secret Kubernetes), prendi in considerazione i controlli di accesso di quel datastore, ad esempio:
- Il data store espande l'accesso al secret?
- È possibile controllare l'accesso al secret?
- Il datastore è conforme ai requisiti di regionalizzazione e crittografia dei dati a riposo?
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 trasmettere i secret tramite il file system o le variabili di ambiente. Per informazioni, consulta Utilizzare Secret Manager con altri prodotti.
Amministrazione
Scegli il criterio di replica automatica quando crei i secret, a meno che il tuo carico di lavoro non abbia requisiti di località specifici (applicabili utilizzando il vincolo constraints/gcp.resourceLocations).
Fai riferimento ai secret tramite il numero di versione anziché utilizzare l'alias più recente. Esegui il deployment degli aggiornamenti ai numeri di versione utilizzando i processi di rilascio esistenti. In genere, questo significa configurare l'applicazione con una versione specifica del secret che viene letta all' avvio. Sebbene l'utilizzo dell'alias più recente possa essere pratico, se si verifica un problema con la nuova versione del secret, il tuo carico di lavoro potrebbe non essere in grado di utilizzare la versione del secret. Se blocchi un numero di versione, la configurazione può essere convalidata e ripristinata utilizzando le procedure di rilascio esistenti.
Disattiva le versioni dei secret prima di eliminarle o distruggerle. In questo modo è possibile evitare interruzioni dei servizi impostando il secret in uno stato che sembra uguale a quello di distruzione, ma è reversibile. In altre parole, puoi disattivare la funzionalità e attendere una settimana per assicurarti che non ci siano dipendenze rimanenti prima di eliminare definitivamente i dati.
Non impostare scadenza sui secret di produzione, a meno che non sia certo che debbano essere eliminati in modo irreversibile. La funzionalità di scadenza è più adatta per la pulizia automatica di ambienti temporanei. Valuta la possibilità di utilizzare le condizioni IAM basate sul tempo come alternativa ai secret con scadenza.
Ruota periodicamente i secret per:
- Limita l'impatto in caso di fuga di un secret.
- Assicurati che le persone che non richiedono più l'accesso a un secret non possano continuare a utilizzare un secret a cui hanno eseguito l'accesso in precedenza.
- Esegui continuamente il flusso di rotazione per ridurre la probabilità di un interruzione del servizio.
Monitora i secret in tutta l'organizzazione utilizzando Cloud Asset Inventory per…
- Aiutano a identificare i secret in tutta l'organizzazione.
- Identifica la mancata conformità ai requisiti dell'organizzazione, ad esempio rotazione, configurazione della crittografia e posizione.
Attiva i log di accesso ai dati per ottenere e analizzare le informazioni sulle richieste AccessSecretVersion. Attiva questa opzione a livello di cartella o organizzazione per applicare il logging senza doverli configurare su ogni segreto 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 il picco di utilizzo dei segreti (tenendo conto di un "mucchio di richieste" a causa di implementazioni di applicazioni simultanee o scalabilità automatica del servizio) e assicurati che il tuo progetto disponga di quote sufficienti per gestire un evento di questo tipo. Se hai bisogno di più quota, richiedi un aumento.