Skip to content

Latest commit

 

History

History

CloudFront

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
cfn
cfn
 
 
README.md
README.md
 
 
get_canonical_user_id.sh
get_canonical_user_id.sh
 
 
install-cloudfront-hosting-toolkit.sh
install-cloudfront-hosting-toolkit.sh
 
 

README.md

CloudFront

Jump to

Useful Libs and Tools

Protection and Security

OAC vs. OAI

Origin Access Control (OAC) and Origin Access Identity (OAI) (Source)

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.

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:

  1. 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.
  2. Comprehensive HTTP methods support – OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
  3. SSE-KMS – OAC supports downloading and uploading S3 objects encrypted with SSE-KMS.
  4. 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”. For details, see (Source).

S3 Website endpoint vs. S3 REST API endpoint

  1. If you use an S3 bucket as the origin, CloudFront uses the REST API interface of S3 to communicate with the origin.

    1. E.g. bucket-name.s3.Region.amazon.com
    2. S3 REST API is more versatile, allowing the client to pass richer information like AWS Identity, thereby allowing the exchange of information that makes OAC (or OAI) possible.

  2. If you use the website endpoint as the origin, CloudFront uses the website URL as the origin.

    1. E.g. http://bucket-name.s3-website.Region.amazonaws.com/object-name
    2. OAI cannot be used when CloudFront is using the website endpoint where only GET and HEAD requests are allowed on objects.
    3. OAI cannot be used. Instead, we have to use an origin custom header that only CloudFront can inject into the Origin-bound HTTP request.
    4. The bucket policy of the S3 bucket hosting the static website can then check for the existence of said header. The assumption here is that if any browser ever directly uses the website URL of the S3 hosted static website, their request will not contain this header, and hence will be rejected by the bucket policy.
    5. Also, S3 hosted static websites do not support HTTPS.
      1. We can only set Viewer Protocol Policy. Only the browser to CloudFront half will be HTTPS. The CloudFront to Origin half cannot be HTTPS in this case.
      2. Therefore, Origin Protocol Policy, in this case, cannot be set to HTTPS Only.

  3. See also https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html#WebsiteRestEndpointDiff.

Secure Lambda function URLs using CloudFront OAC

See also

How to limit the access to your REST Regional API Gateway endpoint exclusively to CloudFront

See also

To take advantage of the perimeter protection layer built with CloudFront, AWS WAF, and Shield, and to help avoid exposing API Gateway endpoints directly, you can use the following approaches to restrict API access through CloudFront only.

  1. CloudFront can insert the X-API-Key header before it forwards the request to API Gateway, and API Gateway validates the API key when receiving the requests. For more information, see Protecting your API using Amazon API Gateway and AWS WAF — Part 2.
    • Support REST API endpoints only
  2. CloudFront can insert a custom header (not X-API-Key) with a known secret that is shared with API Gateway. An AWS Lambda custom request authorizer that is configured in API Gateway validates the secret. For more information, see Restricting access on HTTP API Gateway Endpoint with Lambda Authorizer.
    • has an additional cost due to the use of the Lambda authorizer.
  3. CloudFront can sign the request with AWS Signature Version 4 by using Lambda@Edge before it sends the request to API Gateway. Configured AWS Identity and Access Management (IAM) authorization in API Gateway validates the signature and verifies the identity of the requester.
    • an additional Lambda@Edge cost in this approach
    • support all REST, HTTP, and WebSocket endpoints

Performance and HA

Other

CloudFront Functions and Lambda@Edge

CloudFront Functions

Lambda@Edge

Steps to provision CloudFront

If using custom domain/CNAME, do also (1), (2) and (4); if not, only (3).

  1. Upload a server (ssl) certificate to IAM using aws-cli:

    aws iam upload-server-certificate \
    --server-certificate-name example \
    --certificate-body file://example.crt \
    --private-key file://example.key \
    --certificate-chain file://intermediate.crt \
    --path /cloudfront/

  2. To retrieve the ServerCertificateId or other certificate details:

    aws iam list-server-certificates (--profile your-aws-profile)

  3. Use CloudFormation template CloudFront-S3-WebDistribution-xxx.template to

    1. Create S3 bucket with Static Website, Versioning and Logging enabled.
    2. Create Bucket Policy for PublicRead access (if using Custom Origins approach).
    3. Create a Managed Policy for managing and uploading files to the S3 bucket.
    4. Attach the Managed Policy to the given Group.
    5. Create a CloudFront Distribution

  4. Add new Route53 record set for each CloudFront Alias as CNAME pointing to the CloudFront Domain name.