Amazon CloudFront introduces Origin Access Control (OAC)

Amazon CloudFront is a global content delivery network that securely delivers applications, websites, videos, and APIs to viewers across the globe in milliseconds. Using CloudFront, customers can access different types of origin services to suit their use cases. One of the performant architectures customers adopt is to use Amazon S3 as the origin to host content like websites and videos, and use CloudFront to deliver them to viewers. Today, when using this architecture, customers can leverage CloudFront’s origin access identity (OAI) to secures S3 origin access to CloudFront only.

Origin Access Control (OAC)

While OAI provides a secure way to access S3 origins to CloudFront, it has limitations such as not supporting granular policy configurations, HTTP and HTTPS requests that use the POST method in AWS regions that require AWS Signature Version 4 (SigV4), or integrating with SSE-KMS. To strengthen security and deepen feature integrations, today, we are introducing origin access control (OAC), a new feature that secures S3 origins by permitting access to the designated distributions only. OAC is based on an AWS best practice of using IAM service principals to authenticate with S3 origins. Compared with OAI, some of the notable enhancements OAC provide include:

• Security – OAC is implemented with enhanced security practices like short term credentials, frequent credential rotations, and resource-based policies. They strengthen your distributions’ security posture and provides better protections against attacks like confused deputy.
• Comprehensive HTTP methods support – OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
• SSE-KMS – OAC supports downloading and uploading S3 objects encrypted with SSE-KMS.
• Access S3 in all AWS regions – OAC supports accessing S3 in all AWS regions, including existing regions and all future regions. In contrast, OAI will only be supported in existing AWS regions and regions launched before December 2022.

When using OAC, a typical request and response workflow will be: 1. A client sends HTTP or HTTPS requests to CloudFront. 2. CloudFront edge locations receive the requests. If the requested object is not already cached, CloudFront signs the requests using OAC signing protocol (SigV4 is currently supported.) 3. S3 origins authenticate, authorize, or deny the requests. When configuring OAC, you can choose among three signing behaviors – “Do not sign requests”, “Sign requests”, and sign requests but “Do not override authorization header” (Figure 1). Next we will talk about OAC’s expected behaviors for each signing option.

Figure 1. OAC signing options

“Sign requests” option

When you configured “Sign requests” option, IAM CloudFront service principal will sign each request with SigV4. The signature will then be included, along with additional data, to form an Authorization header which will be sent to your S3 origin. When your S3 origin receives this request, it will perform the same steps to calculate the signature and compare its calculated signature to the one CloudFront sent with the request. If the signatures match, the request is processed. If the signatures don’t match, the request is denied.

With “Sign requests” option, CloudFront will always sign requests received from the clients, even when an incoming request already has an Authorization header signed by your client applications. In which cases, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate a new Authorization header to send to S3 origin.

We recommend most customers use “Sign requests” option as it ensures your applications will always work because CloudFront will always sign the incoming request. Additionally, by having CloudFront to sign your requests, your applications’ performance is improved as less data is transferred between client and CloudFront.

“Do not override authorization header” option

If your client applications can sign requests, and your use cases involve toggling between client-signed and CloudFront-signed Authorization headers based on attributes like different cache behaviors, file directories, HTTP methods, edge computer invocations, you can use “Do not override authorization header” sub-option after selecting “Sign request.” For example, if you want to limit the S3 upload authorization to your client applications but assigning S3 download authorization to CloudFront, you can enable this option. Note that in this example, you must configure your S3 bucket policy accordingly so only your client’s Authorization will be accepted to perform uploading.

In addition, because CloudFront requires headers to be explicitly allow-listed to be forwarded to origin, you must allowlist Authorization header in your cache policy so that client Authorization header can be forwarded to your origin. If “Do not override authorization header” sub-option is enabled but client’s Authorization header isn’t allow listed, CloudFront will drop client’s Authorization header, re-sign the request with CloudFront’s credential, and generate an Authorization header to send to S3 origin.

“Do not sign requests” option

“Do not sign requests” instructs CloudFront to not sign any requests received from S3 origins. You can choose this option if your client applications will always sign the requests, or if your S3 bucket is public (Not a best practice). Note “Do not sign requests” option is equivalent with not using origin access control. This option is useful if you want to change an OAC’s signing options for a large number of CloudFront distributions. For example, if you previously configured an OAC with “Sign requests”, and it’s associated with 100 origins. If you now want clients to sign the requests, instead of changing the OAC associations for 100 origins manually, you can just change this very OAC’s configuration to “Do not sign requests”. CloudFront will then stop signing requests for the 100 origins.

Now we know OAC’s signing behaviors for each option, let’s take a look at how you can configure OAC. We will also look at how you can configure KMS policy to work with OAC.

Configure OAC when creating a new CloudFront distribution

