Understanding access control models in AWS

July 21, 2024    AWS IAM

When it comes to managing permissions and access control in AWS, two popular authorisation models are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). Both models have their unique strengths and can be used to enhance security by following best practices. In this blog post, let’s explore these models and how they can be used effectively.

Security best practices

Before we dive into the authorisation models, I would like to highlight the common security best practices. When working with AWS Identity and Access Management (IAM), following these security best practices is crucial. Here are some key points:

  1. Apply least-privilege access: This means granting only the permissions required to perform a task. It is a standard AWS security advice.
  2. Use temporary credentials: Prefer IAM roles for temporary credentials over long-term access keys. If long-term keys are necessary, rotate them regularly.
  3. Identity provider federation: Use identity provider federation to access AWS using temporary credentials for better security.
  4. Use conditions in IAM policies: Further restrict access by applying conditions in IAM policies.
  5. AWS managed policies: Start with AWS managed policies and gradually move toward least-privilege permissions.
  6. Enforce MFA: Enforce Multi-Factor Authentication (MFA) for additional security.
  7. Avoid root user credentials: Do not use root user credentials for everyday tasks.
  8. IAM Access Analyzer: Use IAM Access Analyzer to generate least-privilege policies.
  9. Regular housekeeping: Conduct regular housekeeping of user accounts.
  10. Permissions guardrails: Establish permissions guardrails across multiple accounts using Service Control Policies (SCPs).

What is RBAC

Role-Based Access Control (RBAC) is a traditional and widely used authorisation strategy. It defines permissions based on a person’s job function or role. Different IAM policies are created for different job functions, such as:

  • AdministratorAccess
  • PowerUser
  • ReadOnly

Other roles might include:

  • SystemAdministrator
  • DatabaseAdministrator
  • NetworkAdministrator

Custom policies can also be created (customer managed) and attached to IAM roles, users, or groups. Access can be further restricted to specific resources for refined permissions.

Example of RBAC IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListObjectsInBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::bucket-name"]
    },
    {
      "Sid": ”GetObjectActions",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": ["arn:aws:s3:::bucket-name/*"]
    }
  ]
}

However, when new resources are added, the IAM policies need to be updated. This requires constant administration and mapping of permissions to new and existing roles. Therefore, the RBAC model is less effective when authorisations are based on dynamic parameters. This can be addressed using the ABAC model.

What is ABAC

Attribute-Based Access Control (ABAC) is a more advanced authorisation strategy that bases authorisation on resource and user attributes (tags). You can attach tags to most AWS resources. A single policy or set of ABAC policies can be created for IAM principals (users or roles), and all IAM principals can refer to the same policy. IAM policies are designed to allow operations when the principal tag matches the resource tag.

  • Resource tag: Control access to resources based on their tags (aws:ResourceTag/key-name).
  • Principal tag: Control what the person making the request (the principal) is allowed to do based on the tags attached to that person’s IAM user or role (aws:PrincipalTag/key-name).

ABAC Authorisation

IAM principals (users/groups) assume IAM roles with predefined IAM permissions (policy) to allow access to AWS resources. The IAM roles and AWS resources are tagged (eg., Heart, Star, Lightning). Operations are allowed when the principal’s tag (IAM role tag) matches the resource tag.

Example of ABAC IAM Policy:

The EC2 start and stop operations are allowed if the principal tag matches the resource tag.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "ec2:startInstances",
      "ec2:stopInstances"
    ],
    "Resource": "*",
    "Condition": {"StringEquals": 
      {"aws:ResourceTag/CostCenter": "${aws:PrincipalTag/CostCenter}"}
    }
  }
}

For AWS resources that do not support tagging, you can use the principal tag as part of the resource name (ARN).

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "glue:GetDatabases"
    ],
    "Resource": [
      "arn:aws:glue::*:database/db-${aws:PrincipalTag/Department}"
    ]
  }
}

The ABAC model is very flexible in allowing dynamic and granular permissions. However, the ABAC model is difficult to implement as defining rules and policies require a significant effort to implement initially.

Why ABAC

ABAC provides several advantages over the traditional RBAC model:

  • Scalability: IAM permissions are more scalable. There is no need to update existing policies for new resources.
  • Fewer policies: You don’t have to create different policies for different job functions.
  • Flexibility: Teams can change and grow quickly, which is great for project development teams.
  • Granular permissions: ABAC allows for more granular permissions compared to RBAC.

You can configure your SAML-based or web identity provider to pass session tags to AWS. When identity users federate into AWS, the user attributes are applied to the resulting principal in AWS. You can then use ABAC to allow or deny permissions based on those attributes.

Key Considerations with ABAC:

  • User provisioning process: Ensure a well-defined user provisioning process (similar to RBAC).
  • Infrastructure-as-code: Use infrastructure-as-code because all humans make mistakes.
  • Tagging strategy: Define a consistent tagging strategy for resources.
  • Deploy SCPs: Use SCPs to deny deleting/modifying principal and resource tags.

Probable Use Cases:

  • Dev/Test environments: Where resources are constantly created and destroyed.
  • Multi-tenanted applications: That share the same backend resources, eg., S3 bucket.
  • Strict security environments: Where there’s a strict security change control on IAM policy creation.

Summary

The following table compares ABAC and RBAC at a high-level:

ABAC RBAC
Attribute based - principal/resource tags Role based - job functions
Better scalability Need to update permissions for new resources
Less policy management Different policy for different function
Granular permissions are possible Write policy that allows access to only specific resources

You can also use a mixed model depending on your requirements. There is no right or wrong choice; it all depends on your specific needs and security goals.

Combining RBAC and ABAC can provide some of the advantages of both models. RBAC is simpler to implement than ABAC. To provide an additional refinement, you can combine ABAC with RBAC. Using this hybrid approach enables simple administration and permissions assignment while permitting increased flexibility and granularity.

References