AWS IAM Policies PART 2 : Permission Boundaries and Service Control Policies

1. Permission Boundaries

Permission Boundary is an advanced feature that allows you to set limits on the maximum permissions an IAM entity (like a user or role) can have. Essentially, it acts as a second layer of control over the permissions defined in the entity's attached IAM policies.

Here’s how it works:

• IAM Policies define what actions and resources an entity can access.

• Permission Boundaries restrict those actions by setting a boundary. Even if a policy grants broad permissions, the actions are limited to what the permission boundary allows.

Key Points:

• IAM Policies: Grant permissions to entities (users, roles).

• Permission Boundaries: Define the maximum permissions that an entity can have. It restricts the permissions granted by the policies.

• The entity's actual permissions are the intersection of permissions in the IAM policy and the permission boundary.

Example 1: User without a Permission Boundary

Suppose you have a user with the following policy attached:

This policy gives user full access to all S3 resources. Without a permission boundary, Alice can perform any action in S3, including creating or deleting buckets, uploading or deleting objects, etc.

Example 2: Applying a Permission Boundary to the User

Now, you want to ensure that user can only read objects from S3, regardless of what their policies say. You attach the following permission boundary to their IAM user:

With this permission boundary, even though users IAM policy allows them to perform any S3 action, their effective permissions will be limited to just the s3:GetObject action. The boundary overrides the policy to ensure they can only read S3 objects, not create, modify, or delete them.

How Effective Permissions are Determined

When permission boundaries are applied, the actual permissions of the user or role are the intersection of:

• IAM Policies: What the policy allows.

• Permission Boundaries: What the boundary limits.

In the example above:

• IAM Policy: Allows s3:* (all actions).

• Permission Boundary: Limits actions to s3:GetObject.

• Effective Permission: User can only perform s3:GetObject because it is the only action allowed by both the policy and the boundary.

Example 3: Using a Role with Permission Boundaries

Consider a role, S3AdminRole, used by different teams. The role’s policy grants full access to S3:

However, you don’t want junior engineers to have full administrative privileges. You create a permission boundary for their role that only allows them to read S3 objects and list buckets:

Even though the S3AdminRole policy allows full access (s3:*), the effective permissions for junior engineers will be constrained by the boundary, allowing them to only list and read objects.

We can combine Permission Boundaries with Multi-Factor Authentication (MFA) to enforce stricter security controls. A common use case is requiring MFA for specific sensitive actions while using permission boundaries to limit the scope of what a user or role can do, even if they are authenticated.

Example Scenario: User with Permission Boundary and MFA Requirement

Let’s say you have a user, Bob, who has the following requirements:

1. Bob can list and read S3 buckets without MFA.

2. Bob can create or delete S3 objects, but only after authenticating with MFA.

3. Bob’s actions are further restricted by a permission boundary to ensure that he can’t modify any resources other than S3 objects (even if his policy grants broader permissions).

   

   Use Cases for Permission Boundaries

   1. Delegated Administration: When delegating admin permissions to other teams or individuals, permission boundaries ensure they cannot grant excessive privileges to users, even if they have permissions to create roles and policies.

   2. Control Over Temporary Roles: For temporary roles that require elevated permissions, permission boundaries can limit what these roles can do, ensuring they don’t exceed security requirements.

   3. Multi-Account Environments: In a multi-account setup, permission boundaries help enforce organization-wide security constraints, ensuring no user or role exceeds permitted actions.

Service Control Policies (SCPs)

Service Control Policies (SCPs) are a feature of AWS Organizations that allow you to manage permissions across all accounts in an organization. SCPs help ensure that accounts can only perform the actions you explicitly allow or deny, regardless of the permissions defined in individual IAM policies within those accounts.

Key Concepts:

• SCPs apply to AWS accounts that are part of an AWS Organization.

• They do not grant permissions by themselves; they set the maximum permissions an account (or the entities in that account) can have.

• SCPs are applied at the organization root, organizational units (OUs), or individual AWS accounts.

• They control what actions the users, roles, and root users within an account can perform on AWS services.

Structure of an SCP

SCPs are similar to IAM policies, using JSON format to define allowed or denied actions. However, unlike IAM policies, SCPs are always evaluated and can limit even the root user of an account.

• Allow list mode: Define actions that are allowed (everything else is denied).

• Deny list mode: Define actions that are explicitly denied (everything else is allowed).

