Amazon Cloudfront Origin Access Control (OAC): All you Need to Know

In this article, you will learn:

• What is Amazon CloudFront origin access control (OAC)?
• New features of OAC
• Can you use the S3 bucket static website endpoint and OAC?
• Do I need to migrate to OAC?
• OAC set up for CloudFront distributions and S3 bucket

Amazon CloudFront is a global content delivery network (CDN) from Amazon Web Services (AWS) that securely delivers applications, websites, videos, and APIs to viewers across the globe in milliseconds.

One of the most used AWS architectures is Amazon S3 which is used as the origin to host content (images, videos, other objects), and CloudFront, which is used to deliver them to viewers. When using this architecture, customers can leverage CloudFront’s origin access identity (OAI) to secure S3 bucket access to CloudFront only.

AWS introduced a new function that replaces OAI, and it has a very similar name: CloudFront origin access control (OAC) and it brings some new features, so let’s look at what CloudFront OAC is, how it works, new features, how to migrate from OAI and how to set it up in AWS Management Console.

You can also watch our video about CloudFront OAC:

What is origin access control (OAC)

OAC is a simple function that can be found in CloudFront distribution settings.

With OAC you can:

• Restricts access to the Amazon S3 bucket so that it's not publicly accessible.
• Make sure that users can access the content in the S3 bucket only through the specified CloudFront distribution.
• Reduce the overall costs of Data transfer out, because serving data directly from S3 costs more than serving them through CloudFront distribution.

OAC prevents users from viewing your S3 files by simply using the direct URL, for example:

• app-private-bucket-stormit.s3.eu-central-1.amazonaws.com/pics/logo.png

Your users can only use the URL of your CloudFront distribution (or your domain name if you set it). For example:

• d2whx7jax6hbi5.cloudfront.net/pics/logo.png

Save up to 60% on your CloudFront costs with StormIT optimized pricing.

Estimate savings

New features of OAC

OAC is based on the AWS best practice of using IAM service principals to authenticate with S3 origins. Compared with OAI, some of the notable enhancements OAC include:

• OAC is implemented with enhanced security practices like short-term credentials, frequent credential rotations, and resource-based policies. It provides better protection against attacks like a confused deputy.
• OAC supports HTTP requests: GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
• Server-side encryption with AWS Key Management Service – SSE-KMS – and OAC supports downloading and uploading encrypted S3 objects.

Signing requests

When configuring OAC, you can choose among three signing behaviors – “Do not sign requests”, “Sign requests” and “Do not override authorization header”.

It’s recommended most customers use the “Sign requests” option as it ensures your applications will always work because CloudFront will always sign the incoming request.

Do not sign the request (not recommended)

You can choose this option if your client application always signs requests or if your S3 bucket is public. Note that the Do Not Sign Requests option is equivalent to not using origin access control. This option is useful when you want to change the OAC's signing options for a large number of CloudFront distributions.

Sign requests (recommended)

If you configure the Sign requests option, the IAM CloudFront service principal signs each request using SigV4. The signature is then inserted along with other data to form the authorization header sent to your S3 origin. When your S3 origin receives this request, it takes steps to calculate the signature and compare it to the signature that CloudFront sends with the request.

“Do not override authorization header” option

If your client application can sign requests, and your use case involves switching between client-signed and CloudFront-signed Authorization headers based on attributes such as different caching behavior, file directories, HTTP methods, edge machine calls, etc.

SSE-KMS support

If you are using legacy OAI, your data is already protected in transit, and you can protect your data at rest using Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3).

If your organisation's policy requires that SSE-KMS encryption be used, you can use OAC to access SSE-KMS encrypted S3 objects.

You just need to configure your KMS policy to allow the CloudFront IAM principal to access your KMS keys with the simple

1. Go to the KMS console (select your region). 2. Select your customer-managed KMS key.

3. Select the “Key policy” tab and click “Switch to policy view”.

4. Edit the policy and add access to the CloudFront service principal.

a. Replace ACCOUNT_ID with the AWS account ID that contains the CloudFront distribution, S3 bucket, and the KMS key.
b. Replace DISTRIBUTION_ID with the ID of the CloudFront distribution.

{
        "Sid":"AllowCloudFrontServicePrincipalSSE-KMS",
        "Effect":"Allow",
        "Principal":{
            "AWS":"arn:aws:iam:: ACCOUNT_ID:root",
            "Service":"cloudfront.amazonaws.com"
        },
        "Action":[
            "kms:Decrypt",
            "kms:Encrypt",
            "kms:GenerateDataKey*"
        ],
        "Resource":"*",
        "Condition":{
                "StringEquals": {
                    "AWS:SourceArn":"arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
                }
            }
}

