When building workloads in the public cloud, one of the most fundamental topics to look at is permissions to access resources and take actions.
This is true for both human identities (also known as interactive authentication) and for application or service accounts (also known as non-interactive authentication).
AWS offers its customers multiple ways to enforce guardrails – a mechanism to allow developers or DevOps teams to achieve their goals (i.e., develop and deploy new applications/capabilities) while keeping pre-defined controls (as explained later in this blog post).
In this blog post, I will review the various alternatives for enforcing guardrails in AWS environments.
Service control policies (SCPs)
SCPs are organizational policies written in JSON format. They are available only for customers who enabled all features of AWS Organization.
Unlike IAM policies, which grant identities access to resources, SCPs allow configuring the maximum allowed permissions identities (IAM users and IAM roles) have over resources (i.e., permissions guardrails), within an AWS Organization.
SCPs can be applied at an AWS Organization root hierarchy (excluding organization management account), an OU level, or to a specific AWS account in the AWS Organization, which makes them impact maximum allowed permissions outside IAM identities control (outside the context of AWS accounts).
AWS does not grant any access by default - if an AWS service has not been allowed using an SCP somewhere in the AWS Organization hierarchy, no identity will be able to consume it.
A good example of using SCP is to configure which AWS regions are enabled at the organization level, and as a result, no resources will be created in regions that were not specifically allowed. This can be very useful if you have a regulation that requires storing customers' data in a specific AWS region (for example – keep all EU citizens’ data in EU regions and deny all regions outside the EU).
Another example of configuring guardrails using SCP is enforcing encryption at rest for all objects in S3 buckets. See the policy below:
SCPs are not only limited to security controls; they can also be used for cost. In the example below, we allow the deployment of specific EC2 instance types:
Source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_syntax.html
When designing SCPs as guardrails, we need to recall that it has limitations. A service control policy has a maximum size of 5120 characters (including spaces), which means there is a maximum number of conditions and amount of fine-grain policy you can configure using SCPs.
Additional references:
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
- https://github.com/aws-samples/service-control-policy-examples
Resource control policies (RCPs)
RCPs, similarly, to SCPs are organizational policies written in JSON format. They are available only for customers who enabled all features of AWS Organization.
Unlike IAM policies, which grant identities access to resources, RCPs allow configuring the maximum allowed permissions on resources, within an AWS Organization.
RCPs are not enough to be able to grant permissions to resources – they only serve as guardrails. To be able to access a resource, you need to assign the resource an IAM policy (an identity-based or resource-based policy).
Currently (December 2024), RCPs support only Amazon S3, AWS STS, Amazon SQS, AWS KMS and AWS Secrets Manager.
RCPs can be applied at an AWS Organization root hierarchy (excluding organization management account), an OU level, or to a specific AWS account in the AWS Organization, which makes them impact maximum allowed permissions outside IAM identities control (outside the context of AWS accounts).
An example of using RCP can be to require a minimum version of TLS protocol when accessing an S3 bucket:
Source: https://github.com/aws-samples/resource-control-policy-examples/blob/main/Service-specific-controls/S3-Enforce-TLS-version.json
Another example can be to enforce HTTPS traffic to all supported services:
Source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps_examples.html
Another example of using RCPs is to prevent external access to sensitive resources such as S3 buckets.
Like SCPs, RCPs have limitations. A resource control policy has a maximum size of 5120 characters (including spaces), which means there is a maximum number of conditions and amount of fine-grain policy you can configure using RCPs.
Additional references:
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html
- https://github.com/aws-samples/resource-control-policy-examples
- https://github.com/aws-samples/data-perimeter-policy-examples
Declarative policies
Declarative policies allow customers to centrally enforce a desired configuration state for AWS services, regardless of changes in service features or APIs.
Declarative policies can be created using AWS Organizations console, AWS CLI, CloudFormation templates, and AWS Control Tower.
Currently (December 2024), declarative policies support only Amazon EC2, Amazon EBS, and Amazon VPC.
Declarative policies can be applied at an AWS Organization root hierarchy, an OU level, or to a specific AWS account in the AWS Organization.
An example of using Declarative policies is to block resources inside a VPC from reaching the public Internet:
Source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html
Another example is to configure default IMDS settings for new EC2 instances:
Source: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative_syntax.html
Like SCPs and RCPs, Declarative policies have their limitations. A declarative policy has a maximum size of 10,000 characters (including spaces).
Additional references:
- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_declarative.html
- https://aws.amazon.com/blogs/aws/simplify-governance-with-declarative-policies/
- https://docs.aws.amazon.com/controltower/latest/controlreference/declarative-controls.html
Permission boundaries
Permission boundaries are advanced IAM features that define the maximum permissions granted using identity-based policies attached to an IAM user or IAM role (but not directly to IAM groups), effectively creating a boundary around their permissions, within the context of an AWS account.
Permissions boundaries serve as guardrails, allowing customers to centrally configure restrictions (i.e., limit permissions) on top of IAM policies – they do not grant permissions.
When applied, the effective permissions are as follows:
- Identity level: Identity-based policy + permission boundaries = effective permissions
- Resource level: Resource-based policy + Identity-based policy + permission boundaries = effective permissions
- Organizations level: Organizations SCP + Identity-based policy + permission boundaries = effective permissions
- Temporary Session level: Session policy + Identity-based policy + permission boundaries = effective permissions
An example of using permission boundaries to allow access only to Amazon S3, Amazon CloudWatch, and Amazon EC2 (which can be applied to a specific IAM user):
Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
Another example is to restrict an IAM user to specific actions and resources:
Source: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
Like SCPs, RCPs, and Declarative policies, permission boundaries have their limitations. A permission boundary has a maximum size of 6144 characters (including spaces), and you can have up to 10 managed policies and 1 permissions boundary attached to an IAM role.
Additional references:
- https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html
- https://aws.amazon.com/blogs/security/when-and-where-to-use-iam-permissions-boundaries/
- https://github.com/aws-samples/example-permissions-boundary
Summary
In this blog post, I have reviewed the various alternatives that AWS offers its customers to configure guardrails for accessing resources within AWS Organizations at a large scale.
Each alternative serves a slightly different purpose, as summaries below:
I encourage you to read AWS documentation, explaining the logic for evaluating requests to access resources:
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic_policy-eval-denyallow.html
I also highly recommend you watch the lecture "Security invariants: From enterprise chaos to cloud order from AWS re:Invent 2024":
https://www.youtube.com/watch?v=aljwG4N5a-0
About the author
Eyal Estrin is a cloud and information security architect, an AWS Community Builder, and the author of the books Cloud Security Handbook and Security for Cloud Native Applications, with more than 20 years in the IT industry.
You can connect with him on social media (https://linktr.ee/eyalestrin).
Opinions are his own and not the views of his employer.
Top comments (0)