使用 IAM 角色真的比在磁盘上存储加密凭证更安全吗？

Question

使用 IAM 角色被认为是获取 EC2 实例凭证的首选方式，以便它可以与 AWS API 进行通信。我知道密钥是临时的并且会轮换，这比使用存储在磁盘上的凭据有明显的优势。然而，它引入了另一个严重的安全问题，通过在磁盘上使用加密凭据可以避免这个问题。

如果我的凭据位于文件系统上，我可以使用文件系统的内置权限机制来阻止除需要密钥的进程之外的任何进程读取它们。在这种情况下，如果有人利用以不同于需要访问 AWS API 的用户身份运行的软件中的某些漏洞来破坏实例，他将无法读取包含凭证的文件（由操作系统强制执行）。（我没有考虑他可以提升到 root 访问权限的情况，在这种情况下，所有的赌注都会被取消）。

但是，当使用 IAM 角色时，可以通过网络调用获取凭证：

http://169.254.169.254/latest/meta-data/iam/security-credentials/*. 

任何进程，甚至那些几乎具有零权限的进程都可以对此 URL 执行 wget（或curl 等），并拥有可供使用的凭据。事实上，它们的轮换并没有让这种情况变得更加安全。

我可以轻易想到的唯一补救措施是本地防火墙来限制哪些进程可以访问 IP 地址 169.254.169.254。这看起来笨重且不优雅。

使用 IAM 角色时是否有推荐的方法来解决此安全问题？

Answer 1

考虑 IAM 角色的方法是将权限授予实例，而不是进程或用户。如果您的实例具有不应拥有权限的用户或进程，则您不应通过 IAM 角色提供该权限。

我们通常不会将实例用作通用机器，而仅用于特定的应用程序目的。对于该用例，IAM 角色比创建具有固定凭证的 IAM 用户并将凭证放在实例上要好得多。在任何一种情况下，接管该实例的入侵者都可以将其用于我们授予该实例的任何权限。但有了角色，入侵者就无法拿走这些凭据并在较长时间内单独使用它们，因为凭据会过期并且经常轮换。入侵者必须保持实例的所有权和存在才能危及角色，如果入侵者能够做到这一点，那么您无论如何都会失去所有安全性。

我们还通过 CloudFormation 堆栈创建 IAM 角色和新实例，这使得每个实例都拥有其所需的权限，而不是所有同类实例的通用权限集。