AWS Permission Boundaries and Service Control Policies Explained

Permission Boundaries and Service Control Policies

In AWS Identity and Access Management (IAM), there is a fundamental misunderstanding regarding how permissions are enforced. Many engineers believe that attaching an AdministratorAccess policy to a role makes that role an administrator. This is incorrect. IAM policies define what an entity can do, but they do not define what the entity is allowed to do in the context of the entire account or organization. To enforce strict security guardrails, especially in delegated administration models, you must use mechanisms that act as ceilings. These are Permission Boundaries and Service Control Policies (SCPs).

Part 4 of the AWS IAM Deep Dive series.

Both mechanisms share a critical characteristic: they never grant permissions. They only restrict the maximum permissions that can be obtained through attached IAM policies. Understanding this distinction is the first step toward building a secure, delegated infrastructure.

The Mechanism of Permission Boundaries

A permission boundary is an advanced feature that defines the maximum permissions that an IAM identity-based policy (user or role) can request. It acts as a safety net. Even if a user has an attached policy that grants s3:* access, if the permission boundary restricts S3 access to s3:GetObject only, the user can only perform s3:GetObject.

The mechanism works by intersecting the permissions from the attached IAM policy with the permissions defined in the boundary. The effective permissions are the intersection of these two sets. If the boundary does not explicitly allow an action, the action is denied, regardless of the attached policy. For detailed technical specifications, refer to the AWS IAM User Guide on Permission Boundaries.

The iam:PassRole Interaction

The most complex aspect of permission boundaries involves the iam:PassRole action. This action allows an IAM user or role to pass a role to an AWS service (like EC2, Lambda, or ECS) so that the service can assume that role.

Consider a scenario where a DevOps engineer needs to launch an EC2 instance. The engineer’s IAM role has an attached policy that grants ec2:RunInstances. However, the engineer must also pass a specific IAM role to EC2 so the instance can access S3 buckets.

If the engineer’s permission boundary does not explicitly allow iam:PassRole, the engineer cannot pass any role, even if their attached policy allows it. Furthermore, the permission boundary can restrict which roles can be passed. You can configure the boundary to allow passing only roles with specific tags or specific names. This prevents a compromised developer account from being used to assume a highly privileged role in the same account.

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/dev-role-*"
}

In this example, the boundary allows the user to pass only roles starting with dev-role-. If the user attempts to pass admin-role, the action is denied by the boundary, even if the attached policy permits it.

The Mechanism of Service Control Policies

Service Control Policies (SCPs) operate at a higher level than permission boundaries. They are attached to the AWS Organizations root, organizational units (OUs), or individual accounts, rather than to individual identities. SCPs restrict the maximum permissions available to all identities within the attached entity, including the root user.

Unlike standard IAM policies which are allow-lists, SCPs function as a guardrail that explicitly denies any action not explicitly allowed by the SCP's Allow section, unless an explicit deny is present in the SCP itself. This means SCPs do not just "override" IAM denies; they restrict the maximum permissions available from IAM policies by limiting the actions that any identity in that account can perform. If an action is not listed in the SCP's Allow section, it is denied, regardless of whether the IAM policy allows it. For comprehensive details, see the AWS Organizations User Guide on SCPs.

Delegated Administration and Guardrails

In a mature AWS environment, administration is often delegated. Development teams need the ability to manage their own resources, but security teams need to ensure that these teams do not compromise the security posture of the organization. This is where permission boundaries and SCPs work in tandem to provide effective guardrails for delegated administration.

Layered Defense

SCPs provide the outermost layer of defense, setting the baseline security posture for the entire organization. They ensure that no account can disable logging, use unauthorized services, or create overly permissive IAM policies.

Permission boundaries provide a finer-grained layer of control within individual accounts. They ensure that even if a security team delegates administrative rights to a development team, those developers cannot escalate their privileges beyond what is necessary for their tasks.

Example Scenario: A Development Account

Consider a development account within an organization. To enable the development team to manage their applications, the security team must first ensure that the SCP explicitly allows the necessary actions, such as iam:AttachRolePolicy and iam:PutRolePolicy. If the SCP is an allow-list, it must explicitly permit these actions for the relevant conditions.

Once the SCP allows these actions, the security team creates a permission boundary for the development team's IAM users. This boundary allows iam:GetRole, iam:PutRolePolicy, and iam:AttachRolePolicy for roles tagged with environment=dev. This allows the developers to manage the policies of their existing roles but prevents them from creating new roles or attaching policies to roles in other environments.

This layered approach ensures that developers have the autonomy to manage their applications while security teams maintain control over the overall security posture.

Conclusion

Permission Boundaries and Service Control Policies are not just additional IAM policies; they are structural mechanisms that define the limits of authority. By understanding that they restrict rather than grant permissions, engineers can design more secure and manageable AWS environments. In delegated administration models, these tools are indispensable for balancing operational flexibility with security compliance. Use SCPs to set organizational guardrails and permission boundaries to enforce least privilege at the entity level.