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 aiuta nei seguenti modi:

  • Limita l'impatto nel caso di un secret divulgato.

  • Assicura che le persone che non richiedono più l'accesso a un secret non possano per usare i vecchi valori dei secret.

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

Secret Manager prevede un concetto di secret, versioni secret e programmazioni di rotazione, che forniscono le basi per creare carichi di lavoro che supportano i secret ruotati.

Questa pagina fornisce suggerimenti 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.

Associa una versione del secret all'applicazione

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

È possibile fare riferimento alla versione del secret aggiunta più di recente su un secret utilizzando il metodo 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 del servizio. Metodi alternativi per l'associazione a una versione del secret è descritta negli scenari seguenti.

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 segreti possono essere invalidati in sistemi esterni (ad esempio API o database che monitorano valori segreti 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 l'interruzione del servizio (ad esempio percentuali di errori HTTP) ed eseguire il rollback per utilizzare una versione precedente del secret (tramite un deployment della configurazione precedente).

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 di deployment, ciò comporta la risoluzione dell'ultima versione del secret il nome della risorsa della versione del secret mediante deployment 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 nei riavvii, aumentando la prevedibilità e la riduzione della 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: risolvi all'avvio dell'applicazione

Recupera il payload del secret più recente all'avvio dell'applicazione e continua a utilizzare il 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 secret può essere aggiornato dinamicamente (ad esempio, se il sistema esterno la convalida del secret fornisce un'API amministrativa), ti consigliamo di impostare una rotazione che viene eseguito periodicamente. I passaggi generali sono descritti di seguito con Cloud Run come ambiente di calcolo di esempio.

Configura una pianificazione della rotazione per il segreto

Impostare una pianificazione di rotazione per il tuo segreto. Gli argomenti Pub/Sub devono essere configurati sul secret ricevi notifiche quando è il momento di ruotare il tuo secret. 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. Ottenere o creare un nuovo secret nel sistema esterno (ad esempio database, API del cloud).

    Assicurati che questa operazione non invalidi i secret esistenti in modo che senza influire sui carichi di lavoro.

  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 dal punto in cui è stato interrotto (deve essere rientrato).

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 di ritorno, potrebbe essere utile salvare per consentire la ripresa del processo di rotazione. Esistono due metodi Funzionalità di Secret Manager utili in questo caso:

  • 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 le durante il flusso di lavoro di rotazione. Scopri di più su etag di secret e versioni dei secret.

Autorizzazioni di Identity and Access Management

Il processo di rotazione richiede l'autorizzazione secretmanager.versions.add per aggiunge una nuova versione del secret e potrebbe richiedere l'autorizzazione secretmanager.versions.access per leggere la versione precedente del secret.

Il processo di rotazione richiede l'autorizzazione secretmanager.versions.add per aggiunge una nuova versione del secret e potrebbe richiedere l'autorizzazione secretmanager.versions.access per leggere la versione precedente del secret.

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. Invece, Configurare un account di servizio separato per il tuo servizio Cloud Run con i ruoli di Secret Manager concessi in base alle esigenze (possono essere uno o più di):

  • roles/secretmanager.secretVersionAdder

  • roles/secretmanager.secretVersionManager

  • roles/secretmanager.secretAdmin

  • roles/secretmanager.secretAccessor

Implementa la nuova versione del secret per i 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.

Ripulire 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. Il processo di pulizia dipende dal tipo di secret, ma in genere:

  1. Assicurati che la nuova versione del secret sia stata implementata completamente in tutti diverse applicazioni.

  2. Disabilita la versione precedente del secret in Secret Manager e verifica che tutte le applicazioni non si interrompono (attendi un periodo di tempo ragionevole per interviene se la disattivazione arreca danni al consumatore).

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

  4. Elimina la versione precedente del secret in Secret Manager

Passaggi successivi