您要求将 CloudFormation 的执行角色限制为仅需要的命令绝对是最佳实践,并且在 CloudFormation 控制台中,当您启动模板时,“权限”选项会显示:
选择一个 IAM 角色以明确定义 CloudFormation 如何在堆栈中创建、修改或删除资源。如果您不选择角色,CloudFormation 会根据您的用户凭据使用权限。
这就是说,在部署您的模板时,CloudFormation 可以使用您的用户权限来部署您的模板中定义的服务,或者根据最佳实践和最低权限原则,CloudFormation 可以承担一个已设计和定义的角色具有特定于此特定模板的权限。这是最佳实践,因为我们希望确定正在使用和执行的服务和资源。
有几种方法可以实现您的目标,即确定 CloudFormation 部署模板所需的权限。在您的情况下,我想您有很多资源,因此这似乎是一项艰巨的任务,需要几个月的时间才能弄清楚,但实际情况是只需要几个小时。我会建议两种方法来实现这一点......让我们开始吧:
命令行界面
- 从我的 CLI 创建一个没有权限的新角色。请务必创建信任关系以允许 CloudFormation 代入该角色。
- 创建一个新的空白策略文档并将该策略附加到您刚刚创建的角色。
iam:PutRolePolicy
为我刚刚创建的新策略添加一个 ALLOW 。
- 从 CLI 承担新角色,以便您继续使用该角色
创建一个 bash 脚本,该脚本将重复尝试部署 CloudFormation 模板,直到成功部署为止。假设模板格式正确,每次脚本尝试部署模板时都会收到权限错误,因为在步骤 2 中假定的角色没有正确的权限。该错误将类似于:
ClientError: An error occurred (AccessDeniedException) when calling the xxxxxxxxxxxx operation: User: arn:aws:sts::[ACCOUNT-NUMBER]:assumed-role/[my-Role-Name]/[Logged In Username] is not authorized to perform: iam:PassRole on resource: xxxxxxxxxxxxx
在上面的示例中,我们的模板需要执行iam:PassRole
,但假定的角色没有执行此操作的权限,因此出现错误。为了解决这个问题,让脚本iam:PassRole
从错误中解析(即它需要的权限),然后通过命令(此处的语法和完整要求)将iam:PassRole
内联策略添加到上面步骤 2 中创建的角色中。aws iam put-role-policy
将策略附加到 IAM 角色后,脚本应循环返回并尝试再次部署模板。它应该一直这样做,直到模板成功部署,或者直到它收到一些其他不相关的错误并且它完全停止执行。成功部署后,您现在将拥有一个角色,该角色具有通过内联策略部署模板所需的确切权限。
注意 1:根据您的帐户设置和/或模板中的资源数量,您可能很容易发现自己达到了权限边界或超出了策略大小限制,这些超出了本问题的范围,但您可能会发现自己需要解决这些问题问题。
注意 2:可以肯定的是,这是一种潜在的危险技术,这种脚本只能在开发环境中运行,以防止出现意外结果。如果您无意中在 CloudFormation 模板中进行了破坏性操作并在生产帐户中运行它,则此类脚本可能会导致灾难事件;谨慎的做法是只在开发人员中运行这样的脚本,这样您就可以查看创建的所有权限,确定您是否有任何意外或不需要的操作/权限,然后您可以制作适当的角色和具有必要权限的生产帐户中的部署策略。
CloudTrail 与基于控制台的部署
一种不太先进的方法是在非生产帐户中使用 CloudTail 来审核 CloudFormation 使用的权限并从中制定策略(实际上是您问题中的第二个选项)。我不知道有任何现成的脚本可以解析 CloudTrail 日志和创建策略文档,但是手动执行并不困难,也可以编写脚本。尽管如此,如果你确实选择了这个选项,在这个阶段,我建议你坚持使用控制台,因为你很快就能看到你需要什么。
- 使用具有管理员权限的用户登录到非生产帐户
- 前往 CloudFormation 并使用登录用户权限(即管理员)部署模板
- 部署完成后,前往 CloudTrail 查找该用户在部署期间使用的所有权限;按 过滤列表
User name
,然后从事件中您将能够看到使用了哪些权限。
- 制定具有 CloudFormation 使用的权限的策略
- 采用该策略并将其添加到 CloudFormation 将在生产账户中使用的部署角色
根据您的 bash 脚本技能,这两个选项应该花费大约相同的时间;几个小时,甚至一天,绝对不是几个月。
祝你好运!