请帮助我理解为什么 AWS 建议将角色分配给 EC2 实例("基于角色的方法") 过度将 API 密钥存储在实例上的文件中("基于文件的方法")？
考虑三个用例： (i) 运行 Web 应用程序的实例上有一个"tomcat"帐户。该应用程序不使用 AWS API。 实例上还有另一个账户("支持")使用 AWS API 进行内务管理和维护 (日志、指标等)。
使用基于文件的方法，如果攻击者利用应用程序并访问文件系统(如"tomcat")， 他们将无法读取凭证文件(只能由"支持"读取)，也无法进行 AWS API 调用。 如果攻击者在"tomcat"帐户下执行任意代码，情况也是如此。
但是，使用基于角色的方法，如果攻击者可以访问文件系统，则一无所获。 (因为根本没有凭证文件)，并且他们无法调用 AWS API。但是，如果攻击者可以执行任意代码 他们可以调用 API。
(ii) 有一个运行 Web 应用程序的"tomcat"帐户。应用程序调用 AWS API 进行操作。 还有另一个账户("支持")使用 AWS API 进行内务管理和维护。 两个帐户都需要访问不同的资源(例如。"tomcat"需要 S3，而"支持"需要日志和指标)。
在基于角色的方法中，分配给实例的角色将有效地包含权限的并集 需要"雄猫"和"支持"，这违背了最小特权原则。即使权限是 从技术上讲，每个帐户在两个角色之间划分，最终将能够承担它并不真正需要的角色。
使用基于文件的方法，如果攻击者获得对文件系统的访问权限，他们将能够读取"tomcat" 凭据并从另一台计算机进行 API 调用(这可以通过限制策略来避免 到特定的源 IP，尽管维护起来很麻烦)。如果攻击者可以执行任意命令 代码中，他们将能够从 EC2 实例进行 API 调用。在这两种情况下，"支持"帐户都将保留 受操作系统保护。
使用基于角色的方法，如果攻击者获得对文件系统的访问权限，则在 API 调用方面一无所获， 因为根本没有凭据文件。但是，如果攻击者执行任意代码，他们可以进行 API 调用 来自 instace 代表两个角色("雄猫"和"支持")。
(iii) 有一个运行 Web 应用程序的"tomcat"帐户。应用程序调用 AWS API 进行操作。 不会从实例进行其他 API 调用。
使用基于文件的方法，如果攻击者获得对文件系统的访问权限，他们将能够读取"tomcat" 凭据并从另一台计算机进行 API 调用(这可以通过限制策略来避免 到特定的源 IP，尽管维护起来很麻烦)。如果攻击者可以执行任意命令 代码中，他们将能够从 EC2 实例进行 API 调用。
使用基于角色的方法，如果攻击者获得对文件系统的访问权限，则在 API 调用方面一无所获， 因为根本没有凭据文件。但是，如果攻击者执行任意代码，他们可以进行 API 调用 从实例。
因此，似乎推荐的基于角色的方法实际上增加了案例(i)和(ii)的风险。
我在这里错过了什么？
如果您在 Amazon EC2 实例上有多个用户集，每个用户组需要不同的 IAM 权限，则不宜通过向EC2 实例分配 IAM 角色来提供凭证。
通常，建议使用 Role 方法，因为凭据不存储在任何位置。存储在磁盘上的凭据有时会意外签入源代码存储库。能够创建磁盘卷快照的用户也可以访问它们，然后他们可以将其附加到其他实例以访问配置文件并避免正常安全性。这表明，仅向 IAM 用户授予其工作所需的特定权限(而不是更多权限)来使用最小权限也很重要。
将角色分配给实例需要ec2:PassRole权限，因此还必须谨慎授予此权限，以确保用户不会为自己分配授予过多访问权限的角色来访问 AWS 服务。
底线：您一直在考虑安全性，这真是太好了。遵循您认为最适合您的业务需求的过程。