IAM Roles的使用被吹捧为获取EC2实例凭据的首选方式，因此它可以与AWS API通信。我知道密钥是临时的并且被轮换，这比使用存储在磁盘上的凭证明显有利。但是，它引入了另一个严重的安全问题，可以通过在磁盘上使用加密凭据来避免。
如果我的凭据在文件系统上，我可以使用文件系统的内置权限机制来阻止任何进程，但需要密钥才能读取它们。在这种情况下，如果有人使用软件中的某些漏洞来破坏实例，该软件作为与需要访问AWS API的用户不同的用户运行，则他无法读取包含凭据的文件（由OS强制执行）。 （我不考虑他可以提升到root访问权限的情况，在这种情况下所有的赌注都已关闭）。
但是，在使用IAM角色时，凭据可通过以下网络呼叫获得：
http://169.254.169.254/latest/meta-data/iam/security-credentials/*.
任何进程，即使是那些几乎没有权限的进程，也可以对此URL执行wget（或curl等）并拥有可随时使用的凭据。它们旋转的事实并没有使这种情况更加安全。
我可以在这里找到的唯一补救措施是使用本地防火墙来限制哪些进程可以访问IP地址169.254.169.254。这看起来很笨拙而且不够优雅。
使用IAM角色时是否有推荐的方法来解决此安全问题？
答案 0 :(得分：1)
考虑IAM角色的方法是为实例提供权限，而不是为进程或用户提供权限。如果您的实例具有不应具有权限的用户或进程，则不应通过IAM角色提供该权限。
我们通常不将实例用作通用机器，而仅用于特定的应用目的。对于该用例，IAM角色比创建具有固定凭据的IAM用户并将凭证放在实例上要好得多。在任何一种情况下，接管实例的入侵者都可以将它用于我们为该实例提供的任何特权。但是，如果有角色，入侵者就无法取走这些凭据并在较长时间内单独使用它们，因为凭据过期并经常轮换。入侵者必须在实例上维护所有权和存在以破坏角色，如果入侵者能够做到这一点，那么你无论如何都会失去所有安全性。
我们还通过CloudFormation堆栈创建IAM角色以及新实例，这允许每个实例具有完全所需的权限，而不是所有其类型实例的一般权限集。 / p>