Quand vous intégrez un identifiant dans une AMI, cet identifiant se propage avec chaque copie de l’image, reste gravé dans les snapshots et peut finir dans des comptes ou des régions que vous n’aviez jamais imaginés. Il suffit que quelqu’un ayant un accès en lecture à l’image l’en extraie. Et comme les images sont conservées par versions, le secret peut survivre bien après que vous avez cru l’avoir fait tourner.
La règle d’or : l’image définit la machine ; les secrets sont livrés à l’exécution.
Où les secrets doivent vivre
| Service | Cloud ou environnement | Idéal pour |
|---|---|---|
| AWS Secrets Manager | AWS | Identifiants rotatifs, intégration native |
| AWS SSM Parameter Store | AWS | Paramètres et secrets simples, faible coût |
| HashiCorp Vault | Multicloud | Secrets dynamiques et contrôle fin |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Équivalents natifs de chaque cloud |
Gardez les secrets dans un gestionnaire dédié, jamais dans l’image ni en clair dans user-data.
Le bon motif : l’identité, pas les mots de passe
La façon la plus sûre pour qu’une instance accède à des ressources n’est pas de lui donner un mot de passe, mais une identité. Sur AWS, un rôle IAM associé à l’instance lui permet d’obtenir des identifiants temporaires, renouvelés automatiquement, sans qu’aucune clé ne voyage dans l’image.
- Rôles IAM d’instance : l’instance endosse un rôle et obtient des identifiants temporaires.
- IRSA sur Kubernetes : identité par pod, sans clés partagées sur le nœud.
- Secrets dynamiques avec Vault : identifiants de courte durée générés à la demande.
- Injection à l’exécution : l’application lit le secret dans le gestionnaire au démarrage, pas dans un fichier intégré.
Protégez les métadonnées : IMDSv2
Les identifiants temporaires du rôle s’obtiennent via le service de métadonnées de l’instance. Un attaquant exploitant une faille SSRF pourrait tenter de les voler. IMDSv2 exige un jeton de session et limite cette classe d’attaques : rendez-le obligatoire sur vos lancements.
Hygiène : ne laissez pas de traces dans l’image
- Avant de sceller l’AMI, effacez les historiques de shell, les logs contenant des identifiants, les clés SSH temporaires et les fichiers de configuration avec secrets.
- Analysez l’image à la recherche de secrets avec des outils comme gitleaks ou trufflehog adaptés aux systèmes de fichiers.
- Ne laissez pas de clés autorisées superflues dans
~/.ssh/authorized_keys. - Évitez les AMI publiques contenant des secrets : si vous publiez, vérifiez que rien ne fuit.
Checklist rapide
- Zéro secret intégré dans l’image.
- Gestionnaire de secrets avec rôles ou identité fédérée.
- IMDSv2 obligatoire.
- Analyse de secrets dans le pipeline.
- Nettoyage des traces avant le scellement.
Questions fréquentes
Et si mon application a besoin du secret au démarrage ?
Qu’elle le lise dans le gestionnaire de secrets à l’exécution, via l’identité de l’instance. Ainsi le secret ne voyage jamais dans l’image et peut être renouvelé sans reconstruction.
Est-il sûr d’utiliser user-data pour passer des secrets ?
Pas en clair : user-data est lisible depuis les métadonnées. Utilisez-le tout au plus pour indiquer quel secret aller chercher dans le gestionnaire, en protégeant les métadonnées avec IMDSv2.
Comment détecter si une image contient déjà des secrets intégrés ?
En l’analysant avec des outils de détection de secrets sur son système de fichiers et en passant en revue fichiers de configuration, historiques et clés autorisées avant usage.
Chez imaxe.cloud, nous construisons des images sans identifiants, pensées pour s’intégrer aux gestionnaires de secrets et à l’identité fédérée.
