07 - Secret Management - Automazione e Rotazione di Credenziali

Secret Management: Il Problema dei Segreti nel Software

I secret (credenziali, API key, certificati, token di accesso) sono gli elementi più sensibili di un'infrastruttura software. Un singolo secret esposto può compromettere interi sistemi, database e account cloud. Secondo le ricerche di GitGuardian, nel 2024 sono stati trovati oltre 12 milioni di secret esposti nei repository pubblici su GitHub.

Il secret management non e solo "non committare le password nel codice". E un sistema completo che copre la generazione, lo storage sicuro, la distribuzione, la rotazione e la revoca dei secret durante tutto il loro ciclo di vita.

Anti-Pattern: Come NON Gestire i Secret

Prima di esplorare le soluzioni, vediamo gli errori più comuni che portano all'esposizione di credenziali:

• Hardcoded nel codice: password e API key scritte direttamente nel codice sorgente
• File .env nel repository: file di configurazione con secret committati per errore
• Variabili d'ambiente non protette: secret passati come env var senza encryption
• Secret condivisi via chat: credenziali inviate su Slack, Teams o email
• Secret mai ruotati: credenziali statiche che non vengono mai cambiate
• Permessi troppo ampi: API key con accesso a tutti i servizi invece del minimo necessario

HashiCorp Vault: Il Reference Standard

HashiCorp Vault e la soluzione più diffusa per il secret management enterprise. Offre storage sicuro, accesso controllato, audit logging e supporto per la rotazione dinamica dei secret. Vault può generare credenziali on-demand con TTL limitato, eliminando il problema dei secret statici.

Setup Vault con Docker

# docker-compose.vault.yml
version: "3.8"
services:
  vault:
    image: hashicorp/vault:1.15
    container_name: vault
    ports:
      - "8200:8200"
    environment:
      VAULT_DEV_ROOT_TOKEN_ID: "dev-root-token"
      VAULT_DEV_LISTEN_ADDRESS: "0.0.0.0:8200"
    cap_add:
      - IPC_LOCK
    volumes:
      - vault-data:/vault/data

volumes:
  vault-data:
      

Operazioni Base con Vault CLI

# Configurare il client
export VAULT_ADDR="http://127.0.0.1:8200"
export VAULT_TOKEN="dev-root-token"

# Abilitare il secrets engine KV v2
vault secrets enable -version=2 kv

# Scrivere un secret
vault kv put kv/myapp/database \
  username="dbadmin" \
  password="super-secret-password" \
  host="db.internal.company.com"

# Leggere un secret
vault kv get kv/myapp/database

# Leggere un campo specifico
vault kv get -field=password kv/myapp/database

# Creare una policy di accesso
vault policy write myapp-read - <<EOF
path "kv/data/myapp/*" {
  capabilities = ["read", "list"]
}
EOF

# Creare un token con policy limitata
vault token create -policy=myapp-read -ttl=1h
      

Dynamic Secrets: Credenziali On-Demand

Una delle feature più potenti di Vault sono i dynamic secrets: credenziali generate al momento della richiesta con un TTL limitato. Quando il TTL scade, Vault revoca automaticamente le credenziali. Questo elimina il problema dei secret statici.

# Abilitare il database secrets engine
vault secrets enable database

# Configurare la connessione PostgreSQL
vault write database/config/mydb \
  plugin_name=postgresql-database-plugin \
  allowed_roles="readonly" \
  connection_url="postgresql://{{username}}:{{password}}@db:5432/mydb?sslmode=disable" \
  username="vault_admin" \
  password="vault_admin_password"

# Creare un ruolo con credenziali dinamiche
vault write database/roles/readonly \
  db_name=mydb \
  creation_statements="CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}'; GRANT SELECT ON ALL TABLES IN SCHEMA public TO \"{{name}}\";" \
  default_ttl="1h" \
  max_ttl="24h"

# Ottenere credenziali dinamiche
vault read database/creds/readonly
      

AWS Secrets Manager

Per le organizzazioni che operano su AWS, AWS Secrets Manager offre un servizio managed per il secret management con rotazione automatica integrata, supporto nativo per RDS, Redshift e DocumentDB, e integrazione trasparente con i servizi AWS.

Secret Detection nei Repository

La prevenzione e la prima linea di difesa. Gli strumenti di secret detection analizzano il codice alla ricerca di credenziali esposte prima che raggiungano il repository remoto.

GitLeaks: Pre-Commit Hook

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks

# .gitleaks.toml - configurazione personalizzata
[extend]
useDefault = true

[[rules]]
id = "custom-api-key"
description = "Custom API Key pattern"
regex = '''MYAPP_API_KEY\s*=\s*['"]([A-Za-z0-9_-]+)['"]'''
secretGroup = 1
entropy = 3.5

[allowlist]
paths = [
  '''test/.*''',
  '''.*_test\.go''',
  '''.*\.md'''
]
      

Integrazione in CI/CD

# .github/workflows/secret-detection.yml
name: Secret Detection
on:
  push:
    branches: [main, develop]
  pull_request:

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: GitLeaks scan
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      

Strategie di Rotazione

La rotazione dei secret e il processo di sostituzione periodica delle credenziali. La rotazione riduce la finestra di esposizione in caso di compromissione e limita il danno di secret leaked che non sono stati ancora scoperti.

• Rotazione automatica: servizi come AWS Secrets Manager possono ruotare automaticamente le credenziali a intervalli configurabili
• Dynamic secrets: Vault genera credenziali con TTL limitato, eliminando la necessità di rotazione
• Rotazione manuale pianificata: per secret che non possono essere ruotati automaticamente, pianificare rotazione trimestrale
• Rotazione d'emergenza: procedura per revocare e ruotare tutti i secret in caso di breach

Best Practice per Secret Management

1. Mai nel codice: zero secret nel codice sorgente, nei file di configurazione o nei container image
2. Centralizzare: un unico sistema di secret management per tutta l'organizzazione
3. Least privilege: ogni applicazione accede solo ai secret di cui ha bisogno
4. Audit logging: registrare ogni accesso ai secret per compliance e forensics
5. Rotazione automatica: implementare rotazione per tutti i secret con TTL massimo 90 giorni
6. Pre-commit hooks: GitLeaks o TruffleHog come pre-commit per bloccare secret prima del push
7. Encryption at rest: i secret devono essere criptati quando non in uso

Conclusioni

Il secret management e uno dei pilastri più critici di DevSecOps. Un secret esposto può vanificare tutti gli altri investimenti in sicurezza. La combinazione di storage sicuro (Vault), detection preventiva (GitLeaks) e rotazione automatica crea un sistema di difesa robusto contro la compromissione delle credenziali.

Nel prossimo articolo esploreremo Policy as Code, analizzando come definire e applicare automaticamente le policy di sicurezza con OPA/Rego, Kyverno e Sentinel.