当你把一份凭据嵌进 AMI，它就会随着镜像的每一次复制而扩散、被刻进快照，并可能出现在你从未 设想过的账户或区域里。只要有人对镜像有读权限，就能把它抠出来。而由于镜像是按版本保存的， 这个机密可能在你以为早就轮换掉之后，依然活得好好的。
黄金法则：镜像定义机器；机密在运行时交付。
机密该住在哪里
| 服务 | 云或环境 | 适合场景 |
|---|---|---|
| AWS Secrets Manager | AWS | 可轮换的凭据，原生集成 |
| AWS SSM Parameter Store | AWS | 简单参数与机密，成本低 |
| HashiCorp Vault | 多云 | 动态机密与精细控制 |
| Azure Key Vault / Google Secret Manager | Azure / GCP | 各云的原生对应物 |
把机密放进专用的管理器，绝不要放进镜像，也不要以明文放进 user-data。
正确的模式：用身份，而不是密码
让实例访问资源，最安全的方式不是给它一个密码，而是给它一个身份。在 AWS 上，绑定到实例 的 IAM 角色能让它取得临时且自动轮换的凭据，而不必让任何密钥随镜像旅行。
- 实例 IAM 角色：实例扮演某个角色并获得临时凭据。
- Kubernetes 上的 IRSA：按 Pod 授予身份，节点上不留共享密钥。
- Vault 的动态机密：按需生成的短生命周期凭据。
- 运行时注入：应用在启动时从管理器读取机密，而不是从烘焙进去的文件里读。
保护元数据：IMDSv2
角色的临时凭据是通过实例元数据服务获取的。利用 SSRF 漏洞的攻击者可能试图窃取它们。 IMDSv2 要求会话令牌，能缓解这一类攻击：在你的启动配置中把它设为强制。
卫生：不要在镜像里留下痕迹
- 封存 AMI 之前，删除 shell 历史、含凭据的日志、临时 SSH 密钥，以及带机密的配置文件。
- 用 gitleaks、trufflehog 之类适配文件系统的工具扫描镜像中的机密。
- 不要在
~/.ssh/authorized_keys里留下多余的已授权密钥。 - 避免发布带机密的公开 AMI：如果你要发布，务必确认没有任何东西外泄。
快速检查清单
- 镜像中零烘焙机密。
- 使用机密管理器，配合角色或联合身份。
- IMDSv2 设为强制。
- 流水线中做机密扫描。
- 封存前清理痕迹。
常见问题
如果我的应用在启动时就需要机密怎么办？
让它在运行时用实例身份从机密管理器读取。这样机密永远不会随镜像旅行，也能在不重建的情况下 轮换。
用 user-data 传机密安全吗？
明文不安全：user-data 可从元数据读到。最多用它来指明该从管理器取哪一份机密，同时用 IMDSv2 保护元数据。
怎么发现一份镜像里是否已经烘焙了机密？
用机密检测工具扫描它的文件系统，并在使用前逐一检查配置文件、历史记录与已授权密钥。
在 imaxe.cloud，我们构建的镜像不含任何凭据，并且从设计上就便于与机密管理器和联合身份集成。
机密vaultiamimdsv2secrets manager
