Secrets Management: HashiCorp Vault, AWS Secrets Manager e GitHub Secrets – Guida Operativa per Sviluppatori

Se il tuo database ha la password in un file .env sul server, non è questione di se venga esposta, ma di quando. Lo vediamo ogni giorno nei progetti che ci vengono in revisione: chiavi API hardcoded, token in chiaro nei repo, credenziali di produzione sparse in decine di posti. Non serve un hacker sofisticato: basta una build CI male configurata o un repository pubblico per scatenare fughe di dati che costano milioni.

Noi, di Meteora Web, lavoriamo da anni con server e pipeline DevSecOps. Abbiamo visto il caos che genera l’assenza di una strategia per i secrets. E abbiamo costruito soluzioni su HashiCorp Vault, AWS Secrets Manager e GitHub Secrets che funzionano davvero. Questa guida è un’immersione pratica nel secrets management: strumenti, comandi, esempi reali. Se ti mancano le basi della sicurezza cloud, parti dalla nostra Pillar Guide su Sicurezza Cloud e DevSecOps.

Perché i secrets sono il tallone d’Achille della sicurezza cloud

Un secret è tutto ciò che non deve essere pubblico: password di database, token OAuth, chiavi SSH, certificati, API key. Il problema è che negli ambienti cloud moderni i secrets si moltiplicano: microservizi, container, CI/CD, serverless. Gestirli a mano è un incubo.

Errori comuni che abbiamo incontrato decine di volte:

• File .env nei repository (anche privati, ma basta un collaboratore distratto)
• Password in variabili d’ambiente hardcodate nei Dockerfile
• Token di servizio condivisi via chat o email
• Nessuna rotazione automatica
• Backup di database con credenziali in chiaro

Il costo? Non solo economico: il tempo per un incident response decuplica quando non sai dove sono i secrets. E la fiducia del cliente vola via in un attimo.

La soluzione è un sistema centralizzato di secrets management: un unico pannello di controllo, con accessi tracciati, scadenza automatica e rotazione. Tre strumenti leader oggi sono HashiCorp Vault, AWS Secrets Manager e GitHub Secrets. Ognuno ha il suo posto. Vediamoli nel dettaglio.

HashiCorp Vault: il punto di controllo centrale

Vault è molto più di un cassetto per password. È un sistema che può generare secrets al volo (dynamic secrets), crearli con scadenza, revocarli, e crittografare dati in transito via Transit Engine. Noi lo usiamo su progetti multi-cloud e Kubernetes.

Installazione rapida per test

# Scarica e avvia Vault in development mode (MAI in produzione senza TLS e HA)
vault server -dev

Il server restituisce un Root Token e il Unseal Key.

Scrivere e leggere un secret

export VAULT_ADDR='http://127.0.0.1:8200'
export VAULT_TOKEN='il-tuo-token'

# Scrive un secret in path /secret/produzione/db
vault kv put secret/produzione/db username=dbuser password=S3cur3P@ss

# Legge il secret
vault kv get secret/produzione/db

Dynamic Database Secrets (PostgreSQL)

Vault può creare credenziali temporanee per il database, valide solo per il tempo necessario. Esempio con PostgreSQL:

# Configura il mount del database
vault secrets enable database

# Configura la connessione a PostgreSQL
vault write database/config/postgresql-db \
    plugin_name=postgresql-database-plugin \
    allowed_roles="*" \
    connection_url="postgresql://{{username}}:{{password}}@host:5432/db" \
    username="vault_admin" \
    password="password_admin"

# Crea un ruolo che genera credenziali valide 1 ora
vault write database/roles/dynamic-reader \
    db_name=postgresql-db \
    creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
    default_ttl="1h" \
    max_ttl="24h"

# Richiedi credenziali (il tuo CI/CD può farlo)
vault read database/creds/dynamic-reader

Risultato: password usa e getta, revoca automatica alla scadenza. Niente più credenziali fisse nei file di configurazione.

Transit Engine per crittografare dati

Vault può fungere da servizio di crittografia centralizzato. Il tuo codice invia dati da cifrare/decifrare senza mai vedere le chiavi.

vault secrets enable transit
vault write -f transit/keys/my-key

# Cifra
vault write transit/encrypt/my-key plaintext=$(base64 <<< "dato sensibile")
# Decifra
vault write transit/decrypt/my-key ciphertext="vault:v1:..."

Perché conviene? Un singolo punto di rotazione delle chiavi senza dover aggiornare ogni applicazione.

Link utente: Documentazione ufficiale HashiCorp Vault

