As an Admin user, I have created an IAM user with some restricted accesses for testing purposes.
So, when I login with the IAM user, I don't have access to unauthorized services as expected but I've noticed that I can create and remove IAM users, even if I didn't created them by myself.
So, I have three questions:
Why an IAM have the ability to remove other users?
And how can I prevent this?
When an IAM user create "sub IAM users", do these "sub users" inherit from his unauthorizations?
1) Why an IAM have the ability to remove other users?
Am IAM user is just another user of your AWS account. It appears you gave the new IAM user the permissions to create, modify, or delete other IAM user accounts.
2) And how can I prevent this ?
You need to review the IAM policies and roles assigned to the new IAM user and remove the permissions you don't want them to have. Please post the exact IAM roles and policies you have assigned to the user if you need help with this.
3) When an IAM user create "sub IAM users", do these "sub users"
inherit from his unauthorizations ?
There is no such thing as "sub users". A user is not in any way tied to the user that created them.
A user is granted the ability to create a user by virtue of the permissions granted to the first user. If you attach a policy to the second her that also grants the ability to create users that second will have permission to do so. There is a feature that allows you to grant a user the permission to create other uses whilst limiting the permissions of the second user. The feature is called Permission boundaries. By using this you can allow a user to create other users but limit what permissions that other user can grant.
There is no concept of "sub-IAM users." An IAM user is an IAM user. The user has permissions to create other IAM users because you haven't denied the iam:* policies. You said you "created an IAM user with some restricted accesses for testing purposes." Without seeing the user it's not possible to know what permissions you have granted, but you must have allowed IAM permissions. To prevent the user from creating other users, do not attach policies that allow the iam:CreateUser permission.
Yes you're right an IAM user shouldn't have the ability to manage other users. AWS has policies for this like if you want other users to give access to all services you can create a group and attach PowerUserAccessPolicy to that group. Users with PowerUserAccess wouldn't be able to manage groups and other IAM users. Further, if you want to restrict admin users access to manage other IAM users you can create custom policy to deny this affect using an inline policy.
Reference:
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html
Any IAM user can't be called as "sub-user", as all users can be said to have the same level.When any IAM user is associated the policies for IAM operations such as create, update, delete, that user can perform such IAM operations for new or existing users.
Related
According to the Documentation: Granting permissions to multiple accounts with added conditions it is possible to create with the entry:
Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]}
just access for all the users inside this account. But unfortunately it is not working. When putting single users there the access for that User from that different account is working. But with all and the root option is does not work.
But with all and the root option is does not work.
This is because the admins of these accounts also have to add permissions to IAM users/roles to access the bucket. In other words, adding arn:aws:iam::111122223333:root to a bucket policy is not enough. The individual IAM users or roles from 111122223333 also need IAM permissions to access the bucket.
I have created a couple of Cognito User Groups named "admins" and "editors" which has in turn created IAM roles as expected {USERPOOLID}-adminsGroupRole. These IAM roles have no policies attached and when a user becomes a member of this group it appears that any permissions they were granted via the default authRole as a non-group user are completely ignored.
I would expected the authRole to be applied to anyone who is authenticated and my admins/editors group to provide additional permissions. If this is the way it works I am then expected to generate custom policies in my CloudFormation templates which already exist elsewhere, and they'd need to be dynamic to work for multiple environments/buckets etc. which is a ballache.
Am I approaching this wrong or misunderstanding? This behavior seems very odd.
Thanks
When using Amazon Cognito User Pools (and not Identity Pools), when you create a group and specify an IAM Role, their permissions are determined by the group's associated IAM Role.
Correct me if I'm wrong, but when you say: I would expected the authRole to be applied to anyone who is authenticated and my admins/editors group to provide additional permissions.
This authRole is the IAM Role defined in the Identity Pool for all users that have been authorized. You can control which role is being selected in the settings of your Identity Pool.
More information in this answer:
AWS Cognito role: Distinguish between Federated Identity Pool roles and User Pool Group roles
Am I able to allow a newly created IAM user to create arbitrary policies but limited to resources he created? For example if I allow a user to create S3 buckets, users and IAM/Bucket policies, I want him to be able to create policies for IAM user that are limited to buckets he created and not other buckets present in the account.
If I'm not able to specify such policy, is there any other way to achieve this? Some kind of namespacing within an account that could isolate that user's resources from all other IAM users?
This is related to AWS IAM Policy to allow user to create IAM User with specific Policy/Roles and I was wondering if something has changed since the time it was asked.
Check out Delegate permission management to developers by using IAM permissions boundaries
The documentation Permissions boundaries for IAM entities
AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries
I have logged into my AWS Management Console as a regular user, which already has AmazonEC2FullAccess
But while launching EC2 instance it says:
You do not have permissions to list instance profiles. Contact your administrator, or check your IAM permissions.
How come, I don't have permission to list profiles If I have fullAccess?
To have access to view this you would also need to have IAM permissions to be able to list the roles that exist.
AmazonEC2FullAccess does not cover this permission.
Ensure you have the following permission attached to your IAM user iam:ListInstanceProfiles.
There is a policy for IAMReadOnlyAccess which will grant that, but it also allows the listing of other IAM resources
After setting up AWS Organizations, I created a member account with a custom IAM role name. I've now forgotten the role name used and I'm unable to assume role as root into that account. I need to create IAM users in the member account but without the ability to assume role using the custom OrganizationAccountAccessRole it seems I'm unable to.
I've tried getting access by
Using the member account root user but it doesn't have permissions to IAM
Signing in to member account using AWS SSO user with IAMFullAccess and AdministratorAccess policies attached to the policy set but user cannot access IAM.
Attempting to describe member account using the master account admin user but the role isn't there
At this point, I'm thinking the only way out is to recreate the member account. Please tell me there is a better way.
UPDATE:
- Found that 1 & 2 didn't work because of a restrictive Service Control Policy (SCP) on the account which didn't include IAM access permissions.
Based on the comments.
The solution was to inspect CloudTrial logs to find the API call used to create the role.