we have an aws 'test' account created by our aws Organization.
i was creating some roles for testing purposes, but i'm totally unable to delete them, even with the root account. The error is:
User: arn:aws:iam::xxxxxxxxxxxx:root is not authorized to perform: iam:DeleteRole on resource: role test with an explicit deny.
i have no policy attached on the rule, everything seems fine.
Btw, the same scenario works correctly on the organization master account, i can delete roles there.
Anyone can help?
Thanks
D.
It looks like that either there is a policy attached to user (or to a group to which user belongs) which is denying this action.
You can also confirm if this role is assigned to some instance profile or to another user/group.
Related
I'm trying to setup my aws cli. I downloaded it and everything worked.
Now I wanted to log in from my powershell script.
Set-AWSCredentials –AccessKey key-name –SecretKey key-name
Because I don't have any users at the moment I had to create one. I have given the user admin rights.
When creating the user aws throws this error:
User: arn:aws:sts::37197122623409:assumed-role/voclabs/user2135080=.... is not authorized to perform: iam:CreateUser on resource: arn:aws:iam::371237422423709:user/.... because no identity-based policy allows the iam:CreateUser action
My first thought was that my education account is having a problem. But I didn't find anything about it. Thanks for your help in advance.
The "voclab" part of the error suggests you are not logged as the account root user but instead assuming a role in an account used for teaching purposes.
This role is probably designed to disallow IAM actions, in order to prevent privilege escalation.
Read
https://docs.aws.amazon.com/singlesignon/latest/userguide/howtogetcredentials.html to get role credentials for the role you're assuming
You can't make any IAM roles, policies or users as a student using voclabs account. AWS Academy does not allow to do that and its a hard limit which you nor your educator can change.
I have a problem when creating a Role I am getting an error that says “Cannot attach a Service Role Policy to a Customer Role”
In fact, there is something called Customer Managed Role, which the above error seems to display as 'Customer Role'.
From AWS documentation (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-role)
A role that a service assumes to perform actions in your account on your behalf. When you set up some AWS service environments, you must define a role for the service to assume. This service role must include all the permissions required for the service to access the AWS resources that it needs.
Now if you create a role, which isn't a service role, and attach permissions yourself, it appears under what AWS shows as Customer Managed Role (Screenshot below). If you look carefully, the service roles in AWS show the AWS box icon and the Customer Managed ones don't.
Reason: I was facing the above error as well and the reason was that my Role had custom inlined policies attached. If a Role has custom attached policies (inlined), AWS doesn't let you attach the Service Roles to it. You can filter the roles and find out what's causing the issue.
I hope this is documented somewhere as I was scratching my head for quite some time on this.
Background:
I am trying to grant access for an ECS task in Account B to extract data from a DynamoDB table in Account A.
In theory, this works fine by: (1) creating a role in Account A that Account B is allowed assume (with a paired External ID), and then (2) granting that role access to the needed DynamoDB tables.
Problem:
When a process running in ECS assumes the ECS role (Account B), it creates a unique instance of that role, which apparently cannot be the target of a principal statement in the account. If I try granting access to the underlying role, that apparently has no affect.
Can I force ECS to use the original role, which I can grant as principal, rather an a temporary set which apparently can't then assume other roles?
The only workaround I can think of is to create a new user with programmatic API credentials, handoff those creds to the ECS task, and then then have the ECS task overrides it's own role with the one's belonging to the AWS key-pair. That's definitely an antipattern though, as far as I can tell, and it opens up the risk of those credentials being compromised.
Is there any way to do this without resorting to a manually created user and manually passed AWS creds?
Additional info:
I can grant to this principal arn:aws:iam::AcctB****:role/myrole but the ECS task is using this one at runtime: arn:aws:sts::AcctB****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53.
Error message is: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::AcctB****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::AcctA****:role/ExternalRole
I faced the same situation and found a safe way to programmatically assume the role from an ECS task.
sts_client = boto3.client('sts')
identity = sts_client.get_caller_identity()
print(identity) # identity in account A
response = sts_client.assume_role(RoleArn=assume_role_arn, RoleSessionName=session_name)
session = boto3.Session(aws_access_key_id=response['Credentials']['AccessKeyId'],
aws_secret_access_key=response['Credentials']['SecretAccessKey'],
aws_session_token=response['Credentials']['SessionToken'])
The idea is to connect to account A, assume role from account B, init a session using temporary credentials and then init whatever client you need from that session.
external_client = session.client('sts')
identity = external_client.get_caller_identity()
print(identity) # identity in account B
This is more secure than creating a IAM user and share credentials between accounts because authentication is done internally.
Here you can find more information about how it works
https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts.html
Linking the following topic here: How to assume an AWS role from another AWS role?
TL;DR
Really make sure you don't have a typo, wrong name or external id in one of the policies.
ECS needs to assume your Task Role the same way you are trying to assume the role in Account B. This can't be changed. Even ECS tries to assume Account B role with assumed-role/... it works as expected when granted a principal with role/...
I'm trying to replicate this lab :https://github.com/aws-samples/ec2-spot-montecarlo-workshop, But keep getting an error The provided credentials do not have permission to create the service-linked role for EC2 Spot Instances. seems like when it tries to create instance it fails, does anyone have an idea why ? I made sure to give it all permission role but didn't work ...
Seems that credentials which you use (IAM user or role) do not have permissions to execute an action iam:CreateServiceLinkedRole. The action:
Grants permission to create an IAM role that allows an AWS service to perform actions on your behalf
Please double check the IAM user and credentials which you use.
When lodging a spot request – there is a service-linked role that needs to be created (if it does not exist) in IAM called AWSServiceRoleForEC2Spot.
Check that the IAM user has the permission:
iam:CreateServiceLinkedRole
More in the docs:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html#service-linked-roles-spot-instance-requests
I am writing an application for AWS platform, which was planned to be launched from the root account, with root credentials. At this point I need to stop some of the machines started by the AWS organizations member accounts.
By default AWS organizations doesn't give access to root account to look or manage resources to other member's account. So I tried using temporary credentials and tried to assume a role created by the target account.
More on that here.
https://docs.aws.amazon.com/AmazonS3/latest/dev/AuthUsingTempSessionTokenJava.html
On the other hand it doesn't allow root account to assume roles, and throws such exception.
com.amazonaws.services.securitytoken.model.AWSSecurityTokenServiceException: Roles may not be assumed by root accounts. (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied; Request ID: 7bee7537-48e0-11e9-bb1a-bb36134736e4)
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.handleErrorResponse(AmazonHttpClient.java:1695) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeOneRequest(AmazonHttpClient.java:1350) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:1101) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:758) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:732) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:714) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$500(AmazonHttpClient.java:674) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:656) ~[aws-java-sdk-core-1.11.475.jar:na]
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:520) ~[aws-java-sdk-core-1.11.475.jar:na]
at...
Is there any way get around this problem? For example, somehow to give the root access to everything or let it assume roles?
Firstly, please don't use your Root account! Best practice is to remove access keys from the root account, add an MFA token and lock it away. We have a large AWS Organization structure and we don't use the root accounts for anything other than where it's absolutely required.
See the IAM Best Practices user guide, specifically the section: Lock Away Your AWS Account Root User Access Keys
For your described administrative purposes, use IAM Users
IAM Users can assume Roles. Recommended steps:
Create IAM Group and attach the required policy for admin permissions. The AdministratorAccess policy is an easy pre-built policy that gives full admin access within the current account, but to assume roles into sub-accounts, all you really need to allow is the sts:AssumeRole action.
Creating Your First IAM Admin User and Group
Granting a User Permissions to Switch Roles
Create an IAM User and assign it to the IAM Group.
Adding and Removing Users in an IAM Group
Create the target Role in your sub-accounts with a Policy to allow actions in that sub-account and with a Trust Relationship defined for your IAM user in the master Org account.
Creating a Role to Delegate Permissions to an IAM User
NOTE: Sounds like you may already have this, but check the trust relationship to make sure.
Authenticate your app via IAM user credentials, temp credentials, etc.
NOTE: The temp credentials doc that you linked is for IAM Users, I'd recommend trying it again once you have a proper IAM user setup.
There are many ways to authenticate to AWS services, as another example see: Assuming an IAM Role in the AWS CLI
Additional: Not sure what you're building, but if appropriate, Consider Using Service-linked Roles to directly provide the app the specific permissions it needs--rather than dealing with user credentials.