CloudFront Origin Access Control (OAC)

CloudFront Origin Access Control (OAC) is a feature that allows you to restrict access to an S3 bucket origin so that only your CloudFront distribution can serve content from that bucket. It uses AWS Signature Version 4 (SigV4) to sign requests from CloudFront to the origin, providing a more secure and flexible alternative to the legacy Origin Access Identity (OAI). OAC supports encrypted origins (S3 SSE-KMS), which OAI does not, and eliminates the need for a static user (the OAI) by dynamically signing each request.

OAI worked by creating a special CloudFront user (the origin access identity) and granting that user access to the S3 bucket via a bucket policy. However, OAI had several limitations:

OAC addresses these issues by using SigV4 to sign each request with a unique signature that includes a timestamp and a hash of the request. The S3 bucket policy then verifies that the request is signed and originates from the CloudFront distribution.

1. User Request: A user requests content from CloudFront (e.g., https://d123.cloudfront.net/image.jpg). 2. Cache Check: CloudFront checks its edge cache. If the object is cached and fresh, it serves it directly. If not, it proceeds to the origin. 3. Origin Request Signing: CloudFront constructs an HTTP GET request to the S3 origin (e.g., https://my-bucket.s3.amazonaws.com/image.jpg). It then signs this request using AWS Signature Version 4. The signing process involves: - Canonical Request: Build a canonical request using HTTP method, URI, query string, headers (including host and x-amz-content-sha256), and payload hash. - String to Sign: Combine algorithm, request date, credential scope, and hashed canonical request. - Signature: Compute the signature using the distribution's private key (associated with the OAC configuration) and the string to sign. 4. Signed Request to S3: CloudFront sends the signed GET request to S3. The request includes the Authorization header with the signature, as well as x-amz-date and x-amz-content-sha256 headers. 5. S3 Verification: S3 receives the request and verifies the signature using the public key of the CloudFront distribution. It also checks that the aws:SourceArn condition in the bucket policy matches the CloudFront distribution ARN. If both checks pass, S3 returns the object. If not, S3 returns a 403 Forbidden. 6. Response: CloudFront receives the object, caches it at the edge, and serves it to the user.

- OAC Configuration: Created in CloudFront console or via API. You specify the S3 bucket origin and optionally enable signing behavior (e.g., for all requests or only for specific behaviors). - Bucket Policy: Must include a statement that allows s3:GetObject (and optionally s3:PutObject for PUT requests) with conditions: - aws:SourceArn: Must equal the CloudFront distribution ARN (e.g., arn:aws:cloudfront::123456789012:distribution/E1234567890ABC). - aws:SourceAccount: Must equal the AWS account ID of the distribution owner. - Signature Version 4: The signing algorithm. Default headers signed: host, x-amz-content-sha256, x-amz-date. The signature includes a timestamp that is checked against the current time (with a default skew of 15 minutes). - OAC vs OAI: OAC is the recommended option for new distributions. OAI is still supported but deprecated for new use cases.

To configure OAC for an S3 origin:

1. Create an OAC: In the CloudFront console, under "Origin Access", select "Origin access control settings" and create a new control setting. You can also use the AWS CLI:

aws cloudfront create-origin-access-control \
     --origin-access-control-config OriginAccessControlConfig.json

where OriginAccessControlConfig.json contains:

{
     "Name": "MyOAC",
     "Description": "OAC for my distribution",
     "SigningProtocol": "sigv4",
     "SigningBehavior": "always",
     "OriginAccessControlOriginType": "s3"
   }

2. Associate OAC with Origin: During distribution creation or update, under "Origin settings", choose "Origin access control" and select the OAC. 3. Update S3 Bucket Policy: Add a bucket policy like:

{
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": "*",
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::my-bucket/*",
         "Condition": {
           "StringEquals": {
             "aws:SourceArn": "arn:aws:cloudfront::123456789012:distribution/E1234567890ABC"
           }
         }
       }
     ]
   }

A large media company uses CloudFront to stream video content stored in an S3 bucket encrypted with SSE-KMS. They previously used OAI but needed to upgrade to OAC to support KMS encryption. The bucket policy was updated to include the aws:SourceArn condition pointing to the CloudFront distribution ARN. The KMS key policy was also updated to allow cloudfront.amazonaws.com to decrypt. They set SigningBehavior to always to ensure all origin requests are signed. Performance was negligible; the signing overhead was less than 1 ms per request. They observed that cache hit rates remained above 90%. One misconfiguration occurred when the KMS key policy was accidentally removed during a rotation, causing 502 errors for all requests. The fix was to re-add the CloudFront service principal with the correct condition.

An e-commerce platform uses multiple S3 buckets for different content types (images, CSS, JavaScript) behind a single CloudFront distribution. Each bucket is a separate origin. They created a single OAC and associated it with all origins. The bucket policies for each bucket were identical except for the bucket ARN in the resource. They set SigningBehavior to no-override so that individual behaviors could override signing if needed (e.g., for public content). However, they later realized that no-override still signs by default unless a behavior explicitly sets SigningBehavior to never. This was fine for their use case. A common mistake was forgetting to update the bucket policy for a new bucket, causing intermittent 403 errors. They automated policy updates using AWS CloudFormation.

A SaaS company uses Lambda@Edge to modify origin requests (e.g., add authentication headers). They use OAC to secure the S3 origin. The Lambda function runs before the request is signed; CloudFront signs the request after the function executes. This allowed them to use OAC without modifying the Lambda code. They encountered an issue where the Lambda function changed the URI, causing the signed request to mismatch the actual request (since the signature was computed on the original URI). They fixed this by ensuring the Lambda function did not modify the URI path. They also used CloudFront logs to debug signature mismatch errors.