When you embed a credential in an AMI, that credential travels with every copy of the image, stays etched into the snapshots and can end up in accounts or regions you never imagined. All it takes is somebody with read access to the image extracting it. And since images are kept by version, the secret can survive long after you believed you had rotated it.
The golden rule: the image defines the machine; secrets are delivered at runtime.
Where secrets should live
| Service | Cloud or environment | Ideal for |
|---|---|---|
| AWS Secrets Manager | AWS | Rotatable credentials, native integration |
| AWS SSM Parameter Store | AWS | Simple parameters and secrets, low cost |
| HashiCorp Vault | Multicloud | Dynamic secrets and fine-grained control |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Native equivalents on each cloud |
Keep secrets in a dedicated manager, never in the image nor in plaintext user-data.
The right pattern: identity, not passwords
The safest way for an instance to reach resources is not to give it a password, but to give it an identity. On AWS, an IAM role attached to the instance lets it obtain temporary, automatically rotated credentials, without any key travelling in the image.
- Instance IAM roles: the instance assumes a role and gets temporary credentials.
- IRSA on Kubernetes: per-pod identity, with no shared keys on the node.
- Dynamic secrets with Vault: short-lived credentials generated on demand.
- Runtime injection: the application reads the secret from the manager at start-up, not from a baked file.
Protect the metadata: IMDSv2
The role’s temporary credentials are obtained through the instance metadata service. An attacker exploiting an SSRF flaw could try to steal them. IMDSv2 requires a session token and mitigates that class of attack: make it mandatory on your launches.
Hygiene: leave no traces in the image
- Before sealing the AMI, delete shell histories, logs containing credentials, temporary SSH keys and configuration files with secrets.
- Scan the image for secrets with tools like gitleaks or trufflehog adapted to filesystems.
- Do not leave extra authorised keys in
~/.ssh/authorized_keys. - Avoid public AMIs with secrets: if you publish, check that you are leaking nothing.
Quick checklist
- Zero secrets baked into the image.
- Secrets manager with roles or federated identity.
- IMDSv2 mandatory.
- Secret scanning in the pipeline.
- Traces cleaned up before sealing.
Frequently asked questions
What if my application needs the secret at boot?
Have it read the secret from the secrets manager at runtime using the instance identity. That way the secret never travels inside the image and can be rotated without rebuilding.
Is it safe to use user-data to pass secrets?
Not in plain text: user-data is readable from the metadata. At most, use it to indicate which secret to pull from the manager, protecting the metadata with IMDSv2.
How do I detect whether an image already has baked-in secrets?
By scanning it with secret detection tools over its filesystem and reviewing configuration files, histories and authorised keys before using it.
At imaxe.cloud we build images free of credentials and designed to integrate with secrets managers and federated identity.
