有人告诉我将Cloudformation限制为仅需要它的命令。具有作用。要创建角色，我可能需要花费数月的时间来检查模板，以决定启动EC2实例实际上涉及10个不同的IAM项（例如，创建标签，网络接口，卷等），并找出所有有问题的ARN，等等。用我所有的资源。 （由于尚未创建这些资源，因此我需要大量*才能使该角色在下次使用。）
或者，有什么工具可以帮我吗？我想提供我的模板和工具就可以了，并承担了大部分角色。可能需要一些更改，以根据参数更改模板在何处执行操作。
或者，如果我在Cloudtrail开启的情况下创建堆栈，是否有工具将cloudtrail日志转换为策略文档？
或采用其他方法避免工作数月？
答案 0 :(得分：0)
将您的CloudFormation执行角色限制为仅需要的命令的要求绝对是最佳实践，并且在CloudFormation控制台中，当您启动模板时，“权限”选项显示为：
选择一个IAM角色来明确定义CloudFormation如何创建，修改或删除堆栈中的资源。如果您不选择角色，则CloudFormation会根据您的用户凭据使用权限。
这是说，在部署模板时，CloudFormation可以使用用户权限来部署模板中定义的服务，或者根据最佳实践和最小特权原则，CloudFormation可以承担已经使用特定于此特定模板的权限来设计和定义。这是最佳实践，因为我们希望确定正在使用和执行的服务和资源。
有几种方法可以实现确定CloudFormation部署模板所需的权限的目标。就您的情况而言，我想您有很多资源，因此，这似乎是一项艰巨的任务，需要花费数月的时间才能弄清，但现实情况是，这仅需要几个小时。我将建议两种方法来完成此任务...让我们开始吧：
CLI
iam:PutRolePolicy。创建一个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 inline 策略到在其中创建的角色中通过aws iam put-role-policy命令执行上述第2步（语法和完整要求here）。
将策略附加到IAM角色后，脚本应随后返回并尝试再次部署模板。它应该继续执行此操作，直到模板成功部署为止，或者直到它接收到其他无关的错误并且完全停止执行为止。成功部署后，您将具有一个角色，该角色具有通过内联策略部署模板所需的确切权限。
注意1：（具体取决于您的帐户设置和/或模板中的资源数量），您很容易发现自己超出了权限范围或超出了策略大小限制，这些都不在此范围内问题，但您可能会发现自己需要解决这些问题。
注意2：，可以肯定，这是一种潜在的危险技术，这种脚本只能在开发环境中运行，以防止产生不良后果。如果您不经意间在CloudFormation模板中进行了破坏性操作并将其运行在生产帐户中，则这种脚本可能会导致灾难事件；谨慎的做法是，仅在开发人员中运行这样的脚本，这样您就可以查看所有创建的权限，确定是否有意外或不必要的操作/权限，然后可以设计适当的角色，生产帐户中具有必要权限的部署策略。
基于控制台的CloudTrail
一种较不高级的方法是在非生产帐户中使用CloudTail来审核CloudFormation使用的权限，并据此制定策略（实际上是问题中的第二个选项）。我不知道有任何现成的脚本来解析CloudTrail日志并创建策略文档，但是手动执行并不困难，并且可以编写脚本。不过，如果您确实选择了此选项，那么在现阶段，我建议您坚持使用控制台，因为这样您就可以快速查看所需内容。
User name过滤列表，然后从事件中查看使用了哪些权限。这取决于您的bash脚本编写技能，这两个选项所花的时间应大致相同。几个小时，甚至一天，绝对不是几个月。
祝你好运！