Informazioni sulle pianificazioni della rotazione

Questo argomento introduce il concetto della rotazione dei secret. Prima di iniziare, ti consigliamo di consultare la panoramica della piattaforma per capire il panorama generale 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 divulgazione di un secret.
• Assicurati che gli utenti che non richiedono più l'accesso a un secret non possano utilizzare i valori dei secret precedenti.
• Esegui continuamente il flusso di rotazione per ridurre la probabilità di interruzione in caso di rotazione di emergenza.

Secret Manager si basa su un concetto di Secret, versioni di secret e pianificazioni di rotazione, che forniscono le basi per la creazione di carichi di lavoro che supportano i secret ruotati.

Questo argomento fornisce suggerimenti per la rotazione dei secret archiviati in Secret Manager. Nelle sezioni successive vengono illustrati i vantaggi e i compromessi in termini di:

• Metodi per associare una versione del secret all'applicazione.
• Approccio alla rotazione dei secret.

Associazione a una versione del secret

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

È possibile fare riferimento alla versione del secret aggiunta più di recente su un secret utilizzando l'alias latest. L'alias latest, sebbene sia pratico per lo sviluppo, può essere problematico per alcuni carichi di lavoro di produzione poiché un valore errato potrebbe essere implementato immediatamente e comportare 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, esiste un rischio inferiore di rottura, ma anche un tempo di ripristino più lento. Alcuni secret possono essere invalidati in sistemi esterni (ad esempio, API o database che monitorano i valori dei secret validi), che potrebbero o meno essere sotto il tuo controllo e, in questi casi, il recupero richiede un'implementazione.

È possibile che un secret non valido venga implementato durante la rotazione manuale o automatica. Un flusso di lavoro di rotazione efficace dovrebbe essere in grado di rilevare automaticamente l'interruzione (ad esempio le percentuali di errore HTTP) e di eseguire il rollback per utilizzare la versione precedente del secret (tramite un deployment di configurazione precedente).

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

Approccio 1: risoluzione dei problemi durante un processo di rilascio esistente

Risolvi e associa la tua versione del secret alla release dell'applicazione. Per la maggior parte dei deployment, ciò comporta la risoluzione dell'ultima versione del secret nel nome completo della risorsa della versione secret e l'implementazione con l'applicazione come flag o in un file di configurazione. Ti consigliamo di risolvere il nome della versione del secret al momento della rotazione, di archiviare il nome della risorsa in un luogo durevole (ad esempio, commit in Git) e di eseguire il pull del nome della versione nella configurazione del deployment durante il push per evitare il blocco dei deployment.

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

Questo approccio offre i seguenti vantaggi:

• L'applicazione utilizza la stessa versione del secret tra i riavvii, aumentando la prevedibilità e riducendo la complessità operativa.
• I processi di gestione dei cambiamenti esistenti per implementazioni e rollback possono essere riutilizzati per la rotazione dei secret e il deployment della versione dei secret.
• Il valore può essere implementato gradualmente, riducendo l'impatto del deployment di valori errati.

Nota: la risoluzione della versione più recente al momento del deployment potrebbe bloccare i deployment se al più tardi esiste una versione del secret errata. La risoluzione dei problemi durante il deployment potrebbe essere meno isolata o riproducibile, poiché il successo dell'implementazione dipende dallo stato della versione del secret in Secret Manager. Se la versione precedente del secret funziona, crea una nuova versione del secret con lo stesso valore e attendi che venga implementata. Si tratta essenzialmente di un "roll forwarding" e richiede l'autorizzazione secretmanager.versions.access sul secret per copiare il valore dalla versione precedente a quella nuova.

Approccio 2: risoluzione all'avvio dell'applicazione

Recupera il payload del secret più recente all'avvio dell'applicazione e continua a utilizzare il secret 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 verrà avviata man mano che le istanze si riavviano o lo scale up del servizio, che potrebbe portare a un'interruzione del servizio.

Approccio 3: risoluzione continua

Esegui un sondaggio continuo sull'ultima versione 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 avviene l'adozione graduale del nuovo valore del secret.

Ruota il tuo secret

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

Configura una pianificazione di rotazione sul tuo secret

Configura una pianificazione di rotazione per il tuo secret. Gli argomenti Pub/Sub devono essere configurati sul secret per ricevere notifiche quando è il momento di ruotare il secret. Per informazioni sulla configurazione degli argomenti nei secret, consulta la guida alle notifiche degli eventi.

Avvia Cloud Run per creare una nuova versione del secret

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

1. Ottieni o crea un nuovo secret nel sistema esterno (ad esempio database, provider API).

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

2. Aggiorna Secret Manager con il nuovo secret.

   Crea un nuovo SecretVersion in Secret Manager. Inoltre, l'alias latest verrà aggiornato in modo che rimandi al secret appena creato.

Nuovi tentativi e contemporaneità

Poiché il processo di rotazione può essere interrotto in qualsiasi momento, il servizio Cloud Run deve essere in grado di riavviarlo dal punto in cui è stato interrotto (deve essere eseguito nuovamente l'accesso).

Consigliamo di configurare i nuovi tentativi in Pub/Sub in modo da eseguire nuovamente le rotazioni non riuscite o interrotte. Inoltre, configura la contemporaneità massima e il numero massimo di istanze sul tuo servizio Cloud Run per ridurre al minimo la probabilità che le esecuzioni di rotazioni simultanee interferiscano tra loro.

Per creare una funzione di rotazione di nuovo accesso, può essere utile salvare lo stato per consentire la ripresa del processo di rotazione. Esistono due funzionalità di Secret Manager che ti consentono di farlo:

• 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 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 modifichino contemporaneamente il secret durante il flusso di lavoro di rotazione. Scopri di più sui tag delle versioni secret e secret.

Nota: gli Etag per i secret e le versioni dei secret sono indipendenti l'uno dall'altro. In altre parole, l'aggiunta di una nuova versione non modifica l'etag del secret principale.

Autorizzazioni di Identity and Access Management

Il processo di rotazione richiederà l'autorizzazione secretmanager.versions.add per aggiungere una nuova versione del secret e potrebbe richiedere 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 le versioni dei secret, ma non per accedere. Per seguire il principio del privilegio minimo, ti consigliamo di NON utilizzare l'account di servizio predefinito. Configura invece 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ù dei seguenti):

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

Implementa il nuovo SecretVersion per i carichi di lavoro

Ora che un nuovo SecretVersion valido è stato registrato nel sistema esterno e archiviato in Secret Manager, implementalo nella tua applicazione. Questa implementazione varia in base al tuo approccio all'associazione dei secret (consulta la sezione Associazione a una versione del secret) e in genere non richiede alcun intervento manuale.

Esegui la pulizia delle versioni precedenti dei secret

Una volta eseguita la rotazione di tutte le applicazioni dalla versione precedente del secret, puoi pulire in sicurezza il secret. 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 tutte le applicazioni.
2. Disabilita la versione precedente del secret in Secret Manager e verifica che le applicazioni non si interrompano (attendi un periodo di tempo ragionevole per consentire a un essere umano di intervenire se la disattivazione provoca un errore per un consumer).
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

• Scopri come configurare pianificazioni di rotazione per i secret.