Informazioni sulle pianificazioni della rotazione

Questo argomento introduce il concetto di rotazione dei secret. Prima di iniziare, ti consigliamo di consultare la Panoramica della piattaforma per comprendere il panorama complessivo di Google Cloud. Ti consigliamo inoltre di leggere la panoramica del prodotto Secret Manager.

Introduzione

La rotazione periodica consente di:

  • 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 usare i vecchi valori del secret.
  • Esegui continuamente il flusso di rotazione per ridurre la probabilità di un interruzione in caso di rotazione di emergenza.

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

Questo argomento fornisce consigli per la rotazione degli secret archiviati in Secret Manager. Le sezioni seguenti illustrano i vantaggi e i compromessi per:

Collegamento a una versione del secret

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 del 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 è più lungo. Alcuni secret possono essere invalidati in sistemi esterni (come API o database che monitorano valori secret validi) che possono 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 errati.

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 riuscirà ad avviarsi al riavvio delle istanze o all'aumento di scalabilità 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 nel tuo secret

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 non invalidi i secret esistenti in modo che i workload esistenti non siano interessati.

  2. Aggiorna Secret Manager con il nuovo secret.

    Crea un nuovo SecretVersion in Secret Manager. Verrà 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 invio in Pub/Sub in modo che le rotazioni non riuscite o interrotte possano essere eseguite di nuovo. Inoltre, configura la contemporaneità massima e le istanze massime nel 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, potresti trovare 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 segreto per monitorare il numero dell'ultima versione aggiunta correttamente durante il flusso di lavoro di rotazione (ad es. 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 segreto 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 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 privilegio minimo, 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à (possono essere uno o più):

  • roles/secretmanager.secretVersionAdder
  • roles/secretmanager.secretVersionManager
  • roles/secretmanager.secretAdmin
  • roles/secretmanager.secretAccessor

Esegui il deployment del nuovo SecretVersion nei workload

Ora che un nuovo SecretVersion valido è stato registrato nel sistema esterno ed è archiviato in Secret Manager, esegui il deployment nell'applicazione. Questo implementazione varia in base al tuo approccio al collegamento dei secret (consulta la sezione Collegamento a una versione del 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. La procedura di pulizia dipende dal tipo di secret, ma in genere:

  1. Assicurati che la nuova versione del secret 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 interrompe 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