In AWS Identity and Access Management (IAM), controlling access to resources is essential for security and proper governance. AWS provides powerful mechanisms to define and evaluate permissions, allowing flexibility to restrict or delegate access. Two core elements in IAM are Policy Evaluation Logic and Permission Boundaries. These advanced features let administrators fine-tune permissions, enabling controlled delegation and ensuring that users and roles cannot exceed predefined permissions.

This article provides an overview of IAM Policy Evaluation Logic, explains IAM Permission Boundaries, and explores their combined usage with real-world use cases.

IAM Policy Evaluation Logic: How Permissions Are Determined

IAM Policy Evaluation Logic determines how AWS assesses and grants permissions to users, roles, and resources. Understanding this logic is essential because AWS uses a consistent order of operations to evaluate whether a request should be allowed or denied based on the policies attached to the relevant IAM entity.

Here's how AWS evaluates a request for access:

  1. Explicit Deny: If any policy explicitly denies a request, the action is denied immediately, and AWS stops further evaluation. Denies always override any allows.
  2. Permission Boundary Evaluation: AWS checks if there is a permission boundary attached to the user or role. Permission boundaries act as a constraint and will limit what can be allowed by other policies.
  3. IAM Policies: AWS evaluates all relevant policies attached to the user or role. These can include inline policies, managed policies, and service control policies (SCPs) from AWS Organizations.
  4. Allow: If the action is explicitly allowed in at least one policy and not restricted by a permission boundary, then the action is permitted.
  5. Default Deny: If none of the policies explicitly allows the request and no permission boundary allows it, AWS denies the action by default.
None
source: https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html

Key Points in Policy Evaluation Logic

  • Explicit Denies Take Precedence: An explicit deny in any policy prevents access, even if other policies allow the action.
  • Permission Boundaries Act as a Ceiling: If a permission boundary is in place, it serves as an upper limit on what a user or role can do, regardless of what other policies allow.
  • Combination with Service Control Policies (SCPs): SCPs apply at the account or organizational unit (OU) level and can limit permissions across the entire account. These work alongside permission boundaries to ensure least-privilege access across the organization.

IAM Permission Boundaries: Setting Maximum Permissions for Users and Roles

IAM Permission Boundaries provide a way to set maximum permissions that a user or role can receive. They act as a limit or ceiling, ensuring that even if a user or role has broader permissions from other policies, they cannot exceed the permissions defined in their boundary.

Key Characteristics of IAM Permission Boundaries

  • Applied to Users and Roles: Permission boundaries can only be applied to individual users or roles, not groups.
  • Managed Policy Requirement: Permission boundaries must be defined using AWS managed policies or customer-managed policies.
  • Combination with Policies: When a permission boundary is attached to a user or role, any action must be allowed by both the permission boundary and the IAM policy to be effective. If an action is only allowed by one and not the other, access will be denied.

For example:

  • Permission Boundary + IAM Policy = No Permissions: If a permission boundary restricts access to certain actions, even if the IAM policy allows more, only the actions permitted in both will be granted.
None
source: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html

Use Cases for Permission Boundaries

  1. Delegating Responsibilities to Non-Administrators: Administrators can grant permission boundaries to allow trusted team members, such as junior administrators, to create and manage other users or roles within a controlled permission boundary. This delegation ensures that users created by the junior administrator cannot exceed the permission limits set by the senior administrator.
  2. Developer Self-Management: Allowing developers to self-assign policies can improve productivity, especially in development and test environments. However, permission boundaries prevent them from escalating their privileges, such as granting themselves administrator access.
  3. Fine-Grained Control for Specific Users: Permission boundaries can be applied to individual users, providing a way to restrict one person without impacting an entire account or organization, as would happen with an SCP applied to the entire account.

Permission Boundaries and AWS Organizations SCPs: A Powerful Combination

Permission boundaries can be combined with Service Control Policies (SCPs) from AWS Organizations to apply both account-level and individual-level access restrictions:

  • SCPs enforce policies at the account level, meaning they apply to all users, roles, and entities within an account or organizational unit.
  • Permission Boundaries can be applied at the individual user or role level, providing fine-grained control for specific IAM entities within the broader SCP framework.

For instance, consider an organization where SCPs restrict all users from accessing certain sensitive services across the account. Within this framework, permission boundaries can further restrict specific users or roles from creating certain resources or taking high-level actions, such as modifying account-wide configurations, within the permissions allowed by the SCP.

Example: Permission Boundary for a Developer Role

Consider a scenario where a company wants to allow developers to manage their own permissions to some extent but prevent them from escalating privileges.

  1. Permission Boundary Definition:
  • The permission boundary permits the developer role to attach policies related to reading and writing resources but restricts access to high-privilege actions, such as iam:CreateRole or iam:AttachUserPolicy for any administrative policies.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "ec2:Describe*",
        "cloudwatch:PutMetricData"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Deny",
      "Action": [
        "iam:CreateRole",
        "iam:AttachUserPolicy"
      ],
      "Resource": "*"
    }
  ]
}

2. IAM Policy for Developer Role:

  • A managed policy allows developers to manage their own permissions but stays within the bounds set by the permission boundary.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetObject",
        "s3:PutObject",
        "ec2:DescribeInstances"
      ],
      "Resource": "*"
    }
  ]
}

This setup ensures that developers can self-manage certain permissions but cannot assign themselves any role that could potentially increase their privileges.

Summary

IAM Permission Boundaries and IAM Policy Evaluation Logic provide AWS administrators with essential tools for managing permissions effectively. By understanding how policy evaluation logic processes allow and deny actions, and by using permission boundaries, administrators can implement finely-tuned permissions that secure resources and meet business requirements.

  • Policy Evaluation Logic determines access based on a hierarchy of allow and deny decisions.
  • Permission Boundaries provide a ceiling on what actions a user or role can perform, even if granted additional permissions.
  • Combined with Service Control Policies (SCPs), permission boundaries allow administrators to delegate specific responsibilities safely while maintaining organizational control.

For more detailed information on IAM Policy Evaluation Logic, cross-account policy evaluation, and using permission boundaries, you can explore the following resources:

These resources offer in-depth examples, best practices, and sample policies to help secure your AWS environment.

By Alice the Architect Cloud Solutions Architect, AWS expert, and tech writer on a mission to simplify cloud architecture choices for developers and architects alike.

In Plain English 🚀

Thank you for being a part of the In Plain English community! Before you go: