This article is on one of the new features AWS released recently, called Resource Control Policies (RCPs).

RCPs are a new way to enforce policies on data (resources) rather than principals in AWS. For principals, the way to enforce policies is to use Service Control Policies (SCPs), which if you’re already familiar with AWS would know plenty about. However, RCPs can still be a little confusing.

What are RCPs?

If we consider an AWS account as a single “permission domain”, there are mutltiple artefacts involved when determining whether a principal can perform a given action or not.

There are permission policies, permission boundaries, session policies, and SCPs involved in the Policy Evaluation Logic.

Out of these permission policies can be divided into two types.

  1. identity policies that apply to principals (users, roles, service principals, and groups. technically groups are not a principal type)
  2. resource policies that are applied to resources like S3 bucket policies, SQS policies etc

In a permission policy, you specify statements that contain a list of permissions that are either allowed or denied to a set of principals on a set of resources, under a set of conditions.

While permission policies grant permissions, there should be a mechanism to limit the maximum boundary of permissions granted by these policies.

This is because, in most cases, the persona that handles the overall organisation security and configuration posture is different from the persona that works with the granted permissions, or even the persona that grants permissions. There are distinct job role differences between these parties, and AWS provides mechanisms for all of them to work together.

Permission boundaries provide this functionality while being coupled to a specific principal.

SCPs provide another side of this policy enforcement where it determines the maximum of permissions coupled to a permission domain, an account, an Organization Unit, or even the entire Organization.

Even if a identity policy grants a certain permission, if an SCP denies it, or if the Permission Boundary doesn’t contain the permission, the action is denied for that principal.

However, both of these control features apply to principals, i.e. permissions granted with identity policies.

RCPs are a way to apply policy enforcement to data at rest, permissions granted by resource policies.

Usage

Like SCPs, RCPs can be applied at any level of the Organization hierarchy, starting from the Root to individual accounts. It is accumulative, which means RCPs applied at the top of the hierarchy are inherited by child nodes.

While RCPs can be applied at any level, it is advisable to start testing RCPs at a lower level, like a sandbox account, and then “graduate” them to proper level once tested. Otherwise, there’s a chance that you’ll break existing functionality of the systems deployed in AWS.

Because they both target the same problem space, SCPs and RCPS both can be used to tackle the same problem sometimes, but RCPs are mostly advisable to be deployed to build a “data perimeter” as AWS calls it. You can use RCPs to determine which level of access your data resources will provide, irrespective of who is accessing it. It’s a resource oriented (pivoted) view of the policy enforcement model.

For an example, with RCPs, you can define a policy that will not allow anyone to open up S3 buckets in your AWS Organization. If this was to be done with SCPs, you may have to restrict operations that change bucket policy content, which is a different point of view than actually guarding the resources. SCPs guard user actions, while RCPs guard resources.

With the above policy applied to your specific “sensitive” OU or even the Root of the Organization, you can comfortably delegate full control of the AWS accounts or OUs under it to different parts of the organisation, or even outside parties as needed. You don’t have to worry about their full control since the level of access that they can grant to the S3 buckets is dictated by the RCP that is applied at level higher than those accounts.

Demo

There’s an demo of the feature in the AWS blog post that I linked above, however, “off the beaten path” is always good. I came up with another example, just to see if there are limits to advertised features.

In this setup, I have two accounts, workload_a and backup, and I’ve created a KMS key with a key policy in the workload_a account that allows users from the backup account to describe it.

With this policy in place (and with matching identity policies for cross-account access) I can successfully describe the key.

Now, conditions change, and workload_a is designated as an account that has sensitive data. It’s KMS keys should not be exposed to any party outside the account. I can implement this as an RCP that is applied to the workload_a account.

To do this, RCPs have to be enabled as a feature. This has to be done at the Organization Management account.

Go to AWS Organizations console in the Management account, then to the Policies page, and scroll down to check if RCPs are enabled. If not, it’s a simple click to enable it. This action has no cost attached to it.

After the RCPs are enabled, a new policy can be created for our requirement.

When RCPs are enabled, a default RCP called RCPFullAWSAccess is created and attached to the Organization Root. This has an umbrella Allow All statement, which makes sure that existing operations will not break, just by enabling the feature.

What this statement does is to deny kms:DescribeKey permission to any principal if they are not from the workload_a account or if they are not an AWS Service.

Using Allow statements in SCPs or RCPs do not grant permissions. They just enable granting that permission.

I then attach this RCP to the workload_a account.

With this RCP attached, if I try to perform the above kms describe-key action again, I’m going to get an access denied message, because even though the Key policy grants kms:DescribeKey, there’s an explicit deny in the mix provided by the RCP.

Having a RCP that denies a permission doesn’t mean you can’t apply resource policies that allow that specific permission. The RCP comes into play during the Policy Evaluation logic, not during the policy attachment to resources.

Conclusion

  1. Use RCPs to setup a “data perimeter”
  2. RCPs (or SCPs) do not “grant” permissions, they define the maximum boundary for permission policies
  3. RCPs are SCPs but for resource policies (with some caveats)