AWS Secrets Manager: il gestore nativo per AWS

Se vivi dentro AWS, Secrets Manager è la scelta più integrata. Gestisce automaticamente la rotazione per RDS, Redshift, DocumentDB, e può essere richiamato via SDK senza dover gestire un cluster Vault.

Creare un secret da CLI

aws secretsmanager create-secret \
    --name prod/db \
    --secret-string '{"username":"dbuser","password":"S3cur3P@ss"}'

Recuperare un secret in Lambda (Python)

import boto3
import json
from botocore.exceptions import ClientError

def get_secret():
    secret_name = "prod/db"
    region_name = "eu-west-1"
    session = boto3.session.Session()
    client = session.client(
        service_name='secretsmanager',
        region_name=region_name
    )
    try:
        response = client.get_secret_value(SecretId=secret_name)
        secret = json.loads(response['SecretString'])
        return secret
    except ClientError as e:
        raise e

Rotazione automatica

Secrets Manager può invocare una funzione Lambda per ruotare la password ogni X giorni. AWS fornisce template già pronti per RDS. Noi suggeriamo di abilitare la rotazione immediatamente dopo la creazione del secret.

aws secretsmanager rotate-secret \
    --secret-id prod/db \
    --rotation-lambda-arn arn:aws:lambda:... \
    --rotation-rules AutomaticallyAfterDays=30

Quando usarlo? Per carichi di lavoro interamente su AWS, con bisogno di integrazione nativa e senza la complessità di Vault.

Link utente: AWS Secrets Manager User Guide

GitHub Secrets: custodire i segreti delle pipeline CI/CD

Il nemico numero 1 delle pipeline CI/CD sono i secrets hardcodati negli YAML. GitHub Secrets (e le variabili d’ambiente criptate) permettono di iniettare credenziali nei workflow senza mai esporle nel codice.

Livelli di gestione

• Repository secrets: visibili a tutti i workflow del repo.
• Environment secrets: legati a uno specifico environment (prod/staging) – protezione extra con required reviewers.
• Organization secrets: condivisi tra più repo, accessibili solo a team autorizzati.

Esempio di workflow GitHub Actions

name: Deploy to production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: Deploy
        run: |
          echo "Connecting to server..."
          ssh user@${{ secrets.DEPLOY_HOST }} << 'EOF'
            docker pull myapp:latest
            docker compose up -d
          EOF
        env:
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}

Importante: i secrets sono offuscati nei log, ma evita di stamparli intenzionalmente. Usa sempre secrets.CHAVE e non stringhe in chiaro.

Best practice

• Organizza i secrets per environment (dev, staging, prod) con permessi separati.
• Non riutilizzare lo stesso secret per più ambienti.
• Per pipeline più complesse, integra con Vault (es. vault-action) per dynamic secrets.

Link utente: GitHub Docs – Using secrets in GitHub Actions

Strategia ibrida: quando usare cosa?

Nella pratica, nessuno strumento basta da solo. Ecco il nostro schema mentale:

Scenario	Strumento consigliato
Multi-cloud / on-premise + cloud	Vault centralizzato
Tutto su AWS	AWS Secrets Manager + Vault per dynamic secrets avanzati
CI/CD su GitHub	GitHub Secrets + Vault per operazioni temporanee
Microservizi su Kubernetes	Vault + CSI driver per iniezione automatica

Regola d’oro: mai hardcodare, mai condividere, mai non ruotare. Ogni secret dovrebbe avere una scadenza.

In sintesi – cosa fare adesso

1. Audit completo: cerca in tutti i repository, server e backup eventuali secrets in chiaro. Strumenti come truffleHog o git-secrets ti aiutano.
2. Scegli il tuo gestore: per progetti nuovi, parti con Vault se sei multi-cloud o vuoi dynamic secrets; altrimenti AWS SM.
3. Abilita la rotazione: non rimandare. Imposta una rotazione automatica di 30 o 90 giorni.
4. Integra con la CI/CD: sposta tutti i secrets delle pipeline in GitHub Secrets (o secret manager equivalente per GitLab, Bitbucket).
5. Forma il team: un solo membro che fa un commit con un token costa più di mezza giornata di remediation.

I secrets sono il sangue della tua infrastruttura. Trattali come tali. E se hai bisogno di una mano per impostare il sistema giusto, passare dal caos a un ambiente gestito – noi di Meteora Web lo facciamo tutti i giorni. Parti dalla Pillar Guide su Sicurezza Cloud e DevSecOps e, se vuoi, contattaci.