If a user in AWS is having AdministratorAccess policy attached, he has full AWS access for that account. But with permission boundaries attached to that user his access can be confined. For example say the user has permission boundaries set to AmazonDynamoDBFullAccess, then the full access is just confined to DynamoDB.
What is real benefit of above approach, one could have just removed the AdministratorAccess policy and attached AmazonDynamoDBFullAccess to the user to achieve the same restrictions/permissions.
Is there anything more to understand?
That is not not purpose of IAM Permission Boundaries, nor is it the way it operates.
From Permissions boundaries for IAM entities - AWS Identity and Access Management:
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.
To explain via an example, let's say that a developer needs permission to create an IAM Role in their software development duties. This can be a very dangerous permission to assign because they could create a Role that has full Admin permissions, thereby granting themselves even more permission that desired.
To limit their abilities, a permission boundary could be added to the developer such that they are only able to create an IAM Role if the role they define is attached to a permission boundary that limits the permissions of the Role (eg so it can only be used to access S3 and DynamoDB, but not other services). It can be a little confusing, but think of it as a set of rules that must be attached to any permissions they give, so that they can't grant full permissions. It's a way to grant them permissions, but limits what permissions they can on-grant to other entities.
This concept is totally separate to assigning IAM managed policies that you mention in your question. In most circumstances, assigning an IAM managed policy is perfectly sufficient. Permissions boundaries only really apply when somebody has permission to create new IAM entities.
Related
I want to be able to specify an iam group as the principal within my policy but i have been reading that you cannot specify an iam group as part of a resource based policy. I could potentially add in a list of iam users but then my policy would look really messy. What is the best approach to take if i cannot add an iam group arn as the principal within my policy.
If you cannot specify an IAM group as the principal in a resource-based policy, you have a few options:
Attach the policy directly to the IAM users: In this case, you would
need to specify each IAM user ARN in the policy. This approach can
quickly become messy and difficult to manage as the number of IAM
users grows.
Use an IAM role: An IAM role is a way to grant permissions to AWS
services or applications that run on AWS. You can create an IAM role
that can be assumed by IAM users or IAM groups. You can then specify
the IAM role in the policy instead of the IAM users or IAM groups.
This approach provides a cleaner and more scalable way to manage
permissions.
Use a service control policy (SCP): An SCP is a type of policy that
is used to set permissions boundaries for an AWS account. You can
use an SCP to allow or deny access to AWS services for IAM groups,
IAM users, or IAM roles. This allows you to manage permissions for
multiple users in a centralized and organized manner.
I would recommend option 2 or 3 as the best approach, as they provide a cleaner and more scalable way to manage permissions compared to specifying individual IAM user ARNs in the policy.
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
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
Suppose, I am AWS IAM user, is there any way so that I can check what resource permission has been given to me, using CLI or Console.
Unfortunately, there is no comprehensive tool for that. In IAM console you can only check your user's IAM profile or group permission you belong to.
But full set of privileges is a very complex thing to get. Apart from obvious IAM user or group permissions you can have:
IAM roles which you can assume,
resource policies which you are listed as a principle (e.g. bucket policy, kms key policy),
resource policies where a role you can assume is a principle,
cross-account permissions in IAM roles or resource policies,
AWS Organization level SCP permissions.
If the reason for asking this question is related to security, e.g., to check what resources were accessed by a compromised IAM user credentials, you suspend the credentials or delete the user. Also can inspect the CloudTrial history to check what resources a given IAM user accessed.
There is a policy attached to user/role which is allowed to create other policies and roles, but, for example, original role doesn't have permissions to do s3:PutObject. Is there any way I can prevent this role/user from creating another policy which allows s3:PutObject and elevating it's own permissions by that?
If you grant users the ability to create policies and roles, then you trust them not to abuse it. Very few admins should have this ability.
The way to solve your case is for an uber-admin to create policies and roles, and for your user to be restricted to which policies/roles he can attach (see related article). You can also implement automation to validate the policies created by your uber-admins meet certain conditions.