Can I AutoCreate an IAM role for a Cloudformation stack from the template?

Question

I've been told to restrict my Cloudformation to only the commands it needs. With a role. To create the role I can spend months going through my template to decide that launching an EC2 instance actually involves 10 different IAM items (like creating tags, network interfaces, volumes, etc..) and figure out all the ARNs in question and so on for all my resources. (Because these resources aren't created yet, I'm going to need a lot of * for this role to be useful next time.)

OR, is there a tool to do that for me? I imagine supplying my template and the tool going away and making the bulk of the role. Maybe a few bits to change where the template does things based on parameters maybe.

OR, if I create the stack with Cloudtrail turned on, is there a tool to convert from cloudtrail logs to a policy document?

OR any other way to avoid months of work?

Answer 1

Your requirements to restrict your CloudFormation's execution role, to only the commands it needs is definitely best practice, and in the CloudFormation console, when you're launching a template there is an option for "Permissions" that says:

Choose an IAM role to explicitly define how CloudFormation can create, modify, or delete resources in the stack. If you don't choose a role, CloudFormation uses permissions based on your user credentials.

What this is saying is that when deploying your template CloudFormation can either use your users permissions to deploy the services defined in your template or, in accordance with best practice and the principal of least privilege, CloudFormation can assume a role that has been designed and defined with permissions that are specific to this specific template. This is best practice because we want to be certain of the services and resources that are being used and executed.

There are a few ways you can achieve your goal of determining what permissions CloudFormation needs to deploy your template. In your case I imagine you have many resources, and because of this it seems like a mammoth task that will take months to figure out, but the reality is that it will take just a few hours. I'll suggest two ways you could accomplish this... Lets begin:

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

      In the example above, our template needed to perform iam:PassRole but the role assumed doesn't have permission to do that, hence the error. To solve this have the script parse the iam:PassRole from the error (ie the permission it needs), and add then add an iam:PassRole inline policy to the role that was created in step 2 above via the aws iam put-role-policy command (syntax and full requirements here ).

      Once the policy is attached to the IAM role, the script should then loop back and try to deploy the template again. It should to keep doing this until the template successfully deploys, or until it receives some other error which is unrelated and it stops executing completely. When it deploys successfully, you'll now have a role that has the exact permissions needed, via inline policies, to deploy the template.

      NOTE 1: depending on your account settings and/or the number of resources in your template, you could easily find yourself hitting permissions boundaries or exceeding policy size limits, these are outside the scope of this question but you may find yourself needing to address those issues.

      NOTE 2: to be sure, this is a potentially dangerous technique and this sort of script should only be run in a dev environment to prevent unwanted outcomes. If you unwittingly had a destructive operation in your CloudFormation template and ran it in a production account, this sort of script could cause a disaster incident; it would be prudent to only run a script like this in a dev so you'll be able to see all the permissions that are created, identify if you have any unexpected or unwanted operations/permissions, and then you can craft an appropriate role and policy for deployments in your production account with the necessary permissions.

2. CloudTrail with Console based deployment

   A less advanced method would be to use CloudTail in a non-production account to audit the permissions being used by CloudFormation and craft a policy from that (effectively the second option in your question). I'm not aware of any off-the-shelf scripts to parse CloudTrail logs and create policy documents, but doing it manually is not difficult and scripting it can also be done. Nonethless, if you do go with this option, at this stage, I'd suggest sticking with using the console as you'll quickly be able to see what you need.

   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

Depending on your bash scripting skills, both of these options should take about the same amount of time; a few hours, maybe even a day, definitely not months.

Good luck!