1. Sign in to the AWS Management Console and open the CloudFront console at https://console.thinkwithwp.com/cloudfront/v3/home
2. Choose Create Distribution.
3. In the Origin configuration section, select an S3 origin from the Origin domain drop-down list.
4. You can optionally configure an origin path to append to the origin domain name for origin requests.
5. Enter a name to uniquely identify the current origin configuration.
6. Choose Origin access control settings (Figure 2)

   Figure 2. Configure origin access when creating a distribution

7. You can choose an existing origin access control or create a new control setting with one of three signing options (Figure 1)
8. Follow the detailed instructions here on how to configure the rest of the settings
9. Select Create distribution at the bottom of the page once all the configuration settings have been chosen
10. Once the distribution is successfully created, you must update the S3 bucket policy, you can reference the policy statement provided on distribution detail page (Figure 3)
11. Note that the policy provided only includes permissions to read objects from S3. If you would like to also upload objects to S3, you must update the policy with additional permissions for “s3:PutObject”

    
    Figure 3. Distribution detail page

    Configure OAC when updating an existing CloudFront distribution

    1. Sign in to the AWS Management Console and open the CloudFront console at https://console.thinkwithwp.com/cloudfront/v3/home
    2. Select one of the distributions from the list
    3. Select the Origins tab and choose the S3 origin which you want to associate with an origin access control setting
    4. If the origin is not using any access mechanism, it will show as public. If the origin is already using OAI, it will show as “Legacy access identifies”. To use OAC, select “Origin access control settings” and choose an existing origin access control or create a new control setting with one of three signing options (Figure 1)

       Figure 4. Update an existing distribution

    5. You must update the S3 policy to allow CloudFront IAM service principal and your distribution resource to access the S3 bucket. Unlike configuring origin access when creating distribution where you can update the policy only after the distribution is created, when updating a distribution, you can, and we indeed recommend, that you update the policy to allow access to both OAI and OAC, prior to saving the origin configuration, to reduce the service downtime to zero. The following is a sample policy that allows access to both OAI and OAC.

       {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowCloudFrontServicePrincipalReadOnly",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID"
                }
            }
        },
        {
            "Sid": "AllowLegacyOAIReadOnly",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EH1HDMB1FH2TC"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
        }
    ]
}

    6. Similar to configure OAC when creating a distribution, the policy CloudFront provided only includes permissions to read objects from S3. If you would like to also upload objects to S3, you must update the policy with additional permissions for “s3:PutObject”
    7. At the bottom of the page, choose Save

    Enable SSE-KMS for CloudFront OAC

    AWS Well-Architected recommends protecting your data in transit and at rest. If you are using OAI, your data is already protected in transit, and you can already protect your data at rest using Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3). On the other hand, if your organizations require that SSE-KMS encryption be used to encrypt content stored in their S3 buckets, you can now use OAC to access SSE-KMS encrypted S3 objects. Note you need to configure your KMS policy to allow CloudFront IAM service principal to access your KMS keys. Adding aws:SourceArn condition key allows only a specific CloudFront distribution to access SSE-KMS encrypted objects using this key policy. You can follow the configuration steps below

    1. Open the KMS console at https://us-east-1.console.thinkwithwp.com/kms/home?region=us-east-1#/kms/keys
    2. Select the customer managed KMS key that is used to encrypt the content in the S3 origin
    3. Select the Key policy tab
    4. Update the KMS key policy to give access to CloudFront Service Principle

       {
    "Sid": "Allow use of the key",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cloudfront.amazonaws.com"
        ]
     },
      "Action": [
          "kms:Decrypt",
          "kms:Encrypt",
          "kms:GenerateDataKey*
       ],
       "Resource": "*",
       "Condition":{
           "StringEquals":{
                “aws:SourceArn”: “arn:aws:cloudfront::ACCOUNT_ID:distribution/DISTRIBUTION_ID”
           }
       }
}

    Do I need to migrate to OAC?

    If you already have CloudFront distributions configured with OAI, you may wonder if you need to migrate from OAI to OAC. Even though we recommend using OAC for its latest security best practices and additional functionalities, CloudFront supports both the new OAC and legacy OAI. If you have a distribution configured to use OAI, you can easily migrate the distribution to OAC with few simple clicks. Any distributions using OAI will continue to work and you can continue to use OAI for new distributions. Refer to CloudFront origin access migration documentation for upcoming region restrictions.

    Now available

    CloudFront Origin Access Control is now available worldwide except for AWS China regions. You can start using OAC through the CloudFront console, APIs, SDK, or CLI. There is no additional fee to use OAC. To learn about how to configure OAC, refer to the CloudFront origin access control documentation. To get started with CloudFront, visit the CloudFront product page.

About the Authors