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 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 super amministratore protetto Google Cloud.
• 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 contribuire a identificare associazioni IAM con privilegi eccessivi.

Le credenziali sono necessarie per l'autenticazione nell'API Secret Manager. La le librerie client usano tutte una strategia simile per cercare le credenziali a cui si fa riferimento 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.
• Su Compute Engine e altre piattaforme di computing Google Cloud, come Le funzioni Cloud Run, le librerie client ottengono le credenziali tramite server di metadati dell'istanza.
• Su 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, prendi in considerazione La configurazione della federazione delle identità per i carichi di lavoro, che utilizza i meccanismi di identità esistenti per eseguire l'autenticazione nelle API Google Cloud.

Tutti questi metodi sono preferibili per esportare le credenziali di un account di servizio perché non richiedono l'accesso e l'archiviazione sicura di un secret aggiuntivo all'esterno 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 secret è accessibile sul file system, le vulnerabilità dell'applicazione come gli attacchi di directory attraversal possono diventare più gravi in quanto l’aggressore possono riuscire a leggere il materiale segreto.
• Quando un secret viene utilizzato tramite le variabili di ambiente, le configurazioni errate ad esempio l'abilitazione degli endpoint di debug o l'inclusione delle dipendenze che elaborano i log i dettagli dell'ambiente potrebbero rivelare secret.
• Quando sincronizzi il materiale secret con un altro datastore (come Kubernetes Secret), prendi in considerazione i controlli di accesso al datastore, ad esempio:
  • Il data store espande l'accesso al secret?
  • È possibile controllare l'accesso al secret?
  • Il datastore è conforme alla crittografia dei dati at-rest e requisiti 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 le integrazioni serverless, passa i secret attraverso il file system o le variabili di ambiente. Per informazioni, consulta Utilizzare Secret Manager con altri prodotti.

Amministrazione

Scegli il criterio di replica automatica durante la creazione a meno che il carico di lavoro non abbia requisiti di località specifici (applicabili) utilizzando l'app constraints/gcp.resourceLocations ).

Fai riferimento ai secret tramite il numero di versione anziché utilizzare l'alias più recente. Esegui il deployment degli aggiornamenti alla versione usando i processi di rilascio esistenti. In genere, questo significa configurare l'applicazione con una versione specifica del secret che viene letta al 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. Con il blocco su un numero di versione, la configurazione può essere vengono convalidate e sottoposte a rollback utilizzando i processi di rilascio esistenti.

Disattiva le versioni dei secret prima di eliminarle o distruggerle. Ciò aiuta a evitare interruzioni inserendo il parametro in uno stato che assomiglia a destroy, ma è reversibile. Vale a dire che puoi disattivare il servizio e attendere una settimana per assicurarti che non ci siano prima di eliminare definitivamente i dati.

Non impostare la scadenza dei secret di produzione a meno che tu non sia sicuro che dovrebbe essere eliminato in modo irreversibile. La funzione di scadenza è più adatta per la pulizia automatizzata degli 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 gli utenti che non richiedono più l'accesso a un secret non possano continuare per utilizzare un secret a cui è stato eseguito l'accesso in precedenza.
• Eseguire continuamente il flusso di rotazione per ridurre la probabilità che o un'interruzione del servizio.

Monitora i secret in tutta l'organizzazione utilizzando Cloud Asset Inventory per…

• Contribuisci a identificare i secret nella tua organizzazione.
• Identificare la non conformità ai requisiti aziendali come rotazione, configurazione della crittografia e località.

Abilita i log di accesso ai dati per ottenere e analizzare AccessSecretVersion richiedere informazioni. 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 tuo picco di utilizzo dei secret (considerando un "tuono gregge" di richieste a causa deployment di applicazioni simultanee o scalabilità automatica del tuo servizio) e assicurati che il tuo progetto dispone di una quota sufficiente per gestire un evento di questo tipo. Se hai bisogno di più quota, richiedi un aumento.