Can you use the S3 bucket static website endpoint and OAC?

It stays the same as for the OAI (origin access identity): you cannot use origin access control (OAC) with the S3 bucket website endpoint.

These two functions do not work together because you are only able to set the OAC for the S3 bucket directly, for example, you choose this origin domain in CloudFront distribution:

test-bucket-website-stormit-2022.s3.eu-central-1.amazonaws.com

And if you use an S3 website endpoint, you are not able to enable OAC, for example like this:

test-bucket-website-stormit-2022.s3-website.eu-central-1.amazonaws.com

One of the main reasons to use the S3 static website hosting function is that you can useredirection rules. This will not work if you use the OAC function in CloudFront.

But there is a way to set permissions when using CloudFront and the S3 website endpoint through [restricting access to files on CloudFront custom origins or serving private content with signed URLs and signed cookies.

Do I need to migrate to OAC?

At this point, there are a lot of customers that are using OAI in their environment. It’s recommended you use OAC for its latest security and some additional functionalities, but CloudFront at this moment supports both the OAC and OAI.

OAI will only be supported in existing AWS regions and regions launched before December 2022.

So there is no hurry to migrate from OAI to OAC. But if you have a distribution configured to use OAI, you can easily migrate the distribution to OAC with a few simple clicks. It’s best to leave the OAI bucket policy until your CloudFront distribution will be deployed after updating.

OAC set up for CloudFront distributions

Configure OAC when creating a CloudFront distribution

1. Log in to the CloudFront Console.

2. Click on “Create Distribution”.

3. Select your S3 bucket as the origin domain.

4. Choose “Origin access control settings” and click on “Create control setting”.

5. You can leave a name as default. In a majority of cases, you can leave “Signing behavior” as “Sign requests”, but you can read more about this option in the previous part of this article. Click on “Create”.

6. It’s also good to select “Redirect HTTP to HTTPS” or “HTTPS only” for this type of distribution.

7. We can leave everything else on default and click on “Create distribution”.

8. You should see a blue panel in the upper part of your browser window.

a. Click on “Copy policy” and click on “Go to S3 bucket permissions to update policy”.

b. If you unintentionally close this panel, you’ll find this new S3 bucket policy in the settings of your new CloudFront distribution, under “Origins”, then click on “Edit”.

c. And here it is under Bucket policy.

9. Go to S3 bucket permissions and click “Edit” next to Bucket policy.

10. Copy the policy inside and click on “Save changes”. You can delete a policy for anonymous access if you have it here.

Here is my policy as an example:

{
    "Version":"2008-10-17",
    "Id":"PolicyForCloudFrontPrivateContent",
    "Statement":[
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect":"Allow",
            "Principal":{
                "Service":"cloudfront.amazonaws.com"
            },
            "Action":"s3:GetObject",
            "Resource":"arn:aws:s3:::test-bucket-main-2022/*",
            "Condition":{
                "StringEquals":{
                  "AWS:SourceArn":"arn:aws:cloudfront::913877976938:distribution/E28H6NNXS8GTVO"
                }
            }
        }
    ]
}

11. You should also block public access to the S3 bucket.

OAI migrating and configuring OAC for existing CloudFront distributions and S3 bucket

This manual can also be used for users that need to migrate from OAI to OAC, but we recommend leaving the OAI S3 bucket policy until your CloudFront distribution is updated and deployed successfully, then you can delete the OAI bucket policy in your S3 bucket.

1. Log in to the CloudFront Console.

2. If you already have an OAC, you can use it. If you don’t you can create it by clicking on “Origin access” in the left panel.

3. Next click on “Create control setting”.

4. Fill in the name. In a majority of cases, you can leave “Signing behavior” as “Sign requests”, but you can read more about this option in the previous part of this article. Click on “Create”.

5. Go to your CloudFront distributions and select the one that has an S3 origin and that you want to enable OAC for it.

6. Choose the “Origins” tab. Select the Amazon S3 origin, and then choose “Edit”.

7. Choose “Origin access control settings” and for the Origin access control select the previously created OAC – NewOAC. Click on Copy policy and go to S3 bucket permissions.

8. In S3 bucket permissions, click “Edit” next to Bucket policy.

9. Copy the policy inside and click on “Save changes”. You can delete a policy for anonymous access if you have it here.

10. Go back to the CloudFront settings tab in your browser and choose “Save changes”. Note that it can take a while for the change to take effect.

11. Do not forget to block all public access in permissions for your S3 bucket.

Conclusion

CloudFront origin access control is now available globally. This blog post tried to describe what it is for and how it is different from OAI. Now it’s on you if you want to start using it or migrate to this function from OAI. We have looked at how to start using it through the AWS Management console but you can also start using OAC through the API, SDK, or CLI.