Informazioni sulla rotazione dei secret

La rotazione dei secret è il processo di aggiornamento o sostituzione periodica di informazioni sensibili (secret) come password, chiavi API o chiavi di crittografia. La rotazione dei secret contribuisce a ridurre al minimo il rischio di accesso non autorizzato o uso improprio dei secret, in particolare se sono stati compromessi o divulgati.

La rotazione periodica è utile nei seguenti modi:

  • Limita l'impatto in caso di fuga di un secret.

  • Garantisce che le persone che non richiedono più l'accesso a un secret non possano utilizzare i vecchi valori del secret.

  • Riduci al minimo il rischio di interruzioni del servizio se devi ruotare i secret con urgenza.

Secret Manager utilizza il concetto di secret, versioni di secret e pianificazioni di rotazione, che forniscono una base per creare carichi di lavoro che supportano i secret ruotati.

Questa pagina fornisce consigli per la rotazione dei secret archiviati in Secret Manager. Imparerai a:

Prima di iniziare, ti consigliamo di leggere la panoramica della piattaforma per comprendere il panorama complessivo di Google Cloud. Ti consigliamo inoltre di leggere la panoramica del prodotto Secret Manager.

Associare una versione del secret all'applicazione

Un secret in Secret Manager può avere più versioni. Le versioni del secret contengono il payload immutabile (la stringa di byte del secret effettiva) e sono ordinate e numerate. Per ruotare un secret, aggiungi una nuova versione a un secret esistente.

È possibile fare riferimento alla versione del secret aggiunta più di recente utilizzando l'alias latest. L'alias latest, sebbene pratico per lo sviluppo, può essere problematico per alcuni carichi di lavoro di produzione, poiché un valore errato potrebbe essere implementato immediatamente e causare un'interruzione a livello di servizio. I metodi alternativi per l'associazione a una versione del secret sono descritti nei seguenti scenari.

Implementazioni graduali

Le implementazioni graduali sono un principio guida per i seguenti scenari. Scegliendo un implementazione più lenta dei secret, il rischio di guasti è inferiore, ma anche il tempo di recupero. Alcuni secret possono essere invalidati in sistemi esterni (ad esempio API o database che monitorano valori secret validi) che potrebbero o meno essere sotto il tuo controllo e il recupero in questi casi richiede un'implementazione.

È possibile che un segreto non valido venga implementato durante la rotazione manuale o automatica. Un flusso di lavoro di rotazione efficace dovrebbe essere in grado di rilevare automaticamente i problemi (ad esempio i tassi di errore HTTP) e eseguire il rollback per utilizzare la versione precedente del secret (tramite un precedente dispiegamento della configurazione).

L'implementazione della nuova versione del secret dipende dal modo in cui i secret sono associati alla tua applicazione.

Approccio 1: risoluzione durante una procedura di rilascio esistente

Risolvi e associa la versione del secret alla release dell'applicazione. Per la maggior parte dei deployment, questo comporta la risoluzione della versione più recente del secret nel nome completo della risorsa della versione del secret e il relativo implementazione con l'applicazione come flag o in un file di configurazione. Ti consigliamo di risolvere il nome della versione del segreto al momento della rotazione, di memorizzare il nome della risorsa in un luogo permanente (ad esempio, un commit in Git) e di inserire il nome della versione nella configurazione di deployment durante il push per evitare i deployment bloccati.

All'avvio dell'applicazione, chiama Secret Manager con il nome della versione del secret specifico per accedere al valore del secret.

Questo approccio presenta i seguenti vantaggi:

  • L'applicazione utilizza la stessa versione del secret a ogni riavvio, aumentando la prevedibilità e riducendo la complessità operativa.

  • Le procedure di gestione delle modifiche esistenti per le implementazioni e i rollback possono essere riutilizzate per la rotazione dei secret e il deployment delle versioni dei secret.

  • Il valore può essere implementato gradualmente, riducendo l'impatto dell'implementazione di valori sbagliati.

Approccio 2: risoluzione all'avvio dell'applicazione

Recupera il payload segreto più recente all'avvio dell'applicazione e continua a utilizzare il segreto per tutta la durata dell'applicazione.

Il vantaggio di questo approccio è che non richiede la modifica della pipeline CI/CD per risolvere le versioni dei secret, ma se viene implementato un secret errato, l'applicazione non riesce ad avviarsi al riavvio delle istanze o al ridimensionamento del servizio e potrebbe verificarsi un'interruzione del servizio a cascata.

Approccio 3: risolvi continuamente

Esegui continuamente la ricerca della versione più recente del secret nell'applicazione e utilizza immediatamente il nuovo valore del secret.

Questo approccio rischia un'interruzione immediata a livello di servizio, in quanto non viene adottato gradualmente il nuovo valore del secret.

