Intro to AWS Resource Control Policies (RCPs)

AWS recently announced Resource Control Policies (RCPs) as part of pre:Invent (announcement was made in November, 2024). This post will give you a high level overview of RCPs and should give you ideas of how RCPS can be utilized to improve your security posture.

Before we dig into RCPs, let's focus on principals, resources, and the previous methods for securing these entities.

Securing Principals and Resources

A principal is an entity that can perform actions within AWS, such as an IAM user, IAM role, or an AWS account. Resources are entities in AWS that you can manage and work with. From a security and governance perspective, we want to control who can interact with our AWS services and how they can interact. Prior to RCPs, here were the top methods for security both types of entities.

To control access for principals, there are identity policies at the more granular level and Service Control Policies (SCPs) that restrict the permissions identity policies can grant.

For resources, resource policies can enforce granular control, but there was no mechanism for limiting the actions that resource policies can provide across an organization. For what SCPs do for identities, RCPs do for resources.

With RCPs, we can enforce consistent security standards for resources. We can now control WHO can access our resources and HOW they can access resources, regardless as to whether the principals exist within our organization or are external (keep in mind that SCPs only control identities that exist within an AWS organization).

Resource Control Policies vs Service Control Policies

AWS has a nice table (shown below) to illustrate how RCPs and SCPs compare.

Keep the scope of each in mind as you plan out how to secure your AWS environments with SCP and RCP policies.

Common RCP Use Cases

Some common use cases covered by RCPs are:

• Establishing a data perimeter

• Enforcing secure access via HTTPS

• Restricting cross-account access

• Enforcing audit and compliance requirements

Establishing a Data Perimeter

A great use of RCPs is to set up a data perimeter for your AWS accounts. Data perimeters were possible prior to RCPs using resource policies, but it is now easier to ensure proper protection of the perimeter.

A common requirement of an AWS data perimeter is to prevent unknown accounts from assuming IAM roles. A very simple RCP policy to restrict access to trusted accounts is below.

{ 
    "Effect": "Deny", 
    "Principal": "*", 
    "Action": "sts:AssumeRole", 
    "Resource": "*", 
    "Condition": { 
        "StringNotEqualsIfExists": { 
            "aws:PrincipalOrgID": "<my-org-id>", 
            "aws:PrincipalAccount": [ 
                "<trusted-account-1>", 
                "<trusted-account-2>"
            ]
        } 
    } 
}

In this example, we are restricting access to assume a role to principals within the organization and to a list of trusted accounts. This ensures that even if a misconfiguration occurs, no untrusted external accounts may assume a role.

AWS has created a number of examples for establishing a data perimeter with RCPs and SCPs - those can be viewed here.

Enforcing secure HTTPS Access

To enforce HTTPS access across all services that are currently supported by RCP, the following example is provided by AWS:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceSecureTransport",
            "Effect": "Deny",
            "Principal": "*",
            "Action": [
                "sts:*",
                "s3:*",
                "sqs:*",
                "secretsmanager:*",
                "kms:*"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}

Services that RCP Supports

As the prior example shows, RCP does not yet support many of the AWS services. At the time that I wrote this, only the following AWS services are supported:

• STS
• S3
• SQS
• Secretsmanager
• KMS

However, I expect we will see more services supported soon.

Things to Keep in Mind

RCPs Require AWS Organizations

Resource Control Policies can ONLY be utilized within AWS organizations. If you haven't yet placed all of your AWS accounts under Control Tower and AWS Organizations, now is the time. I believe that we will continue to see more and more security and governance capabilities tied to AWS Organizations for providing protection at scale across your account portfolio.

RCPs only DENY

Like SCPs, Resource Control Policies do not grant privileges - they only define constraints.

Deploy with Caution

There is no "audit mode" with RCPs. Ensure you test your RCPs in a dev or test environment before establishing them in your critical production accounts.

Utilize Access Analyzer Before Implementing RCPs

Reviewing existing external access patterns would be wise before implementing any RCPs. This would show any external entities that have been provided with access to your resources, and you would want to ensure any new RCPs do not restrict that access if it is still a business requirement.

Summary

I hope that this post provides you with enough information to make you want to learn more. Here are some helpful links:

• AWS RCP announcement blog
• Building a Data Perimeter
• RCP Documentation
• How RCPs fit within AWS policy evaluation logic (single account)
• How RCPs fit within AWS policy evaluation logic (cross account)
• AWS RCP Examples on GitHub
• Authorization Policies in AWS Organizations: SCPs and RCPs

How are you planning to utilize RCPs? Let us all know in the comments!

My next post will dig a little deeper into RCPs and how to create your first couple of RCPs within AWS Organizations.

Connect with me on LinkedIn here.