我可以从模板中为CloudFormation栈AutoCreate一个IAM角色吗？

Question

我被告知要将我的Cloudformation限制为只使用它需要的命令。有自己的角色。为了创建角色，我可以花几个月的时间浏览我的模板，以确定启动EC2实例实际上涉及10个不同的IAM项目(如创建标签、网络接口、卷等)。为我所有的资源找出所有有问题的ARN，以此类推。(因为这些资源还没有创建，所以我需要很多*才能让这个角色在下一次有用。)

或者，有没有工具可以帮我做到这一点？我想象一下，提供我的模板和工具，让角色的大部分消失。可能需要对模板根据参数执行操作的位置进行一些更改。

或者，如果我在打开Cloudtrail的情况下创建堆栈，是否有工具可以将cloudtrail日志转换为策略文档？

或者其他方法来避免几个月的工作？

Answer 1

您要求将CloudFormation的执行角色限制为它需要的命令，这绝对是最佳实践，并且在CloudFormation控制台中，当您启动一个模板时，有一个“权限”选项，上面写着：

选择IAM角色来明确定义CloudFormation如何在堆栈中创建、修改或删除资源。如果您不选择角色，CloudFormation将根据您的用户凭据使用权限。

这就是说，在部署模板时，CloudFormation可以使用您的用户权限来部署模板中定义的服务，或者，根据最佳实践和最小特权原则，CloudFormation可以承担已设计和定义的角色，该角色具有特定于此特定模板的权限。这是最佳实践，因为我们希望确定正在使用和执行的服务和资源。

有几种方法可以实现您的目标，即确定CloudFormation部署模板所需的权限。在您的情况下，我假设您有很多资源，因此这似乎是一项需要几个月才能解决的巨大任务，但实际情况是，它只需要几个小时。我将提出两种方法来实现这一点。让我们开始吧：

1. CLI

1. Create a new role from my CLI that has no permissions. Be sure to create the trust relationship to allow CloudFormation to assume the role.
2. Create a new blank policy document and attach that policy to the role you just created.
3. Add an ALLOW `iam:PutRolePolicy` for that new policy I just created.
4. Assume the role new from the CLI, so that you're using that role going forward
5. Create a bash script that is going to repeatedly attempt to deploy the CloudFormation template until it successfully deploys it. Assuming the template is formatted correctly, each time the script try's to deploy the template it's going to receive a permissions error because the role that was assumed in step 2 doesn't have the correct permissions. The error is going to look something like:

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 (即它所需的权限)，然后通过aws iam put-role-policy命令(语法和完整要求here)将iam:PassRole内联策略添加到上面步骤2中创建的角色。

将策略附加到IAM角色后，脚本应循环返回并再次尝试部署模板。它应该继续这样做，直到模板成功部署，或者直到它收到其他一些无关的错误，并且完全停止执行。当它成功部署时，您现在将拥有一个角色，该角色具有通过内联策略部署模板所需的确切权限。

备注1:根据您的帐户设置和/或模板中资源的数量，您可能很容易发现自己遇到了权限界限或超过了策略大小限制，这些都超出了本问题的范围，但您可能会发现自己需要解决这些问题。

注2:可以肯定的是，这是一种潜在的危险技术，这种类型的脚本应该只在开发环境中运行，以防止不希望出现的结果。如果您无意中在CloudFormation模板中执行了破坏性操作，并在生产帐户中运行它，则此类脚本可能会导致灾难事件；谨慎的做法是仅在开发人员中运行这样的脚本，以便您能够查看创建的所有权限，确定是否有任何意外或不需要的操作/权限，然后您可以使用必要的权限为生产帐户中的部署创建适当的角色和策略。

​

采用基于控制台的部署的

1. CloudTrail

一种不太高级的方法是在非生产帐户中使用CloudTail来审计CloudFormation使用的权限，并从中制定一个策略(实际上是您问题中的第二个选项)。我不知道有任何现成的脚本来解析CloudTrail日志和创建策略文档，但是手动完成并不困难，也可以编写脚本。不管怎样，如果你选择了这个选项，在这个阶段，我建议坚持使用控制台，因为你很快就能看到你需要的东西。

1. Login to a non-production account with a user that has admin permissions
2. Head over to CloudFormation and deploy the template using the logged in users permissions (ie admin)
3. Once deployment is complete, head over to CloudTrail to find all the permissions that were used by that user during the deployment; filter the list by `User name`, and then from the events you'll be able to see what permissions were used.
4. Craft a policy that has the permissions that were used by CloudFormation  
5. Take that policy and add it to the deployment role that CloudFormation will use in the production account

​

根据您的bash脚本编写技巧，这两个选项应该花费相同的时间；几个小时，甚至一天，肯定不是几个月。

祝好运!