Ruota il secret

Se il segreto può essere aggiornato dinamicamente (ad esempio, se il sistema esterno che convalida il segreto fornisce un'API Admin), ti consigliamo di configurare un job di rotazione che venga eseguito periodicamente. I passaggi generali sono descritti nella sezione seguente con Cloud Run come ambiente di calcolo di esempio.

Configurare una pianificazione della rotazione per il segreto

Configura una programmazione della rotazione per il tuo segreto. Gli argomenti Pub/Sub devono essere configurati sul secret per ricevere notifiche quando è il momento di ruotarlo. Consulta la guida alle notifiche sugli eventi per configurare gli argomenti nei tuoi secret.

Avvia un servizio Cloud Run per creare una nuova versione del secret

Crea e configura un servizio Cloud Run per ricevere notifiche di rotazione ed eseguire i passaggi di rotazione:

  1. Ottieni o crea un nuovo token segreto nel sistema esterno (ad esempio database, fornitore di API).

    Assicurati che questa operazione non invalidi i secret esistenti in modo che i carichi di lavoro esistenti non siano interessati.

  2. Aggiorna Secret Manager con il nuovo secret.

    Crea una nuova versione del secret in Secret Manager. Viene aggiornato anche l'alias latest in modo che rimandi al secret appena creato.

Nuovi tentativi e concorrenza

Poiché il processo di rotazione potrebbe essere interrotto in qualsiasi momento, il servizio Cloud Run deve essere in grado di riavviare il processo da dove si è interrotto (deve essere ricorrente).

Ti consigliamo di configurare i tentativi di nuovo in modo da poter eseguire nuovamente le rotazioni non riuscite o interrotte. Inoltre, configura la concorrenza massima e le istanze massime sul tuo servizio Cloud Run per ridurre al minimo la probabilità che le esecuzioni di rotazione simultanee interferiscano tra loro.

Per creare una funzione di rotazione ricorsiva, potrebbe essere utile salvare lo stato per consentire la ripresa del processo di rotazione. Esistono due funzionalità di Secret Manager che possono aiutarti:

  • Utilizza le etichette sui secret per salvare lo stato durante la rotazione. Aggiungi un'etichetta al secret per monitorare il numero dell'ultima versione aggiunta correttamente durante il flusso di lavoro di rotazione (ad esempio, ROTATING_TO_NEW_VERSION_NUMBER=3). Al termine della rotazione, rimuovi l'etichetta di monitoraggio della rotazione.

  • Utilizza gli ETag per verificare che altri processi non stiano modificando contemporaneamente il secret durante il flusso di lavoro di rotazione. Scopri di più sugli etag dei secret e delle versioni dei secret.

Autorizzazioni di Identity and Access Management

La procedura di rotazione richiede l'autorizzazione secretmanager.versions.add per aggiungere una nuova versione del segreto e potrebbe richiedere l'autorizzazione secretmanager.versions.access per leggere la versione precedente del segreto.

La procedura di rotazione richiede l'autorizzazione secretmanager.versions.add per aggiungere una nuova versione del segreto e potrebbe richiedere l'autorizzazione secretmanager.versions.access per leggere la versione precedente del segreto.

L'account di servizio Cloud Run predefinito ha il ruolo Editor, che include l'autorizzazione per aggiungere, ma non accedere alle versioni dei secret. Per seguire il principio del minor privilegio, ti consigliamo di non utilizzare l'account di servizio predefinito. Al contrario, configura un account di servizio separato per il tuo servizio Cloud Run con i ruoli di Secret Manager concessi in base alle necessità (potrebbero essere uno o più di):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Esegui il deployment della nuova versione del secret nei carichi di lavoro

Ora che è stata registrata una nuova versione valida del secret con il sistema esterno ed è archiviata in Secret Manager, esegui il deployment nell'applicazione. Questo aggiornamento varia in base al tuo approccio all'associazione di secret e in genere non richiede intervento manuale.

Eliminare le vecchie versioni dei secret

Una volta che tutte le applicazioni sono state ruotate fuori dalla vecchia versione del secret, questa può essere eliminata in sicurezza. La procedura di pulizia dipende dal tipo di segreto, ma in genere:

  1. Assicurati che la nuova versione del segreto sia stata implementata completamente in tutte le applicazioni.

  2. Disattiva la vecchia versione del secret in Secret Manager e verifica che le applicazioni non si interrompano (attendi un periodo di tempo ragionevole per consentire a un utente di intervenire se la disattivazione causa l'interruzione di un consumatore).

  3. Rimuovi o annulla la registrazione della vecchia versione del secret dal sistema esterno.

  4. Elimina la vecchia versione del secret in Secret Manager

Passaggi successivi