I'm trying to achieve the following:
I have a web application that needs different user permissions for some menus and calls to the API gateway.
I have done the following:
- Set up a user pool with 2 groups ( Group 1 and Group 2 )
- Assigned users to those groups
- Set up 2 policies ( Policy 1 and Policy 2, where policy 1 is the default policy in authenticated role in fed. identites)
- Set up the correct trust policies in the roles
- In federated identities, under authentication providers, I have set authenticated role selection to choose role from token
On the front, I have decoded the ID token and verified that the cognito:groups etc are correct when initialising a login.
So group 1 is the looser policy allowing everything, and policy 2 is the stricter policy that should not allow calls to a certain resource in API gateway.
But when I assign a user to a group 2 which has the stricter Policy 2, the user still seems to use the policy 1 which allows everything. What am I doing wrong here?
I have the same problem as this thread and done exactly what it says but still no progress
Check the role assigned to the user group has a trust relationship. It needs this so it can assume the role of the federated identity provider.
You can build an appropriate role for the User pool groups role by doing this:
Open AWS console
Get to IAM section
Pick roles
Pick web identity
Choose Amazon Cognito
Paste in your Identity pool id (the federated one)
Click next
Now add/create policies you need for the user group, like S3 access, or whatever.
Give the role a name and save it.
Go to your User Pool group, edit it and assign the role just created.
Open the Federated Identity
Set the Authenticated role selection dropbox to Choose role from token
Optionally set Role resolution to DENY
References:
Fine grained auth
Role based access control
This may be a silly question, but have you assigned an IAM Role to the Cognito User Pools Group?
Further, I would opt for a more restrictive policy precedence. You should apply "normal user" policies as the Authenticated Role and more "admin user" policies as roles to be assumed by users belonging to specific groups.
Similar to:
Group: Admins (Policy A attached) (Precedence 0)
Group: Users (Policy B attached) (Precedence 10)
Authenticated Role: Policy B
Related
I want to create an IAM Policy of my Secret Manager in AWS, to limit access to an Admin group. But in IAM Policy, I can't create a condition for an IAM group to have single access. I can limit to specific users, to a role, but not a group.
I found that you can limit to a role, and then the Admin can create a temporary link that the user can temporarily attach the role permission by one hour. Link: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_permissions-to-switch.html.
But I don't think this is the best process for me.
So the answer is that you are putting your IAM policy in the wrong place.
With IAM Groups you assign Identity policies to the group, which then filter to all the users within said group.
With Resources (such as Secret Manager) you assign Resource Policies which can limit access to that resource (or grant specific allowances beyond other policies to specific other resources)
In effect, you want to create a Policy that gives Secret Manager permissions, then attach that policy to your group, rather than create a policy on Secret Manager that will give access to admins.
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html
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
I have two roles configured in my IAM called "role1" and "role2" and a user called "foobar". The trust policy of "role2" is configured so that "role1" is granted the AssumeRole action, while "role1" can be assumed by the foobar user.
So the workflow to use role2 would be to login as user foobar, then assume role1 and from there assume role2.
I know that I can easily jump from role1 to role2 in the CLI by setting the source_profile value in the configuration file ~/.aws/config. But I have been unable to do the same thing in the management console (web interface). There is the "Switch Role" menu, but that only allows me to assume the role from the user not logged in, not from an already assumed role.
So my question is: How can I switch to "role2" in the scenario described above from the management console?
I think the transitive IAM Role switch from AWS Console is not allowed as per the documentation
Granting a user permissions to switch roles
When you switch roles in the AWS Management Console, the console always uses your original credentials to authorize the switch. This applies whether you sign in as an IAM user, as a SAML-federated role, or as a web-identity federated role. For example, if you switch to RoleA, it uses your original user or federated role credentials to determine if you are allowed to assume RoleA. If you then try to switch to RoleB while you are using RoleA, your original user or federated role credentials are used to authorize your attempt, not the credentials for RoleA.
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.
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.