AWS Resource Control Policies (RCPs): Everything You Need To Get Started

Intro

AWS just introduced resource control policies (RCPs). This article covers RCPs, including related services such as IAM Access Analyzer and Control Tower, and related content, such as articles and workshops. We also discuss some use cases, recommendations, and implications.

In short, RCPs are to resource-based policies what SCPs are to identity-based policies. You use them to apply invariants across your organization on how and by whom certain resources can be accessed. Here are some examples:

• Are you sure no S3 bucket or SQS queue should ever be publicly writable across all your AWS accounts? Use an RCP
• Want to ensure all S3 buckets use KMS encryption? Use an RCP
• Want to control the third-party principals who can assume roles across your AWS accounts? Use an RCP

AWS Services & Content

This article is not intended to duplicate information already found in the AWS documentation and other sources. The purpose of the article is to compile the main sources of information you can use to understand RCPs and how to deploy them within your organization, so here they are:

1. The Official AWS Documentation

This is where you should start if you want to understand more about RCPs. Here are some takeaways:

• You can use RCPs for S3, STS (i.e., IAM roles), KMS, SQS, and Secrets Manager.
• Similar to SCPs, RCPs do not grant permissions. You can only use RCPs to limit permissions (i.e., set permission boundaries). You still need IAM/resource policies to grant the actual permissions. This is why you can only use Deny statements.
• RCPs are not intended to control permissions at a granular scope (e.g., for specific resources or specific identities). This is why you can only use * as the principal.
• RCPs do not apply to the organization management account, service-linked roles, and AWS-managed KMS keys. Please do not use the management account to run workloads.
• Unlike SCPs, which apply only to identities within the AWS organization, RCPs apply to all requests reaching your resources.

2. The “Establishing a Data Perimeter on AWS” Blog Series

The AWS team has already updated their blog series to include RCPs 👏. The articles provide excellent use cases for RCPs in building a data perimeter on AWS. Here are some takeaways:

• Your data perimeter comprises the trusted identities, trusted resources, and expected networks. RCPs help ensure that only trusted identities from expected networks can access your data.
• If you have already built a data perimeter, you relied on resource-based policies. In this context, RCPs replace resource-based policies (for the supported services), making establishing the perimeter across multiple accounts easier.
• The data perimeter heavily relies on the following global condition keys to ensure the trusted identities part: aws:PrincipalOrgID, aws:SourceOrgID, aws:SourceAccount, and aws:PrincipalAccount. The second article in the series provides excellent explanations and examples of using these condition keys.
• To check the expected networks, you will leverage aws:SourceIp, aws:SourceVpc, aws:SourceVpce condition keys to ensure your data is accessed only from expected networks. Applying network controls keeps your data secure even if an attacker obtains valid IAM credentials as long as they are not within the expected networks (committing credentials to public repos still happens). The fourth article in the series has some great references on this.
• You must exclude certain AWS services (service principals) interacting with your data from your RCPs, such as CloudTrail storing logs into your S3 buckets or S3 calling KMS to encrypt objects. You achieve this by leveraging aws:PrincipalIsAWSService and aws:ViaAWSService condition keys. If those are true, your RCP should not Deny the request.

You can also check out the “Building A Data Perimeter on AWS” AWS whitepaper, which the AWS team updated 👏. It provides good explanations, especially about the exceptions required for certain AWS services.

Last, you should also check out the Data Perimeter Workshop and Data Perimeter In Action workshops. They are still to be updated to use RCPs instead of resource-based policies, but they provide excellent learning opportunities nonetheless.

3. IAM Access Analyzer

You can use IAM Access Analyzer External Access (highly recommended; it’s free) to identify resources that can be accessed from outside your zone of trust (AWS organization or account). If you are wondering if it already considers resource control policies (RCPs), it does. It will even tell you when an RCP influences a finding, and you can identify resources that are not yet covered (or supported) by RCPs - the “Resource control policy restriction” field (there is a new column in the findings table) will be set to “Not applicable”.

Moreover, since the Policy Editor uses IAM Access Analyzer to validate policies as you author them, you benefit from the RCP coverage there, too. It even helps you properly use the condition keys mentioned above. You can find all the supported checks in the reference documentation.

One important mention is that, unlike resource-based policies, changing RCPs does not trigger a re-scan of the applicable resources. You will see the updated findings within 24 hours after the analyzer performs its scheduled scan.

4. AWS Control Tower

If you use AWS Control Tower to govern your AWS Organization and apply controls/guardrails to your AWS accounts, you now have access to a new set of preventive controls, the AWS Control Tower RCP controls.

Even if you don’t use AWS Control Tower, you can still leverage the controls since they are just RCPs (replace the parameters with your actual values). For example, you can require encryption of data in transit for calls to Amazon S3 resources or require that the organization's Amazon SQS resources are accessible only by IAM principals that belong to the organization, or by an AWS service.

For more examples, check out the data perimeter policy examples GitHub repo.

Infrastructure as Code

CloudFormation doesn’t support RCPs yet, but a new type, RESOURCE_CONTROL_POLICY, will most likely be available for AWS::Organizations::Policy.

For Terraform, the PR is open.

The Well-Architected Framework

The Well-Architected Framework is an entire ecosystem, including the framework itself, the Well-Architected Tool, lenses, partners, workshops, and more. Expect to see updated best practices (BPs) for the data protection questions and those involving external parties, such as SEC03-BP09: Share resources securely with a third party.

FAQs

AWS has already added a few mentions about the RCPs in the AWS Organizations FAQs. Here are a few additional clarifications you might need:

• Do RCPs apply to S3 buckets using access control lists (ACLs)?

  Yes. For example, if you have an S3 bucket made public using an ACL (no bucket policy), you can still deny access to the bucket using RCPs.

• Do RCPs apply to S3 presigned URLs?

  Yes. Presigned URLs use the identity of the principal that generated the URL. The access is evaluated as described in the Policy Evaluation Logic documentation.

• Do RCPs apply to the root user?

  Yes.

• How will RCPs affect resource-based policies?

  You can still use resource-based policies like before. RCPs do not prohibit you from changing resource-based policies unless they specifically intend to achieve this (e.g., an RCP might deny s3:PutBucketPolicy). However, the effective permission evaluated for each request will also consider RCPs.

• Do RCPs apply to requests within the same AWS account?

  Yes. For example, if you set an RCP to deny all S3 actions, no one in the organization or outside of it will be able to interact with any S3 buckets affected by the RCP.

Conclusion

We now have a simple mechanism for controlling access to our S3 buckets, SQS queues, IAM roles, KMS keys, and Secrets Manager secrets in the form of resource control policies (RCPs). Use it to streamline your data perimeter policies or to enforce security invariants, such as no public buckets, no plain HTTP data transfer, or no old TLS. Make sure to test RCPs with a subset of your accounts before applying them at a larger scale.