背景信息：使用一些自动扩展组和一些不可缩放的独立虚拟机来build立一个基础架构。 某些angular色需要秘密（私钥），这些秘密（私钥）应该限制在根目录或特定的用户。 pipe理是通过Puppet完成的（“无服务器” – configuration在git仓库中），Ansible也是可用的。
- 在Puppet或Git中join秘密是不可接受的，因为它们被广泛使用
- 在EC2用户数据中放入秘密限制了对特定虚拟机的访问，并且在自动扩展组中正确复制，但是虚拟机中的任何unix用户都可以访问。
- 将秘密放在安全的S3存储桶中是很多的工作，限制对特定虚拟机的访问，在自动扩展组中正确复制，在静止时对数据进行encryption，但是VM中的任何unix用户都可以访问 – 请参阅http：// blogs.aws.amazon.com/security/post/Tx2B3QUWAA7KOU/How-to-Manage-Secrets-for-Amazon-EC2-Container-Service-Based-Applications-by-Usi
- AWS KMS针对安全的S3存储桶进行了改进，但是我无法find有关在VM中访问其服务的任何限制。
我毫不怀疑Linux的用户权限是无懈可击的。 但是，只有Linux root用户才能将访问权限限制在…有用！ 🙂
我们find了一个可行的解决scheme：
- 使用保险柜或类似的pipe理实际的秘密，按angular色分组，用短密钥来解锁每一组秘密。
- 作为创build脚本的一部分，使用可脚本化的东西自动创build实例创build（即：Cloudformation，Terraform，aws cli）…
- 使用保险库密钥创build并填充短期存在的S3存储桶
- 通过EC2用户数据提供引导脚本，从S3存储桶获取保险库密钥
假设：
- S3存储桶的随机性阻止了（快速）发现
- 您的基础AMI是安全的，直到引导完成; 这意味着它并不是根深蒂固的;-)并且不会提供不安全/错误configuration的服务，使其在S3存储桶生命周期的短时间窗内成功受到攻击。
感谢@ceejayoz提供有用的提示。