Best practice di Secret Manager

Questa guida introduce 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 Google Cloud generale 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 per i secret.

Per l'autenticazione all'API Secret Manager sono necessarie le credenziali. Le librerie client utilizzano tutte una strategia simile per cercare le credenziali denominate credenziali predefinite dell'applicazione.

  • Quando sviluppi in locale, utilizza gcloud auth application-default login. Viene creato un file con le credenziali che vengono recuperate automaticamente dalle librerie client.

  • Su Compute Engine e altre piattaforme di calcolo come le funzioni Cloud Run, le librerie client ottengono le credenziali tramite il server dei metadati dell'istanza. Google Cloud

  • Su GKE, Workload Identity 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 utilizza i meccanismi di identità esistenti per l'autenticazione alle API Google Cloud .

Tutti questi metodi sono preferibili all'esportazione di una credenziale del account di servizio perché non richiedono l'archiviazione e l'accesso sicuri a un secret aggiuntivo al di fuori dell'API Secret Manager.

Pratiche di programmazione

Evita di passare secret alla tua applicazione tramite il file system o le variabili di ambiente. Di seguito sono riportati alcuni motivi per utilizzare altri metodi per la gestione dei secret:

  • Quando un secret è accessibile sul file system, le vulnerabilità delle applicazioni come gli attacchi di attraversamento delle directory possono diventare più gravi perché l'autore dell'attacco potrebbe ottenere la possibilità di leggere il materiale segreto.

  • Quando un secret viene utilizzato tramite variabili di ambiente, 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 perdita di secret.

  • Quando sincronizzi materiale segreto con un altro datastore (ad esempio i secret di Kubernetes), valuta i controlli di accesso forniti da quel datastore. Considera quanto segue:

    • 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 l'API Secret Manager direttamente 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 tramite il file system o le variabili di ambiente. Per informazioni, consulta la sezione Utilizzo di Secret Manager con altri prodotti.

Amministrazione

Scegli i criteri di replica automatica quando crei i secret, a meno che il tuo workload non abbia requisiti di località specifici (applicabili utilizzando il vincolo constraints/gcp.resourceLocations).

Fai riferimento ai secret in base al loro numero di versione anziché utilizzare l'alias latest. Esegui il deployment degli aggiornamenti ai numeri di versione utilizzando le procedure di rilascio esistenti. In genere, ciò significa configurare l'applicazione con una versione specifica del secret che viene letta all'avvio. Sebbene l'utilizzo dell'alias più recente possa essere conveniente, se si verifica un problema con la nuova versione del secret, il tuo workload potrebbe non essere in grado di utilizzare la versione del secret. Se blocchi una versione, la configurazione può essere convalidata e ripristinata utilizzando i processi di rilascio esistenti.

Disattiva le versioni del secret prima di eliminarle o eliminare i secret. In questo modo si evitano interruzioni mettendo il secret in uno stato che appare uguale a destroy, ma è reversibile. ovvero puoi disattivare e attendere una settimana per assicurarti che non ci siano dipendenze prima di eliminare definitivamente i dati.

Non impostare la scadenza per i secret di produzione, a meno che tu non sia certo che debbano essere eliminati in modo irreversibile. La funzionalità di scadenza è più adatta per la pulizia automatica degli ambienti temporanei. Prendi in considerazione le condizioni IAM basate sul tempo come alternativa ai secret in scadenza.

Ruota periodicamente i secret per:

  • Limitare l'impatto in caso di divulgazione di un secret.

  • Assicurati che le persone che non hanno più bisogno di accedere a un secret non possano continuare a utilizzare un secret a cui hanno già avuto accesso.

  • Ridurre la probabilità di un'interruzione.

Monitora i secret nella tua organizzazione utilizzando Cloud Asset Inventory per i seguenti motivi:

  • Aiutare 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 la registrazione senza doverla configurare per 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 massimo dei secret (tenendo conto di un effetto gregge di richieste dovuto a deployment simultanei di applicazioni o alla scalabilità automatica del servizio) e assicurati che il tuo progetto disponga di quota sufficiente per gestire un evento di questo tipo. Se hai bisogno di più quota, richiedi un aumento.

Conformità alla residenza dei dati

Scegli secret regionali se hai requisiti rigorosi di residenza e sovranità dei dati. I secret regionali ti consentono di archiviare dati sensibili in una posizione geografica specifica, fornendo garanzie complete per i dati at-rest, in uso e in transito, aiutandoti a rispettare i requisiti legali, normativi o organizzativi relativi alla residenza dei dati.