Challenge with Individual Permissions:
Managing individual permissions becomes increasingly difficult and time-consuming as the number of users and resources grows.
Example: With three developers (John, Mary, and Pat), each has a policy for accessing Amazon EC2. When they need access to Amazon S3, the administrator must modify each individual user policy.
As the number of developers and resources increases, the effort and chance of error increase significantly.
IAM Groups Solution:
Attach permissions to multiple users at once using IAM groups.
Create groups based on job functions (e.g., developers, admins, testers).
Assign IAM permissions to the group.
Members of the group automatically inherit the group's permissions.
Updating permissions for all members requires only a single change to the group policy.
IAM Group Characteristics:
IAM groups do not have security credentials; you cannot sign in with a group.
Groups are a mechanism for managing user permissions.
Example Scenario:
IAM groups for admin, developer, and test job functions.
When a new person is hired, add them to the appropriate group.
If someone changes jobs (e.g., Anna), remove them from their old group and add them to the new one.
Users can belong to multiple groups, but groups cannot be nested.
Permission Overrides:
Permissions directly attached to a user override group permissions if the user policy is more restrictive.
Example: Xen is a member of the developer group and has access to Amazon Athena through the group policy. However, Xen cannot access Amazon Kinesis, even though it's permitted in the group policy, because it's explicitly denied in their user policy.
Role-Based Access Control (RBAC):
Creating IAM policies for job roles and assigning users to groups based on job functions is more scalable than attaching policies to individual users.
Disadvantage: When adding resources to multiple roles, you must update each of the policies that need the resource.
Each new bucket or instance requires modifying the policy for each group that needs it.
ABAC Overview:
Define permissions based on attributes (key-value pairs).
More flexible and scalable than RBAC because you don't have to update policies with every change.
Attributes in AWS (Tags):
In AWS, attributes are called tags.
Tags are key-value pairs and can apply to IAM users, roles, and AWS resources.
You can create user-defined tags, and many API operations return tag keys and values.
Tag Usage:
Access control.
Billing.
Filtering views.
Example Tags for EC2 Instances:
Name
Project
Environment
ABAC Example Scenario:
Development team with attributes to identify the environment (development or test) and the project (maintenance or new development).
Four IAM roles: maintenance developer, new project developer, maintenance tester, and new project tester.
Each project has two EC2 instances, one tagged for the dev environment and the other tagged for test.
An S3 bucket tagged for developers and one tagged for testers.
ABAC Policy:
A single policy is set up using the attributes to define which tags have access to which resources.
If a new EC2 instance is added, it's tagged appropriately, and the roles that should have access will have it without any other changes.
Implementing ABAC:
Create IAM users or roles and assign attributes to them.
Require attributes for all new resources.
Configure access permissions based on the attributes.
Use IAM groups to grant the same access rights to multiple users in the same job function.
Use attribute-based access control (ABAC) to scale permissions management.
ABAC is an authorization strategy that defines permissions based on attributes.
Use tags to assign attributes to your IAM identities and AWS resources.
6_Managing Access Permissions at Scale with IAM
Challenge with Individual Permissions:
IAM Groups Solution:
IAM Group Characteristics:
Example Scenario:
Permission Overrides:
Role-Based Access Control (RBAC):
ABAC Overview:
Attributes in AWS (Tags):
Tag Usage:
Example Tags for EC2 Instances:
ABAC Example Scenario:
ABAC Policy:
Implementing ABAC: