AWS Resource Control Policies

In the last couple of weeks there have been a few announcements coming out of AWS. Normally at this time of year it appears to be features that are ready for Re:Invent, but didn't make the cut for a big conference announcement.

Re:Invent is a massive event but there are only so many announcement, some must not make the list. There is a limit to what you can publicise in what is effectively 4 days! I have no idea what the exact criteria for being important enough for a Re:Invent announcement are. But I guess one of the important ones is creating a coherent picture that will excite investors. That means some great features will not make the list. Th good news is they often drop early so we can get them sooner.

Resource Control Policies are a great security feature but are not going to excite the world like big GenAI launches!

Resource Control Policies (RCPs) are another organisational level control. They can only be used if you are using all the organisational controls and not just consolidated billing.

RCP complement the existing Service Control Policies (SCPs) that have been around for a while.

One very important thing to note with both SCP and RCP is they are guard rails. They can be used to prevent access. They remove permissions already granted (i.e. by an IAM policy). They can't on their own grant any access.

RCP vs SCP

RCP and SCP are very similar and sometimes can be used to achieve exactly the same thing. The main difference is an RCP is resource centric whereas a SCP is principal centric (ie a user or role).

This is pretty much the same as an IAM policies and resource policies (like s3 bucket policies) within an account.

A SCP refers to a principal whereas a RCP refers to a specific resource. This does get slightly confusing as many 'global' controls are applied to all principals using a SCP.

One key difference is is that RCP can be used to control access to resources where an account principal is not required. This includes any unauthenticated access (like a public s3 bucket) and cross account access.

Account structure

A big warning - RCPs do not apply to any resources in the management account. However this should not be a problem for most users who follow best practice and use the management account just for policies and billing.

RCPs will work best if you think about your account structure. Splitting up your resources between different accounts is important. You can then separate control and also apply RCPs and other policies more selectively.

There are many ways to design your AWS organisational structure and each has their own advantages. There are a couple of recommendations I follow:

• Split up production and non-production services
• Never put anything you don't need to in the master account.
• Separate out IAM access and then use assumed roles to use specific accounts
• Think about how to structure OU to best apply policies
• Separate out shared services like any audit requirements

Here is a possible account structure that groups accounts by product. Another common way to group accounts is putting all development and production accounts in their own Organisational units (OU). This will depend on your policy requirements.

- Master account
- Audit Account
- IAM users
-Networking OU
    - Production
    - Development
    - Test
    - Backup
- Products OU
    - Product 1 OU
        - Production
        - Development
        - Test
        - Backup
    - Product 2 OU
        - Production
        - Development
        - Test
        - Backup
...        

AWS Organisations are hierarchical. You need to best decide how to structure your organisation to apply policies. In the above example, you could still apply policies to all production accounts but you would have to attach them individually. However it would be easy to apply a policy to a a complete product.

One final thought is to make sure you make your accounts sufficiently granular. This will help apply policies, separate control a billing as well as creating a logical separation.

What do RCP do

Currently RCP are only support a few resource types:

• S3
• KMS
• STS
• SQS
• Secrets Manager

I suspect more services will be added and would expect this list to resemble the services that support resource based policies over time. This is only my expectation though and based on no official announcements.

Services that support resource based policies are listed here in the AWS docs:

So what can you do with a policy? Here is an example policy (credit AWS RCP announcement blogpost) that restricts access to s3 from principals outside an organisation. This is a good example of something that cant be applied using a SCP:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EnforceOrgIdentities",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": "*",
            "Condition": {
                "StringNotEqualsIfExists": {
                    "aws:PrincipalOrgID": "[MY ORG ID]"
                },
                "BoolIfExists": {
                    "aws:PrincipalIsAWSService": "false"
                }
            }
        }
    ]
}        

Here are the relevant fields explained:

• Version – This is a standard part of all IAM policies and just defines the syntax
• Statement – Each statement defines a single permission
• Sid – An optional identifier for the statement
• Effect – IAM allows "Allow" or "Deny" policies but as RCP are guardrails only "Deny" is used.
• Principal – This is required for RCP but must be set to "*" as it applies to all principals. It can be scoped by either the action or conditions.
• Action – Which AWS services and actions are effected by the statement
• Resource – Specifies the resources that the RCP applies to. It can be applied to all resources or specific resources. For a RCP this will often be "*"
• Condition – Conditions that determine if the statement should be applied to a request.

This policy has 2 conditions. The first checks the organisational id of the principle that is requesting to access a resource. The second checks it is not an AWS service. Conditions are ANDed together so this statement will only apply if there is an principal organisation id for another organisation and the principal is not an AWS service.

A handful of caveats

There are a few things I have found that are worth considering if you use this feature.

• This feature is available in all AWS commercial regions but you have to specifically enable it in your organisation.
• In many cases policies could be applied using SCP or RCP. Due to teh wider support, I would recommend sticking with SCP where possible.
• It appears that as long as the policy is syntactically valid it is possible to reference services that are not supported. Then the policy will have no effect.
• RCP do not apply to the master account. This is stated above and several times in teh official documents, but this does feel like it may surprise people.

Conclusion

RCP are a new type of guard rail that could not be applied previously. If you need to control access to resources with cross account access or public access then these are a great addition. They work just like resource policies but for your whole organisation.