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?
A permissions boundary is an IAM feature that helps your centralized cloud IAM teams to safely empower your application developers to create new IAM roles and policies in Amazon Web Services (AWS).
IAM provides fine-grained access control across all of AWS. With IAM, you can control access to services and resources under specific conditions. Use IAM policies to manage permissions for your workforce and systems to ensure least privilege.
Permissions let you specify access to AWS resources. Permissions are granted to IAM entities (users, groups, and roles) and by default these entities start with no permissions. In other words, IAM entities can do nothing in AWS until you grant them your desired permissions.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With