Gestione dei Segreti

Ecco il punto sui fork: sono copie byte per byte dell’immagine cifrata, credenziali incluse. Una chiave live Stripe, una password del database, un token API nel repo? Il fork le eredita. La tua sandbox finisce per addebitare le carte dei clienti reali.

Il posto giusto è rdc repo secret. Due modalità di consegna, solo scrittura per design, e il fork inizia senza nulla. In questo tutorial impostiamo entrambi i tipi, distribuiamo un’app che li usa, verifichiamo che i valori arrivino davvero nel container, e poi osserviamo un fork che non riesce ad avviarsi perché i segreti si sono rifiutati di seguirlo.

Guarda il tutorial

La trappola: .env nel repo

La maggior parte dei team mette .env nel repo. È la mossa ovvia.

Poi fanno il fork.

Il fork è una copia byte per byte dell’immagine del parent. Qualunque cosa ci sia in .env è nel .env del fork. I container del fork si avviano. Leggono la stessa chiave Stripe. Chiamano la stessa API Stripe con le credenziali di produzione. Dal punto di vista di Stripe, quella chiamata sei tu.

Brutta giornata. Chiedimi come lo so.

Passo 1: Imposta un segreto in modalità env

rdc repo secret set --name my-app --key DB_HOST --value postgres.internal --mode env

--mode env fa atterrare il valore come variabile d’ambiente nel container. Le prime scritture non richiedono cerimonie; è sovrascrivere un segreto esistente che richiede la prova del valore corrente.

Passo 2: Imposta un segreto in modalità file

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_xxx --mode file

La modalità file non inserisce mai il valore nell’ambiente del container. Lo scrive invece in /run/secrets/stripe_key, usando il meccanismo standard di Docker. Preferisci questo per qualsiasi cosa sensibile.

Passo 3: Elenca quello che hai

rdc repo secret list --name my-app

Vedi nomi e modalità. Nessun valore. La lista non mostra mai i valori, indipendentemente da chi chiede.

Collegalo a compose

Apri docker-compose.yml. Fai riferimento a entrambe le modalità:

services:
  api:
    image: myapp:latest
    environment:
      DATABASE_HOST: ${REDIACC_SECRET_DB_HOST}
    secrets:
      - stripe_key

secrets:
  stripe_key:
    file: /var/run/rediacc/secrets/${REDIACC_NETWORK_ID}/STRIPE_KEY

${REDIACC_SECRET_DB_HOST} è la modalità env: il wrapper compose di renet lo espande dal tuo store di segreti al momento del deploy.

Il blocco secrets: è la modalità file, usando il meccanismo standard di Docker. Il percorso host usa ${REDIACC_NETWORK_ID} in modo che lo stesso compose funzioni per parent e fork. Ogni fork ha il proprio ID di rete.

Non puoi mai rileggerlo

Ecco la parte che sorprende le persone la prima volta, incluso me stesso.

Passo 4: Get restituisce un digest

rdc repo secret get --name my-app --key STRIPE_KEY

Ottieni un digest. Non il valore. Non esiste un flag che lo faccia restituire il valore. Non esiste alcun comando che ti restituirà il testo in chiaro.

Questo è il modello GitHub Actions: solo scrittura. Puoi dimostrare di sapere cosa è un segreto passando --current <value> e osservando la precondizione soddisfatta. Non puoi chiedere a Rediacc di dirtelo.

Passo 5: Ruota quando dimentichi

Hai perso il valore? Non spiare. Ruota.

rdc repo secret set --name my-app --key STRIPE_KEY --value sk_test_new --mode file --rotate-secret

--rotate-secret salta la precondizione. Il log di audit lo segna come rotazione: esplicito, deliberato.

Se ricordi il vecchio valore, dimostracelo invece con --current <old-value>. Questo è il percorso più sicuro. Mi è capitato più di una volta quando sono nel terminale sbagliato o sulla macchina sbagliata.

Distribuisci e verifica la consegna

I segreti che non raggiungono mai l’app sono solo un database elegante. Distribuisci e verifica entrambi i percorsi di consegna.

Passo 6: Distribuisci con entrambi i segreti

rdc repo up --name my-app --machine <machine-name>

Passo 7: Il segreto env arriva

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app printenv DB_HOST'

Il container stampa postgres.internal. L’app ha davvero ricevuto il valore, espanso nel suo ambiente al momento del deploy.

Passo 8: Il segreto file arriva

rdc term connect --machine <machine-name> --repository my-app --command 'docker exec app cat /run/secrets/stripe_key'

Ed ecco il valore ruotato, letto da /run/secrets/stripe_key all’interno del container. Solo scrittura vale per gli esseri umani e la CLI; la tua app ottiene il testo in chiaro reale dove Docker lo promette.

Il colpo di scena del fork

Ricordi la trappola? Fai il fork del repo e guarda.

Passo 9: Fork del repo

rdc repo fork --parent my-app --tag test --machine <machine-name>

Passo 10: Il fork elenca vuoto

rdc repo secret list --name my-app:test

Vuoto.

Il fork non ha la chiave Stripe. Nessuna password del database. Nessun token API. I container nel fork non possono interpolare ${REDIACC_SECRET_STRIPE_KEY}. Il file in /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY non esiste.

Il fork non può fingersi te.

Passo 11: Il fork non riesce nemmeno ad avviarsi

rdc repo up --name my-app:test --machine <machine-name>

Il deploy fallisce di proposito: bind source path does not exist: /var/run/rediacc/secrets/<fork-id>/STRIPE_KEY. Il file del segreto si trova sotto l’ID di rete del parent, non del fork, quindi Docker rifiuta il mount. Il fallimento è la demo: le credenziali di produzione non seguono mai un fork, nemmeno per sbaglio.

Se vuoi segreti nel fork per i test, impostali esplicitamente nel fork con valori sandbox, ad esempio rdc repo secret set --name my-app:test --key STRIPE_KEY --value sk_sandbox_yyy --mode file. Ora il fork comunica con la sandbox di Stripe e si avvia correttamente. Le credenziali di produzione non hanno mai lasciato la produzione.

Riepilogo

• rdc repo secret mette le tue credenziali fuori dall’immagine del repo.
• Entrambe le modalità raggiungono davvero il container: interpolazione env e /run/secrets.
• get restituisce un digest, mai il valore. Ruota quando dimentichi; non spiare.
• Il fork elenca vuoto e non riesce nemmeno ad avviare il compose del parent.

Segreti che il fork non può seguire.

Successivo: Backup e Ripristino.