Quando incorpori una credenziale in una AMI, quella credenziale si propaga con ogni copia dell’immagine, resta impressa negli snapshot e può finire in account o regioni che non avresti mai immaginato. Basta che qualcuno con accesso in lettura all’immagine la estragga. E poiché le immagini si conservano per versioni, il segreto può sopravvivere molto dopo che credevi di averlo ruotato.
La regola d’oro: l’immagine definisce la macchina; i segreti si consegnano a runtime.
Dove devono vivere i segreti
| Servizio | Cloud o ambiente | Ideale per |
|---|---|---|
| AWS Secrets Manager | AWS | Credenziali ruotabili, integrazione nativa |
| AWS SSM Parameter Store | AWS | Parametri e segreti semplici, basso costo |
| HashiCorp Vault | Multicloud | Segreti dinamici e controllo fine |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Equivalenti nativi in ogni cloud |
Conserva i segreti in un gestore dedicato, mai nell’immagine né in user-data in chiaro.
Il modello corretto: identità, non password
Il modo più sicuro perché un’istanza acceda alle risorse non è darle una password, ma darle un’identità. In AWS, un ruolo IAM associato all’istanza le permette di ottenere credenziali temporanee e ruotate automaticamente, senza che nessuna chiave viaggi nell’immagine.
- Ruoli IAM di istanza: l’istanza assume un ruolo e ottiene credenziali temporanee.
- IRSA su Kubernetes: identità per pod, senza chiavi condivise sul nodo.
- Segreti dinamici con Vault: credenziali di breve durata generate su richiesta.
- Iniezione a runtime: l’applicazione legge il segreto dal gestore all’avvio, non da un file incorporato.
Proteggi i metadati: IMDSv2
Le credenziali temporanee del ruolo si ottengono tramite il servizio di metadati dell’istanza. Un attaccante che sfrutti una falla SSRF potrebbe provare a rubarle. IMDSv2 richiede un token di sessione e mitiga quella classe di attacchi: rendilo obbligatorio nei tuoi avvii.
Igiene: non lasciare tracce nell’immagine
- Prima di sigillare la AMI, cancella cronologie di shell, log con credenziali, chiavi SSH temporanee e file di configurazione con segreti.
- Scansiona l’immagine in cerca di segreti con strumenti come gitleaks o trufflehog adattati ai filesystem.
- Non lasciare chiavi autorizzate di troppo in
~/.ssh/authorized_keys. - Evita AMI pubbliche con segreti: se pubblichi, verifica di non far trapelare nulla.
Checklist rapida
- Zero segreti incorporati nell’immagine.
- Gestore di segreti con ruoli o identità federata.
- IMDSv2 obbligatorio.
- Scansione di segreti nella pipeline.
- Pulizia delle tracce prima di sigillare.
Domande frequenti
E se la mia applicazione ha bisogno del segreto all’avvio?
Che lo legga dal gestore di segreti a runtime usando l’identità dell’istanza. Così il segreto non viaggia mai nell’immagine e si può ruotare senza ricostruire.
È sicuro usare user-data per passare segreti?
Non in chiaro: user-data è leggibile dai metadati. Usalo al massimo per indicare quale segreto prelevare dal gestore, proteggendo i metadati con IMDSv2.
Come rilevo se un’immagine ha già segreti incorporati?
Scansionandola con strumenti di rilevamento di segreti sul suo filesystem e rivedendo file di configurazione, cronologie e chiavi autorizzate prima di usarla.
In imaxe.cloud costruiamo immagini prive di credenziali e pensate per integrarsi con gestori di segreti e identità federata.