How SCPs Work

1. SCPs Limit Permissions: They act as a filter. The effective permissions for an account are the intersection of:

   • The SCP applied to the account or OU.

   • The IAM policies within that account.

If an action is allowed by both the IAM policy and the SCP, the action will succeed. If the SCP denies the action, it will not succeed, even if the IAM policy allows it.

2. No Implicit Denies in SCPs: SCPs work only by allowing or explicitly denying actions. If a service action is neither allowed nor denied, the action is implicitly denied.

3. Root User and SCPs: Even the root user of an account is subject to SCP restrictions. SCPs can effectively prevent root users from performing certain actions, adding an additional security layer.

Example 1: Deny All Except Specific Services

You want to create an SCP that denies all actions in the AWS account except for basic read-only operations on S3 and EC2. Here’s an example of what this SCP might look like:

Explanation:

• This SCP allows only the read-only actions for S3 (s3:Get*) and EC2 (ec2:Describe*).

• Any other service or action is implicitly denied.

• Even if an account’s IAM policy allows writing to S3 or creating EC2 instances, the SCP prevents those actions.

Use Case:

• You might use this for accounts that should only have read-only access to S3 and EC2 (e.g., in a logging or monitoring account).

Example 2: Denying Specific Actions Across the Organization

In this example, you want to ensure that no account in your organization can delete or modify IAM users or roles (to prevent accidental privilege escalation). You can create an SCP that explicitly denies these actions:

Explanation:

• This SCP explicitly denies the ability to delete IAM users, roles, and groups, or attach inline policies to them.

• Even if an IAM policy within a specific account grants these actions, the SCP will override it and prevent them.

• This is helpful in ensuring that no one in the organization can modify sensitive IAM resources.

Use Case:

• You might apply this SCP to your entire organization or to specific OUs (e.g., a production OU) to ensure security best practices are followed.

Example 3: Limiting Access to Specific AWS Regions

Suppose you want to restrict certain accounts in your organization to only use AWS resources in the US East (N. Virginia) (us-east-1) region. You can create an SCP that denies all actions in any region except us-east-1:

Explanation:

• This SCP denies all actions in any AWS region except us-east-1.

• The aws:RequestedRegion condition ensures that actions in other regions are denied.

• Even if an IAM policy within an account allows using services in other regions, this SCP will prevent it.

Use Case:

• You might apply this to accounts in environments that need to be region-locked for compliance or cost control reasons, ensuring that all resources are created and managed in a specific region.

Example 4: Allow Only Specific AWS Services

Suppose you have a development environment where you want to limit access to only a few services (like S3, EC2, and Lambda) to reduce complexity and minimize costs. You could create an SCP like this:

Explanation:

• This SCP allows all actions for S3, EC2, and Lambda, but nothing else.

• Any other service (e.g., RDS, CloudFormation) is implicitly denied.

Use Case:

• You might apply this SCP to accounts in a development OU where you want to restrict access to a few key services to keep things simple and reduce costs.

How SCPs and IAM Policies Interact

To summarize how SCPs interact with IAM policies:

• SCPs do not grant permissions. They only set the boundaries for what actions are allowed or denied at the account level.

• The IAM policies attached to users, groups, and roles in the account determine what permissions they have within the scope set by the SCP.

For example:

• If an SCP denies EC2 instance deletion, an IAM user with full EC2 permissions would still be unable to delete an EC2 instance because the SCP overrides the IAM policy.

• On the other hand, if the SCP allows S3 read-only actions, and an IAM policy also allows those actions, the user will be able to read from S3.

Key Use Cases for SCPs

1. Enforcing Guardrails: Use SCPs to prevent risky or sensitive actions (like deleting IAM users, using certain regions, or launching certain instance types) across your entire organization or specific OUs.

2. Restricting Services: Apply SCPs to allow only certain AWS services (e.g., S3 and EC2) to be used in development environments, minimizing security and cost risks.

3. Region Locking: Prevent resources from being created outside of specific AWS regions to meet compliance or governance requirements.

4. Ensuring Best Practices: Enforce security policies, such as preventing modifications to logging and monitoring infrastructure, using SCPs across all accounts.

SCPs are a powerful way to apply organization-wide governance and ensure security best practices across all AWS accounts in an organization.

The difference between AWS IAM Permission Boundaries and AWS Service Control Policies (SCPs) lies in their scope, purpose, and application within AWS. Here’s a breakdown of how they differ:

1. Scope and Application

• Permission Boundaries:

  • Apply to IAM users or IAM roles within a single AWS account.

  • Set a maximum limit on the permissions that can be assigned to an IAM user or role.

  • Restrict the actions that a specific IAM entity (user or role) can perform, but only within the account where the boundary is applied.

  • Can be thought of as a restrictive IAM policy for a particular user or role that defines the maximum possible permissions, even if broader permissions are granted by other IAM policies.

• Service Control Policies (SCPs):

  • Apply to AWS accounts that are part of an AWS Organization.

  • Control the maximum permissions that any IAM entity (users, roles, and even the root user) in the account can have.

  • Affect all users, roles, and resources within the account(s) to which they are applied.

  • SCPs are applied at the organization root, organizational unit (OU), or individual account level, governing what actions are allowed or denied across entire accounts.

2. Purpose and Use Case

• Permission Boundaries:

  • Used to delegate control to specific users or roles without granting excessive permissions.

  • Useful when you want to delegate permission management (e.g., allow developers to create IAM roles) but ensure that they can only create roles with limited permissions.

  • Commonly used to control permissions within a single AWS account for specific users/roles.

• Service Control Policies (SCPs):

  • Used to govern and enforce permissions across multiple AWS accounts within an AWS Organization.

  • Useful for setting organization-wide guardrails or security controls to prevent certain actions (e.g., prevent deletion of S3 buckets or launching EC2 instances in specific regions).

  • SCPs help enforce compliance and security policies at a higher level, across multiple accounts, including preventing even the root user from performing certain actions.

3. Where They Apply

• Permission Boundaries:

  • Apply only to IAM users or roles within a single AWS account.

  • The boundary limits what the user or role can do within that account.

• Service Control Policies (SCPs):

  • Apply to AWS accounts within an AWS Organization.

  • Control what all users, roles, and even the root user of the account can do.

4. How Permissions Are Evaluated

• Permission Boundaries:

  • The actual permissions of a user or role are the intersection of:

    • The IAM policies attached to the user or role.

    • The Permission Boundary attached to the user or role.

  • If a permission is granted by the IAM policy but denied by the boundary, the action will be denied.

• Service Control Policies (SCPs):

  • The effective permissions for an AWS account are the intersection of:

    • The IAM policies within that account.

    • The SCP applied to the account or its parent organizational unit (OU).

  • Even if an IAM policy grants broad permissions, the SCP can override it, limiting the actions allowed across the entire account.

5. Granting vs. Limiting Permissions

• Permission Boundaries:

  • Do not grant permissions by themselves; they only define the maximum permissions an entity (user/role) can have.

  • Permission boundaries are typically more restrictive and limit what users or roles can do, even if their IAM policies grant broader access.

• Service Control Policies (SCPs):

  • Do not grant permissions by themselves; they only define what actions are allowed or denied at the account level.

  • SCPs act as an overarching policy that limits what any IAM entity in an account can do, providing guardrails for security and governance across multiple accounts.

6. Effect on Root User

• Permission Boundaries:

  • Do not apply to the root user of an AWS account. The root user can still perform any action, even if permission boundaries are in place.

• Service Control Policies (SCPs):

  • Apply to all users, including the root user of an AWS account.

  • If an SCP denies an action, even the root user is prevented from performing it.

Example Comparison

Example 1: Permission Boundaries

You have a developer, Alice, who needs to create IAM roles but shouldn’t be able to create roles with permissions beyond what is strictly necessary for her tasks.

• IAM Policy: Grants Alice permission to create IAM roles.

• Permission Boundary: Restricts Alice to creating roles with only S3 read access.

Even if Alice’s IAM policy grants her permission to create roles with broad permissions, the permission boundary ensures that the roles she creates can only have S3 read permissions.

Example 2: Service Control Policy (SCP)

You manage a multi-account organization and want to ensure that no one in the organization (including the root user) can delete S3 buckets or launch EC2 instances outside of us-east-1.

• SCP: Denies the s3:DeleteBucket action and denies any EC2 actions outside of the us-east-1 region.

Even if individual account policies allow S3 bucket deletion or EC2 actions in other regions, the SCP will override these permissions and prevent the actions from happening across the entire organization.

Both Permission Boundaries and SCPs are important tools for securing and managing permissions in AWS, but they operate at different levels and are used for different purposes.