AWS IAM Policies PART 3 : Role Based and Attribute Based Access Control (RBAC & ABAC)
AWS Role-Based Access Control (RBAC)
AWS Role-Based Access Control (RBAC) is a method of regulating access to AWS resources based on the roles that users or services assume. Instead of assigning permissions directly to individual users, permissions are associated with roles. Users or services then assume these roles to gain the necessary permissions to access specific AWS resources.
Key Concepts
IAM (Identity and Access Management): IAM is the service that AWS uses for RBAC. It allows you to define who can access which AWS resources and under what conditions.
Roles: A role is an AWS identity that has permissions but is not associated with a specific user or group. Roles are intended to be assumed by trusted entities such as users, applications, or AWS services like EC2 or Lambda.
Policies: Policies define what actions are allowed or denied by a user, group, or role. They are written in JSON and attached to roles to control access to AWS services.
Trust Relationship: A trust relationship is a JSON document in a role that specifies which entities (e.g., users, services) are allowed to assume the role.
How RBAC works
. Create an IAM Role
In AWS Identity and Access Management (IAM), you create a role, which is a set of permissions that define what actions an entity (user, service, etc.) can perform on specific AWS resources.
A role does not belong to any specific user or service; instead, it can be assumed by users, services, or even other AWS accounts.
2. Define a Trust Policy
When creating the role, you also define a trust policy, which specifies who or what can assume the role. This could be:
IAM users or roles from your own AWS account.
IAM users or roles from another AWS account.
AWS services (like EC2, Lambda, etc.).
The trust policy is written in JSON format and attached to the role.
3. Attach a Permissions Policy to the Role
After defining the trust policy, you need to attach a permissions policy to the role. This defines what actions the role can perform and on which AWS resources.
Permissions are defined in JSON, specifying Allow or Deny actions.
4. Assume the Role
The entity (user, service, or another AWS account) that needs access will "assume" the role.
When assuming the role, AWS Security Token Service (STS) provides the entity with temporary security credentials (access key, secret key, and session token) that can be used to interact with the resources allowed by the role's permissions.
5. Use Temporary Credentials to Access AWS Resources
After assuming the role, the entity uses the temporary credentials issued by AWS STS to access the AWS resources specified in the role's permissions policy.
The credentials are valid for a limited duration (usually 15 minutes to 12 hours) and automatically expire.
Example: An EC2 instance with an attached role uses its permissions to upload data to an S3 bucket.
6. Session Expiration and Renewal
When the temporary credentials expire, the entity must assume the role again to get a new set of temporary credentials.
AWS handles role assumption automatically for AWS services like EC2, Lambda, and others.
Example. Assume Role for Cross-Account Access
Scenario: You have two AWS accounts, Account A and Account B. Users in Account A need to access resources (e.g., S3 buckets) in Account B.
Steps:
In Account B:
Create an IAM Role: Define a role (e.g., CrossAccountRole) with the necessary permissions to access the desired resources.
Trust Policy: Configure the role's trust policy to allow Account A to assume the role.
- In Account A:
Assume the Role: Use AWS STS to assume the role from Account B.
Response: AWS STS returns temporary security credentials
Use Temporary Credentials: Configure your AWS CLI or SDK with the temporary credentials to access Account B resources.
AWS Attribute Based Access Control (ABAC)
In AWS IAM Attribute-Based Access Control (ABAC), you can use tags to control access to resources. Let’s use a scenario where your team manages RDS databases for both testing and production environments, and you want to ensure that users can only access RDS databases based on their environment (tagged either as Testing or Production).
Scenario:
You have two types of environments: Testing and Production.
You want to ensure that:
Developers can only access RDS instances in the Testing environment.
Administrators can access RDS instances in both Testing and Production environments.
Approach:
Tag each RDS instance with an environment label:
RDS instances used for testing are tagged with "Environment": "Testing".
RDS instances used for production are tagged with "Environment": "Production".
Tag users based on their roles:
Developers are tagged with "Environment": "Testing".
Administrators are tagged with "Environment": "Production" and "Environment": "Testing" (or both roles, depending on how flexible access is).
IAM Policy for Developers (Access to Testing Environment Only)
This policy allows developers to access only the RDS instances tagged with "Environment": "Testing".
How This Policy Works:
PrincipalTag/Environment: The user has a tag Environment set to Testing, meaning this policy only applies to users with that tag.
ResourceTag/Environment: The policy allows access only to RDS instances that are tagged with "Environment": "Testing".
The condition ensures that users tagged with "Environment": "Testing" can only perform actions on resources that also have the "Environment": "Testing" tag.
IAM Policy for Administrators (Access to Both Testing and Production)
This policy grants administrators access to both Testing and Production RDS instances.
How This Policy Works:
PrincipalTag/Environment: The user (administrator) is tagged with both "Environment": "Testing" and "Environment": "Production".
ResourceTag/Environment: The policy allows access to RDS instances that are tagged with either "Environment": "Testing" or "Environment": "Production".
The condition ensures that administrators can access both environments, while developers are restricted to the testing environment.
Step-by-Step Policy Behavior:
Developer Scenario:
When a Developer (who is tagged with "Environment": "Testing") attempts to perform any action on RDS instances:
The policy checks the resource tags on the RDS instance.
If the instance is tagged with "Environment": "Testing", the action is allowed.
If the instance is tagged with "Environment": "Production", access is denied because the developer’s PrincipalTag doesn’t match the ResourceTag.
Administrator Scenario:
When an Administrator (tagged with both "Testing" and "Production") attempts to access RDS instances:
The policy checks the resource tags on the RDS instance.
Whether the RDS instance is tagged with "Environment": "Testing" or "Environment": "Production", the access is allowed because the administrator’s tags match both environments.
Advantages of ABAC in This Scenario:
Scalability: As more RDS instances are created, you don’t need to manually update policies. The environment tag on the RDS instance automatically enforces access control.
Flexibility: You can easily manage access by adjusting user tags, allowing dynamic access control without modifying the policies themselves.
Security: Ensures strict environment-based access. Developers can’t mistakenly access production resources, reducing the risk of unauthorized changes in critical environments.
Example of How You Might Implement It:
Tag RDS Instances:
Tag your RDS instance for testing as:
Tag your RDS instance for production as:
- Tag Users (or Roles):
When creating users or assigning roles, tag the Developer user or role with:
Tag the Administrator user or role with: