I'm working on an automated pipeline (using Jenkins) that deploys AWS Cloudformation Templates residing in a git repository to AWS.
I have a working pipeline that works off of an AWS IAM user whose access keys are used by a Jenkins job to talk to the AWS Cloudformation API.
The issue I'm facing is that preferably I would have this IAM user to have as little permission as possible, but it should have enough permissions both to access the Cloudformation API but also to create the resources I have templates for.
In order to determine this minimal permission set, my question is whether there exists an application, package or AWS utility (I haven't been able to find one yet) to infer the IAM permissions required to execute a given (set of) Cloudformation templates, that can preferably be used programatically.
Thanks in advance for any suggestion!
This is something that would be very nice to have, but for some reason Amazon is not willing to provide an API to check for this.
One hacky way to approach this could be to run the cloudformation template over and over again and check the output for the missing permissions. Then you add them each time to a temporary IAM role and repeat until you have all the permissions to launch your template. This might take a rather long time, but could be the only actual way to programmatically approach this.
Related
I am using AWS application composer to create my serverless stack.
Specifically on Lambdas, i need to add additional IAM policies that have been included in my Lambda code logic. For example, some of the AWS service IAM policies access. I know I can add the additional access after deployment at the AWS IAM page, however this is not ideal especially we might forget or it would be difficult to pass the setup code and templates to other teams.
Any insights? Thanks.
I have searched the reference or documentation but could not find any workaround.
If you are referring to policies attached to Lambda service role, you can add it.
Since Application Composer uses SAM AWS::Serverless::Function templating, you should be able to add it under the Policies field, it is in the Application Composer console under Details as well (you need to scroll down to the bottom)
https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-policies
As stated in the documentation -
This property accepts a single string or a list of strings, and can be the name of AWS managed policies or AWS SAM policy templates, or inline IAM policy documents formatted in YAML.
You can try to add that in. For example:
I'm trying to set up AWS IAM Identity Center (successor to AWS Single Sign-On) for my organisation, and my team has a strong preference for Infrastructure as Code (IaC) wherever practical.
While exploring solutions, I was able to set up an Instance with several Users, Groups and Permission Sets using the Management Console UI. However, now I have come to set up something more long-term, I can't find any way to create an Instance via either CloudFormation or the AWS CLI.
When looking for documentation, I found the CloudFormation reference for AWS SSO, as well as the AWS CLI reference for the sso-admin subcommand. Neither mention any operations that create instances. Neither does the AWS SSO API reference, which leads me to think programmatic access may not be possible.
Is it possible to create an Instance through code rather than the Management Console?
If it is possible, what have I missed?
In the spirit of providing least privilege permissions I often find myself hunting down required permissions to complete a specific task or providing others with access. Access denial messages in AWS are usually pretty good and list the required permissions. However other times the error message can be vague, especially when one service is dependent on another. Is there a better way than trying to complete an action and granting required permissions one by one? Does a list or some sort of tool exist?
AWS now has AWS Access Analyser that can be used to generate IAM policies based iam user/roles.
Here is the documentation: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html
You can also use AWS CLI as well to generate policies based on IAM activity:
aws accessanalyzer start-policy-generation --policy-generation-details
and then, get the generated policies:
aws accessanalyzer get-generated-policy --job-id <>
another way, you can use user's access activity from AWS console and see what that user has been using and not using, and on basis of that you can create your policies.
I need to create a CloudFormation SAM template that creates multiple resources. I also need to integrate GitHub Actions so code gets auto deployed on push. The problem is this requires that I give GitHub a lot of IAM permissions to do the necessary work. Note that I'm using an Open ID identity provider for GitHub as opposed to api keys.
How do I find out which IAM permissions are needed at minimum so I don't give GitHub more than what is necessary? Is there an AWS tool that can parse the deployment template and tell me which permissions are needed for both deployments and rollbacks?
No, there's no such tool. You can however look at the Cloudtrail logs to see which actions are being invoked by CloudFormation, and based on that you could put together the list of required policies.
Alternatively, you could replicate what the CloudFormation template is doing by using the AWS CLI. That way, you could use iamlive to generate the IAM policies required for those CLI commands.
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?
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:
CLI
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.
Create a new blank policy document and attach that policy to the role you just created.
Add an ALLOW iam:PutRolePolicy for that new policy I just created.
Assume the role new from the CLI, so that you're using that role going forward
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.
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.
Login to a non-production account with a user that has admin permissions
Head over to CloudFormation and deploy the template using the logged in users permissions (ie admin)
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.
Craft a policy that has the permissions that were used by CloudFormation
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!