I have an IAM role with AdministratorAccess, but when I upload a custom template to AWS CloudFormation, I get the following error:
Operation failed, ComputeEnvironment went INVALID with error:
CLIENT_ERROR - You are not authorized to call EC2 Describe operations.
It is required to perform CreateLaunchConfiguration operation.
All the other resources seem to complete successfully, so I'm not sure if there is some sort of role delegation taking place?
It is possible that you are affected by Service Control Policies (SCPs) or by Permission Boundaries or even other policy types.
Identity-based policies
Resource-based policies
Permissions boundaries
Organization SCPs
Access control lists
Session policies
Regarding SCPs:
An SCP restricts permissions for IAM users and roles in member
accounts, including the member account's root user. Any account has
only those permissions permitted by every parent above it. If a
permission is blocked at any level above the account, either
implicitly (by not being included in an Allow policy statement) or
explicitly (by being included in a Deny policy statement), a user or
role in the affected account can't use that permission, even if the
account administrator attaches the AdministratorAccess IAM policy with
/ permissions to the user.
Also see How to use service control policies to set permission guardrails across accounts in your AWS Organization
As this article states,
The member accounts of an AWS Organization are unable to see the SCPs
that have been applied to them. Further, when actions are denied,
there is no way to know whether that is due to an IAM policy, an SCP,
or something else (ex. session policy, IAM boundary, resource policy).
This means there will be no indication in the error message from an
API call or in the CloudTrail log to show what denied the call. This
can make debugging issues difficult.
This article has some useful diagrams that show the different things that could be affecting/limiting the access.
I've been working on this problem for four days and finally came up with a solution that I think resolves it.
There are two kinds of CDK bootstrap: legacy and modern. Legacy is the default.
There appears to be a bug in the legacy bootstrap that affects some accounts and not others. I was able to verify that the same code worked for me on one account but produced the exact symptoms of this problem on a newly created account.
If you are not stuck with legacy bootstrap for some reason, just convert over to modern bootstrap. That should make the error (and the reason for the error) go away.
The instructions are here: https://docs.aws.amazon.com/cdk/latest/guide/bootstrapping.html
Basically, you have to set an environment variable before you call cdk bootstrap, and then you have to change either some code or some configuration in your project.
It is not intuitive that this feature exists in the CDK at all, nor that it would be the fix for this particular problem. However, it cleared it up for me. Maybe it will do the same for others.
Related
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've created a custom role in GCP, which I'm using to assign limited access to our business users, enabling them to train the chatbot. At the moment they can perform the functions as needed using the Training module, I would also like to give access to the History module, but I keep hitting an error
IAM permission 'dialogflow.conversations.list' on 'projects' denied.
When I try and add this permission, it's not available. I've noticed the second I make a copy of a standard dialogflow permission group, this object goes missing.
Any suggestions on how I can enable access to this module?
Add Permissions Screenshot
According to Google document, Not all permissions can be used for custom IAM role.
Custom IAM role has a limitation that some permissions are not available.
Below is description about limitation of custom IAM from google document page.
Some predefined roles contain permissions that are not permitted in
custom roles. To check whether you can use a specific permission in a
custom role, see Support level for permissions in custom roles.
Also, I checked whether dialogflow.conversations.list permission is permitted or not. But It didn't even exist.
You can also check it here.
I think you can just grant a dialogflow.conversationManager role to group or users for your situation.
That dialogflow.conversationManager role looks perfect, I'll switch to that.
Many thanks!
I'm totally new to AWS and learning about IAM. I was wondering if there is a way around for an IAM user to check what all permission he/she have? Like as a root user, I created a group of IAM users where they were only allowed to use S3 service but once I logged in as an IAM user, it was showing that I have access to other AWS services as well like running EC2 instances, etc which I reckon shouldn't be the case. Thanks!
No, it isn't possible to "show" which services you have access to use, because the policies can be quite complex (eg permission to access an S3 bucket, but only a particular sub-folder if coming from a given range of IP addresses).
You would need to look the the IAM Policies attached to the IAM User, plus the policies on any IAM Groups they are in. Then, some services like Amazon S3 have additional permissions such as Bucket Policies.
In addition, AWS Organizations can limit the permissions of all users within an AWS Account, so even if a user appears to be granted certain permissions, they might not actually be available for use.
In many situations, you'll only know if you can do something by actually trying it. For example, you might have Read Only permissions, which means you can see resources in the AWS Console, but you would receive an error when you try to change things.
All services are available in the AWS Console, but various parts of the console will only work if you have adequate permission.
Note that there's IAM Policy Simulator from AWS. You can select a service and check if a given user has access to any given action (or all actions relevant to a service)
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!
For small CloudFormation and CodePipeline templates we could "try - test" to get least privilege IAM Policy for the roles required.
This usually involves:
Starting with a minimal policy
Creating the stack
It fails with - stack doesn't have rights to someService:someAction
Add the service action to the policy
update stack and try again
This approach is too time consuming for larger CloudFormation Templates.
How are you developing Least Privilege IAM Policies?
Ideas:
Allow "*" and then scrape cloudtrail for events and build map for listed events to their equivalent roles - then reduce the roles to only those listed in the cloudtrail logs.
If you can isolate actions down to a user name this helps
https://github.com/byu-oit-appdev/aws-cloudwatch-parse
Access Advisor
Grant least privilege is a well-documented IAM Best Practice. The documentation recommends incrementally adding specific permissions, using the Access Advisor tab to determine which services are actually being used by an application (presumably using a broader set of permissions during the testing phase):
It's more secure to start with a minimum set of permissions and grant additional permissions as necessary, rather than starting with permissions that are too lenient and then trying to tighten them later.
Defining the right set of permissions requires some research to determine what is required for the specific task, what actions a particular service supports, and what permissions are required in order to perform those actions.
One feature that can help with this is the Access Advisor tab, which is available on the IAM console Summary page whenever you inspect a user, group, role, or policy. This tab includes information about which services are actually used by a user, group, role, or by anyone using a policy. You can use this information to identify unnecessary permissions so that you can refine your IAM policies to better adhere to the principle of least privilege. For more information, see Service Last Accessed Data.
This approach is similar to scraping CloudTrail for API events generated by a specific IAM Role/application, though the latter might be more difficult to filter through the entire event stream in order to find the relevant events, while the Access Advisor list is already filtered for you.