Traditional Web Hosting on AWS: Part 3 — Building Robust Security with Amazon CloudFront, AWS WAF & AWS Secrets Manager

Published in

AWS Tip

27 min readAug 22, 2023

Welcome to Part 3 of the comprehensive series on Traditional Web Hosting on AWS.

In this instalment you will enhance the security and optimise the performance of your application infrastructure. Before you proceed, briefly revisit the foundation you have already built in Part 1 and Part 2:

Part 1: Deploy a Highly Available Virtual Private Cloud (VPC)

Ensuring the high availability of critical business systems is paramount in the AWS environment. You have already taken your first step towards resilience by creating a new Virtual Private Cloud (VPC) that spans multiple Availability Zones. You created public and private subnets, configured Internet and NAT Gateways, and set up route tables for efficient traffic routing. This establishes the groundwork for a robust and fault-tolerant infrastructure.

You can find all the details in Part 1 here.

Part 2: Scalable and Highly Available Environment

In the second instalment you focused on scalability and high availability.

You configured an Application Load Balancer to distribute incoming traffic across instances, enhancing system resilience. A launch template streamlined the instance deployment process through an Auto Scaling group, providing you with control and flexibility.

By implementing a secure two-tier architecture and appropriate security group configurations, you ensured robust security. The high availability of your Web Server was thoroughly tested and demonstrated, including its performance under stress conditions.

You can find all the details in Part 2 here.

Now, in Part 3, you focus on security and performance optimisation. The following comprehensive configurations are designed to elevate your application’s security posture and user experience:

HTTPS Configuration with ACM for your Application Load Balancer

Securing the transfer of sensitive data is the foundation of any robust application. While you already have an existing AWS Application Load Balancer (ALB), you will now enhance its security by configuring a HTTPS listener and associating it with a valid SSL/TLS certificate from AWS Certificate Manager (ACM). This establishes a secure channel for communication between your users and your application’s backend. Data integrity and confidentiality are preserved throughout transit.

CloudFront CDN for Caching:

Optimising the delivery of content to your users is important for providing a responsive user experience. Using Amazon CloudFront as a Content Delivery Network (CDN) enhances performance by caching frequently accessed content closer to the user. This reduces the load on your Application Load Balancer, and accelerates content delivery, resulting in lower latency and improved load times.

AWS WAF for Web Application Firewall:

Safeguarding your application from a wide range of web-based attacks is essential to maintaining its integrity. AWS Web Application Firewall (WAF) acts as an intelligent shield against common threats like SQL injection and cross-site scripting. By integrating WAF with CloudFront, you’re adding a proactive layer of security that identifies and blocks malicious traffic before it reaches your application.

Secure Web Communications with Custom SSL:

To reinforce the security of your application’s communication, an Alternate Domain Name (CNAME) is associated with your CloudFront distribution. A Custom SSL certificate encrypts the connection between CloudFront and your users. This layered encryption approach ensures end-to-end security, from the user’s device to your application’s backend.

Force HTTPS for CloudFront:

Ensuring that all user interactions remain encrypted is crucial for maintaining the confidentiality of data. By configuring your CloudFront distribution to exclusively use HTTPS when communicating with your Application Load Balancer, you are enforcing secure communication throughout the user journey, mitigating any potential security vulnerabilities. Viewers are also forced to view your application over HTTPS, and any attempt to access it via HTTP is automatically redirected to the secure HTTPS version.

Prevent Direct Origin Access with Custom Headers and WAF:

Controlling access to your application’s origin resources is important for security. CloudFront can be configured with custom headers, such as the X-Origin-Verify header, which enforces restrictions on viewer requests. Additionally, AWS WAF rules can be set up to validate these headers, preventing unauthorised access to your origin content.

Secrets Manager for Automated Secret Rotation:

Enhancing security through the regular rotation of application secrets is vital to mitigate the risk of unauthorised access. AWS Secrets Manager streamlines this process by automating the rotation of the secret employed for the X-Origin-Verify header. As part of this automated procedure, a Lambda function is configured to orchestrate the rotation. Alongside this rotation, the connected AWS WAF web ACL and CloudFront distribution undergo updates, facilitating a seamless transition that maintains security integrity.

Lambda Layer for Enhanced Functionality:

The Lambda function leverages the requests module to interact with the CloudFront X-Origin-Verify header. To streamline code reusability and optimise deployment, a Lambda Layer is introduced. This layer includes the required module, reducing package size and simplifying management.

Validation and Review:

You will conduct a thorough review of the security configurations you’ve implemented, ensuring the integrity and effectiveness of your application’s security measures. By verifying the secret rotation process, confirming access through CloudFront, assessing AWS WAF’s role in blocking direct origin access, and reviewing critical configurations, you’ll ensure that your application remains well-protected and fully functional.

Objectives:

Secure HTTPS Setup with ACM Certificates for your Application Load Balancer and CloudFront.
Setting Up CloudFront Distribution with Application Load Balancer Origin, HTTPS, CNAME, Custom SSL Certificate, and Custom Headers.
Domain Integration with CloudFront Distribution using the CLI.
Review AWS Web Application Firewall Integration with CloudFront
Configure a WAF ACL, Associated with you Application Load Balancer and Create an X-Origin Verification Rule.
Automate Secret Rotation for X-Origin-Verify Header Value using AWS Secrets Manager.
Configure a Lambda Function for Secret Rotation and Resource Management.
Review Security Configurations.

Task 1: Secure HTTPS Setup with ACM Certificates for your Application Load Balancer and CloudFront

In this task you will enhance the security of your application by configuring a HTTPS Listener for your Application Load Balancer, attaching a SSL/TLS Certificate, and setting up a redirect from HTTP to HTTPS.

a) Request SSL/TLS certificates from ACM

Since ACM is a regional service, certificates are tied to the specific region where they are issued. Therefore, you need to obtain an SSL/TLS certificate from AWS Certificate Manager (ACM) for your Application Load Balancer’s domain and CloudFront Distribution.

Before you begin, open AWS CloudShell to access the command-line environment within your browser. This will provide a convenient platform for executing AWS CLI commands.

Log in to the AWS Management Console.
In the top navigation bar, click the shell icon to open a CloudShell environment. CloudShell will open utilising your console credentials.

Request ACM certificate for the ALB.

To begin, obtain an SSL/TLS certificate from AWS Certificate Manager for your Application Load Balancer’s domain.

The aws acm request-certificate command will initiate the certificate request process for your ALB’s region (eu-west-2). Replace “YOUR_DOMAIN NAME” with your actual domain name. If your ALB is in a different region, input the correction region:

aws acm request-certificate \
  --domain-name YOUR_DOMAIN_NAME \
  --validation-method DNS \
  --region eu-west-2

Make a note of the CertificateArn provided in the response. This identifier will be needed when setting up the HTTPS listener on your Application Load Balancer.

Complete DNS Validation:

After submitting the certificate request, you must perform DNS validation to verify your ownership of the domain.

You cannot programmatically request that ACM automatically create your record in Route 53. You need to perform the actual steps to create the DNS records.

Navigate to the AWS Certificate Manager Console.

Locate and choose the certificate you requested with a status of pending validation.
Under the Domains section, choose Create Records in Route 53.
Ensure the records are selected and choose Create Records

A green banner confirms that you Successfully created DNS records.

Request ACM Certificate for CloudFront

Next, you will request an SSL/TLS certificate for your CloudFront distribution. ACM certificates are region-specific, but CloudFront requires certificates from the us-east-1 region to be distributed globally. This means that you will need to request a separate certificate for CloudFront using this region.

Use the following CLI command, replacing “Your Domain Name” with your actual domain name:

aws acm request-certificate \
  --domain-name YOUR_DOMAIN_NAME \
  --validation-method DNS \
  --region us-east-1

Complete DNS Validation for CloudFront Certificate:

Follow the same DNS validation process as before for the CloudFront ACM certificate:

Navigate to the AWS Certificate Manager Console and choose List certificates.

Change your region to US East (N Virgina).

Your certificate should now be listed with a status of pending validation.

Choose your certificate.
Under Domains, choose Create Records in Route 53.
Ensure the records are selected and choose Create Records.

By completing these steps, you have requested and validated SSL/TLS certificates for both your Application Load Balancer and CloudFront distribution. These certificates will enable secure communication and data encryption for your application’s users.

b) Create an HTTPS Listener with your ACM Certificate on your Application Load Balancer

In your CloudShell environment, execute the following AWS CLI command to create an HTTPS listener for your Application Load Balancer.

Make sure to replace the placeholders with the actual ARNs and values from your AWS environment:

aws elbv2 create-listener \
  --load-balancer-arn arn:aws:elasticloadbalancing:eu-west-2:223791342103:loadbalancer/app/WebServer-LB/2b7861c6b48102a7 \
  --protocol HTTPS \
  --port 443 \
  --certificates CertificateArn=arn:aws:acm:eu-west-2:223791342103:certificate/35f8885d-8a5d-40e8-b2a9-0fc8fa7c58a0 \
  --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:eu-west-2:223791342103:targetgroup/WebServer-App/ef9476658872874a

This command sets up a listener for an Elastic Load Balancer v2 (ELBv2). It specifies the load balancer’s ARN, protocol (HTTPS), and port (443) for secure traffic. Additionally, it requires the ARN of an SSL certificate from AWS Certificate Manager for encryption. Use the CertificateArn that you noted when you requested the ACM certificate for the ALB.

The default action for the listener is configured to forward incoming traffic to a specific target group using its ARN.

With this setup, your ALB is now properly configured with HTTPS listeners associated with the SSL/TLS certificate from ACM.

Configure HTTP-to-HTTPS Redirection

To ensure all traffic is encrypted, you will configure an HTTP listener rule that redirects HTTP requests to HTTPS.

In your CloudShell environment, execute the following AWS CLI command to modify your existing listener on the Elastic Load Balancer:

aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-2:223791342103:listener/app/WebServer-LB/2b7861c6b48102a7/a1666e1212132bfd\
  --default-actions Type=redirect,RedirectConfig="{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}"

This command updates the listener’s default actions to include a redirection action. The action redirects incoming HTTP requests to HTTPS using a 301 status code, which signifies a permanent redirect. By executing this command, you’re configuring the listener to perform an HTTP-to-HTTPS redirection, enhancing both security and SEO optimisation for your application.

Task 2: Setting Up CloudFront Distribution with Application Load Balancer Origin, HTTPS, CNAME, Custom SSL Certificate, and Custom Headers

In the following steps, you will configure Amazon CloudFront as a content delivery network (CDN) to efficiently distribute and cache content from your Application Load Balancer (ALB) origin, enhancing content delivery speed and reducing load on the ALB.

Access CloudFront Console and Create Distribution

Open the CloudFront console and choose Create a CloudFront distribution. Leave settings at their default values if not specified in the steps.

Configure Origin Settings

Set up the origin settings for the distribution:

Origin Domain: Search for and choose your Application Load Balancer under Elastic Load Balancer.
Protocol: Choose HTTPS only.

The Origin Protocol Policy dictates that CloudFront will exclusively use HTTPS to access your origin. This ensures secure connections between CloudFront and the Application Load Balancer.

Add Custom Header:

Enhance security by adding a custom HTTP header to requests sent to your origin. This custom header serves as a protective measure to prevent direct access to your origin content and ensures compliance with AWS Web Application Firewall (WAF) rules before reaching your origin.

Header Name: X-Origin-Verify
Value: random-value-1234567890

Configure Default Cache Behavior

Configure settings for the default cache behavior:

Path Pattern: Keep the Default (*) setting to route all requests to the origin.
Viewer Protocol Policy: Choose Redirect HTTP to HTTPS to facilitate access even when users load the HTTP URL.
Allowed HTTP Methods: Keep the default GET and HEAD settings.
Restrict Viewer Access: Keep the default No setting. This will be a public website.

Configure Cache Key and Origin Requests:

Opt for the recommended default options for both Cache policy and Origin request policy.

Cache Policy: Choose Cache Optimized.
Origin Request Policy: Optionally, choose Create origin request policy.

Create Origin Request Policy:

A custom cache policy is crucial to enable proper HTTPS communication between CloudFront and your Application Load Balancer. This ensures that the correct SSL certificate is used based on the requested domain name.

Name: HTTPS-ALB-Cache-Policy
Headers: Include the following headers.
Add headers: Host.
Choose Create.

After creating this policy, return to the CloudFront page and under Origin request policy — optional, choose the refresh button.

Choose the HTTPS-ALB-Cache-Policy

Configure Web Application Firewall (WAF) settings:

One click security protection with AWS WAF is now available in the new Web Application Firewall (WAF) section. You can secure your web applications with AWS WAF with a single click in the Amazon CloudFront console. CloudFront can create and configure out-of-the-box AWS WAF protection for your application as a first line of defense against common web threats.

Enable Security Protection: Choose this option to activate AWS WAF security protection.

Additional security protections, such as against bots and specific threats, can be configured later in the AWS WAF console.

Configure Distribution Settings

Configure settings in the “Settings” section of the distribution:

Price Class: Keep the default “Use all edge locations” setting.
Alternative Domain Name (CNAME): Specify your unique domain name.
Custom SSL Certificate: Choose the ACM certificate you created in task 1.

Create Distribution

Scroll to the bottom of the page and choose Create distribution. While the distribution is being created, the status will display Deploying at the top. This process might take 5 to 15 minutes for completion.

Upon completion, your CloudFront distribution will be fully configured with the Application Load Balancer as the origin, HTTPS enabled, custom headers added, and enhanced security features integrated.

Task 3: Domain Integration with CloudFront Distribution using the CLI

In this task, you will link your custom domain to a CloudFront Distribution by utilising Route 53’s Alias records. This integration ensures that your domain points to your CloudFront Distribution, enhancing content delivery and user experience.

a) Retrieve Hosted Zone ID

To initiate the integration, start by retrieving your hosted zone ID using the aws route53 list-hosted-zones-by-name CLI command. Replace “YOUR_DNS_NAME” with your actual domain name:

aws route53 list-hosted-zones-by-name \
    --dns-name YOUR_DNS_NAME \
    --query "HostedZones[0].Id" \
    --output text

b) Create Alias Record:

Create an Alias Record using the AWS Route 53 Change Resource Record Sets CLI Command. Replace the hosted zone ID, your domain name, and CloudFront distribution ID with the respective ARNs from your AWS environment:

aws route53 change-resource-record-sets --hosted-zone-id Z03756231E8XL64ZEK4TA \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "denizyilmaz.cloud",
          "Type": "A",
          "AliasTarget": {
            "DNSName": "d2fogucqo3t4it.cloudfront.net",
            "EvaluateTargetHealth": false,
            "HostedZoneId": "Z2FDTNDATAQYW2"
          }
        }
      }
    ]
  }'

These CLI commands replicate the process of linking your custom domain and CloudFront distribution through Route 53’s Alias records, programmatically.

DNS changes can take time to propagate across the internet. It might take anywhere from a few minutes to several hours for the changes to take full effect.

c) Verify Integration

Confirm the successful creation of the Alias Record for your custom domain and CloudFront distribution by using the Curl command. Replace the domain name with your actual domain:

curl -I https://YOUR_DOMAIN_NAME

An HTTP status code of 200 OK upon accessing your domain signifies that your Alias record setup with Amazon Route 53 and CloudFront is functioning as expected.

Should the HTTP status code not return as 200 OK, keep in mind that DNS changes might require some time to spread throughout the internet.

By executing these steps, you have integrated your custom domain with your CloudFront Distribution, ensuring optimised content delivery and enhanced user experience.

Task 4: Review AWS Web Application Firewall Integration with CloudFront

In this task, you will explore the functionality of AWS WAF and its integration with CloudFront. AWS WAF serves as a vital layer of protection for your web applications, safeguarding against common web-based attacks that could potentially disrupt application availability, compromise security, or drain resources.

Navigate to the AWS WAF console.

In the left navigation pane, choose Web ACLs.
Under the Web ACLs section, choose Global (CloudFront) from the dropdown box. This selection focuses on the Web ACL created by CloudFront.
Click on the link for the Web ACL that CloudFront generated. The Overview tab offers insight into the requests that have been inspected by this Web ACL.

Proceed to the Rules tab to inspect the three rules that CloudFront’s security protections automatically establish:

AWS-AWSManagedRulesAmazonIpReputationList — Blocks IP addresses from potential threats based on Amazon internal threat intelligence.
AWS-AWSManagedRulesCommonRuleSet — Protects against the most common vulnerabilities found in web applications as described in the OWASP Top 10.
AWS-AWSManagedRulesKnownBadInputsRuleSet — Protects against malicious actors discovering application vulnerabilities.

AWS WAF has additional rules you can add to your web ACL to protect against other types of web threats depending on your application’s needs.

By reviewing the AWS WAF setup and its integration with CloudFront, you are well-positioned to ensure the security of your web applications against a spectrum of web-based attacks.

Task 5: Configure a WAF ACL, Associate it with your Application Load Balancer and Create an X-Origin Verification Rule.

In this task, you will establish a configuration for an AWS WAF (Web Application Firewall) rule that validates the CloudFront custom header X-Origin-Verify. This process ensures a comprehensive approach to enhancing the security of your application.

Start by navigating to Web ACLs.

Create Web ACL

Under Web ACLs, select the region where your Application Load Balancer is located and choose Create Web ACL.

Configure Web ACL

Fill in the details for the Web ACL configuration:

Name: OriginVerifyACL
Description: Web ACL for X-Origin-Verify Header Validation

Keep the default settings for other configurations.

Associate AWS Resources

Under Associated AWS resources — optional, choose Add AWS resources.

Under Resource type, choose Application Load Balancer.
Choose your Application Load Balancer.
Choose Add.
Choose Next.

In every AWS WAF rule group and every web ACL, rules define how to inspect web requests and what to do when a web request matches the inspection criteria. Each rule requires one top-level statement, which might contain nested statements at any depth, depending on the rule and statement type.

Add Rules and Rule Groups

In the add rules and rule groups configure the following:

Choose Add Rule
Choose Add my own rules and rule groups
Under Rule type, choose Rule Builder
For rule name, enter OriginVerifyHeaderRule
For type, leave the default Regular rule
Under If a request matches, in the dropdown box choose at least one of the statements (OR)

Define Rule Statements:

Configure Statement 1 as follows:

Inspect: Choose Single header
Header Field name: Enter x-origin-verify
Match type: Choose Exactly matches string
String to match, Enter random-value-1234567890

The rule will match requests with the custom header x-origin-verify containing the specific value random-value-1234567890. Note that HTTP header field names are case insensitive.

Configure Statement 2 as follows:

Inspect: Choose Single header
Header Field name: Choose x-origin-verify
Match type: Choose Exactly matches string
String to match, Enter random-value-1234567890

In then, Set the action for both statements as Allow and then at the bottom of the page choose Add Rule.

Configure Default ACL Action

In Default web ACL action for requests that don’t match any rules, choose Block. Proceed to Next.

Set Rule Priority

Proceed to Next for setting the rule priority.

Configure Metrics

Continue to Next for metric configuration.

Review and Create Web ACL

In the Review and create web ACL section:

Choose Create Web ACL.

Choose the OriginVerfiyACL you just configured.

In addition to the visual web ACL representation you just configured in the WAF Rule visual editor, every web ACL also has a JSON format representation you can edit by using the WAF Rule JSON editor. You can download the complete configuration for a web ACL in JSON format, modify it as you need, and then provide it to AWS WAF through the console, API, or command line interface (CLI).

Confirm Configuration

Under the Rules tab, verify that the OriginVerifyHeaderRule has been configured with the Allow action, while the default web ACL action is set to Block. This setup ensures that requests not meeting the rule conditions are blocked.

Confirm Blocking

To confirm that direct website accessibility to the origin Application Load Balancer is blocked, return to the CloudShell environment and execute the following Curl Command, replacing the Application Load Balancers DNS name with your actual value:

curl WebServer-LB-128681772.eu-west-2.elb.amazonaws.com

A returned HTTP status code 403 (Forbidden) indicates successful blocking by AWS WAF based on the specified conditions.

By configuring the WAF ACL and creating the X-Origin Verification Rule, you are taking crucial steps towards safeguarding your application against potential threats and unauthorised access.

Task 6: Automate Secret Rotation for X-Origin-Verify Header Value using AWS Secrets Manager

In this task, you configure AWS Secrets Manager for the automated rotation of the secret associated with the X-Origin-Verify header field value. This automated rotation process invokes an AWS Lambda function, which rotates the secret, updates the connected AWS WAF web ACL, and synchronises changes with the CloudFront distribution.

To establish the secret rotation framework using the console, you will initiate the setup by configuring the secret and the associated rotation. This involves creating an empty Lambda rotation function and configuring the necessary permissions. The completion of the rotation function is essential for the overall process, ensuring successful secret rotation and managing potential retries.

Navigate to the Secrets Manager console and choose Store a new secret.

On the Choose secret type page, select Other type of secret and provide the secret value in either JSON Key/value pairs or plaintext format:

Key: HEADERVALUE

Value: random-value-1234567890

{"HEADERVALUE":"random-value-1234567890"}

Choose an appropriate encryption key, either AWS managed key or a customer-managed key, based on your requirements. There is no cost for using an AWS Managed Key for Secrets Manager.

Choose Next.

On the Configure secret page, do the following:

For Secret name enter, OriginValidationSecret
For Secret description, enter Secrets Manager Secret for Origin Validation
Choose Next

On the Configure Rotation — optional page, do the following:

Turn on Automatic rotation
Under Rotation schedule, choose 1 Day

The rotation window automatically starts at midnight unless you specify a Start time. You can rotate a secret as often as every four hours.

Create an empty Lambda rotation function

Under Rotation function, choose Create function. The Lambda console opens in a new window.

Choose Author from scratch.
For Function name, enter OriginSecretRotateFunction
For Function description, Secrets Manager Rotation Lambda.
For Runtime, choose Python 3.9.
Choose, Create function

Choose the Configuration tab.

Choose Permissions.
In permissions, Scroll down to Resource-based policy statements and choose Add permissions to grant permission for Secrets Manager to invoke the function.
In Policy statement, choose AWS Service.
In Service, choose Secrets Manager.
In Statement ID, enter Grant-permission-for-Secrets-Manager-to-invoke-function.
In Action, choose Lambda:InvokeFunction.

Choose Save.

Switch back to the Secrets Manager console to attach the new rotation function to your secret.

For Lambda rotation function, choose the refresh button. Then in the list of functions, choose your new function.
Choose Next.
In the Review section, scroll to the bottom and choose Store.

This setup lays the foundation for automated secret rotation using AWS Secrets Manager. The integration of AWS Lambda with Secrets Manager ensures the rotation of the secret value associated with the X-Origin-Verify header field.

Task 7: Configure a Lambda Function for Secret Rotation and Resource Management

In this task you will configure the Origin Secret Rotate Function, a critical step in automating the secret rotation process using AWS Secrets Manager. This function is responsible for orchestrating the rotation of the secret used for the X-Origin-Verify header, ensuring enhanced security and seamless transitions.

a) Granting Permissions

The Origin Secret Rotate Function needs permission to access the secret in Secrets Manager, and it needs permission to access CloudFront and AWS WAF to rotate the secrets.

To achieve this, you will edit the execution role of the function and replacing the policy with a specific JSON policy. The policy follows the principle of least privilege, providing access only to required resources.

In your Lambda function. Choose the Configuration tab.

In Permissions under Execution role, choose the link to OriginSecretRotateFunction-role.
A new browser page opens and you are redirected to the IAM console.
Under Permission policies, locate and expand the AWSLambdaBasicExecutionRole.
Choose Edit to modify the policy.

Once you’re in the policy editing interface, follow these steps:

Delete the existing policy content.
Copy and paste the provided JSON policy into the policy editor. Make sure to replace the placeholder ARNs with the actual ARNs and values specific to your AWS environment.

Here’s the JSON policy template you’ll be using:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents",
                "logs:DescribeLogStreams"
            ],
            "Resource": "arn:aws:logs:eu-west-2:223791342103:log-group:/aws/lambda/OriginSecretRotateFunction:*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:UpdateSecretVersionStage"
            ],
            "Resource": "arn:aws:secretsmanager:eu-west-2:223791342103:secret:OriginValidationSecret-rOhUDy",
            "Effect": "Allow"
        },
        {
            "Action": [
                "secretsmanager:GetRandomPassword"
            ],
            "Resource": "*",
            "Effect": "Allow"
        },
        {
            "Action": [
                "cloudfront:GetDistribution",
                "cloudfront:GetDistributionConfig",
                "cloudfront:ListDistributions",
                "cloudfront:UpdateDistribution"
            ],
            "Resource": "arn:aws:cloudfront::223791342103:distribution/EATVFQ5QPS89",
            "Effect": "Allow"
        },
        {
            "Action": [
                "wafv2:*"
            ],
            "Resource": "arn:aws:wafv2:eu-west-2:223791342103:regional/webacl/OriginVerifyACL/37c26a4d-87da-4d33-8d8f-ff5d672d6f02",
            "Effect": "Allow"
        }
    ]
}

The permissions granted to the Origin Secret Rotate Function adhere to the principle of least privilege, offering specificity to individual resources.

Once you’ve inserted the correct ARNs, choose Next.

In the review section, choose Save changes.

This completes the step of granting the necessary permissions to the Lambda function, ensuring it can access the required resources securely and effectively.

b) Function Code and Script

In this step, you will upload the provided Python script for the Lambda rotation function.

Return to the Lambda Function.

In Code source, choose Upload from.
Choose Amazon S3 location.
Copy and paste the following S3 link URL for the function code’s ZIP package:

https://denizyilmaz-ce3.s3.eu-west-2.amazonaws.com/OriginSecretsManagerRotation.zip

Choose Save.

The provided Python script automates the rotation of AWS Secrets Manager secrets and manages related resources such as CloudFront distributions and WAF WebACLs. It consists of steps to create, set, test, and finalize secrets during rotation. The script is designed for AWS Lambda and follows the event-triggered rotation process. It interacts with AWS services like Secrets Manager, CloudFront, and WAF to ensure secure secret rotation and resource functionality.

c) Increasing Lambda Timeout:

Since updating the WAF WebACL is a resource-intensive task that requires more time than the default Lambda timeout of 3 seconds, you will need to extend the timeout. This adjustment ensures that the Lambda function has ample time to complete the complex WAF WebACL update process.

Navigate to your Lambda Function’s Configuration tab.

Under the General configuration section, choose Edit.
In the timeout field, enter 5 minutes.
Once you’ve updated the timeout, choose Save.

By increasing the timeout to 5 minutes, you allow the Lambda function the necessary time to finish the demanding WAF WebACL update. This adjustment prevents premature timeouts and ensures the successful execution of the entire rotation process.

d) Installing the Requests Module

To ensure the effective rotation of the CloudFront X-Origin-Verify header, it’s crucial to test the origin URL using the requests module. This Python library simplifies sending HTTP requests and performing tests on CloudFront distributions and other web services.

Within the provided Python script, the requests module is utilised to interact with CloudFront distributions and test the accessibility of the origin URL. This is a fundamental step in ensuring the seamless and secure rotation of the CloudFront X-Origin-Verify header. By doing so, you ensure that the new header value functions correctly, and the origin server continues to respond properly. This minimises the risk of service disruptions and enhances the overall user experience.

The requests module is not included by default in AWS Lambda's toolbox. To include it in your Lambda function, you will need to create a Lambda Layer specifically for the requests module. This approach improves code reusability and reduces the size of the deployment package for your function.

In the left navigation pane, choose Layers.

Choose Create Layer.
For the name enter, Python-Requests.
For description enter, Python requests module and deps.
Choose Upload file from S3 and paste the S3 link URL:

https://denizyilmaz-ce3.s3.eu-west-2.amazonaws.com/python.zip

Under Compatible runtimes — optional, choose Python 3.9.

Choose Create.

To make use of the requests module in your Lambda function without adding it to the deployment package, you need to associate the newly created layer with the function.Go to your Lambda function in the AWS Lambda console.

Scroll down to the Layers section.
Choose Add a layer.
Choose Custom layers and Choose the Python-Requests layer you created.
Choose Version 1 of the layer.
Choose Add.

By setting up the requests module and creating a Lambda Layer for it, you ensure that your Lambda function can interact with HTTP endpoints efficiently, enhancing the capabilities of your function in managing CloudFront distributions and verifying the rotation of the CloudFront X-Origin-Verify header.

e) Configuring Environment Variables:

You will set up environment variables to provide configuration details required for the rotation process.

These variables include AWS region, CloudFront distribution ID, header name for origin verification, origin server URL, WAF ACL ID, name, and rule priority.

Configuring these as environment variables enables flexibility and operational efficiency.

To configure environment variables, navigate to the Configuration tab of your Lambda function.

Choose Environment variables.
Choose Edit.

Add the following environment variables, each with its corresponding value:

AWSREGION: This is AWS region where your resources are deployed. For example, eu-west-2 for the Europe (London) region.

CFDISTROID: This is the ID of your CloudFront distribution.

HEADERNAME: This is the name of the custom header that you want to use for origin verification. It is X-Origin-Verify.

ORIGINURL: This is the URL of your origin server that CloudFront will forward requests to. It should be the URL of the server that hosts your content.

WAFACLID: This is the ID of the Web Application Firewall (WAF) Access Control List (ACL) that you want to update.

WAFACLNAME: This is the name of the WAF ACL that corresponds to the ID mentioned above.

WAFRULEPRI: This is the priority of the WAF rule that you want to update. It’s a numeric value that determines the order in which rules are evaluated.

Save your changes after configuring the necessary environment variables.

These values allow your Lambda function to interact with your CloudFront distribution, WAF ACL, and origin server in a controlled manner.

Task 8: Review Security Configurations

In this final task, you will review and validate the security measures you have set up. Confirm secret rotation, CloudFront access, AWS WAF’s origin block, and critical configurations. This ensures robust protection and optimal functionality for your application.

a) Verify Successful Secret Rotation

In this step you will manually trigger a secret rotation in AWS Secrets Manager. You will observe Secrets Manager automatically rotates the custom header value and update the origin AWS WAF and CloudFront configurations.

Navigate to AWS Secrets Manager service.

Choose the secret, XOriginVerifySecret.
Choose Retrieve Secret Value.

When you retrieve the secret, Secrets Manager programmatically decrypts the secret and displays it in the console.

In Rotation configuration, choose Rotate secret immediately.
Confirm your selection by choosing Rotate.

After initiating rotation, wait for a few minutes for the rotation process to complete. The rotation involves updating various configurations. Refresh the page to ensure that the secret rotation process is complete.

Choose the Retrieve Secret Value option again to confirm that the secret has been successfully rotated.

Access the AWS Lambda console and navigate to your Lambda function associated with secret rotation.

Choose the Monitor tab in your Lambda function’s details.
Choose View CloudWatch Logs. A new browser page will open, directing you to the CloudWatch Logs console.

In Log groups for your function you will see a list of log streams. These represent individual executions of your Lambda function.

Choose the latest log stream.

You will see the log events generated during that execution.

In the filter box, enter the keyword Event to filter log streams related to the event you are trying to find.
Choose Display.
Choose Expand all rows.

The rotation process involves four steps:

1. **Create Secret Step**: A new secret version is generated by the Lambda function. It uses GetRandomPassword to create a random string and labels it AWSPENDING for in-progress status.

2. **Set Secret Step**: The rotation function updates the web ACL rule for the AWS WAF linked to the origin ALB. Rule statements are updated with AWSPENDING and AWSCURRENT values, along with the X-Origin-Verify header. CloudFront propagates these changes.

3. **Test Secret Step**: The Lambda function verifies AWSPENDING and AWSCURRENT X-Origin-Verify header values by accessing the origin ALB. It ensures a successful “200 OK” response.

4. **Finish Secret Step**: The AWSCURRENT label is moved from the old to the new secret version. The old version gets AWSPREVIOUS, serving as the last good version for recovery if needed. The old version is deprecated without staging labels.

Upon successful finishSecret, Secrets Manager schedules the next rotation based on the interval, updating validation headers. Monitoring usage and changes in secrets is essential for detecting and investigating unexpected usage or alterations.

b) Confirm access to the website through CloudFront

To confirm access to a website through CloudFront using AWS CloudShell, you can use the Curl -I command-line tool to send HTTPS requests to your CloudFront distribution's domain name. This will help you verify that your CloudFront distribution is properly configured and serving content from your origin server.

Access AWS CloudShell:

Open the AWS Management Console.
Search for “CloudShell” and select it from the search results.

In CloudShell copy and paste the following command, replacing the domain with your actual domain name:

curl -I https://denizyilmaz.cloud

Your successful interaction with the website demonstrates that you are able to access it securely over HTTPS.

c) Confirm that direct viewer access to the origin URL is blocked by AWS WAF

Navigate to the EC2 dashboard. In the left nagivation pane choose Load Balancers.

Find the Load Balancer associated with your CloudFront distribution.
Copy the DNS name of your Load Balancer.

In CloudShell, paste the following curl command, replacing the Application Load Balancer DNS name with the DNS name you copied. Press Enter to execute the command:

curl -I WebServer-LB-128681772.eu-west-2.elb.amazonaws.com

This confirms that your AWS WAF configuration is effectively blocking direct access to your origin resources, and requests are being routed through the Load Balancer as intended.

d) Review the CloudFront origin custom header configuration

Now that you’ve confirmed that the test website can only be accessed through CloudFront, you can review the detailed CloudFront, WAF, and Secrets Manager configurations that enable this restriction.

To review the custom header configuration, navigate to the CloudFront Console.

Choose your CloudFront distribution.
Choose Origins.
Choose Edit to go to the Origin Settings section, scroll to the bottom and review the Origin Custom Headers.

You can see that the custom header, X-Origin-Verify, has been configured using Secrets Manager with a random 32-character alpha-numeric value. This custom header will be added to web requests that are forwarded from CloudFront to your origin. Requests without this header are blocked by AWS WAF at the origin ALB.

e) Review the AWS WAF web ACL header validation rule

In this final step, you review the AWS WAF rule configuration that validates the CloudFront custom header X-Origin-Verify.

Navigate to AWS WAF and in the left navigation pane, choose Web ACLs. Ensure you are in the of your Application Load Balancer.

Choose OriginVerifyACL.

On the Overview tab, you can view the Requests per 5 minute period chart and the Sampled requests list, which shows requests from the last three hours that the ALB has forwarded to AWS WAF for inspection. The sample of requests includes detailed data about each request, such as the originating IP address and Uniform Resource Identifier (URI). You also can view which rule the request matched, and whether the rule Action is configured to ALLOW, BLOCK, or COUNT requests.

Choose the Rules tab to review the rules for this web ACL.

On the Rules tab, you can see that the OriginVerifyACL rule has been configured with the Allow action, while the Default web ACL action is Block. This means that any incoming requests that don’t match the conditions in this rule will be blocked.

Choose the OriginVerifyACL rule
Choose Edit to bring up the Rule Builder tool.

In the Rule Builder configuration for Statement 1, you can see that the request Header is being inspected for the x-origin-verify Header field name and the String to match value is set to the value you reviewed in CloudFront.

In the Rule Builder, you can also see a logical OR with an additional rule statement, Statement 2. You will notice that the configuration for Statement 2 is the same as Statement 1, except that the String to match value is different. Statement 2 helps to ensure that valid web requests are processed by your origin servers when Secrets Manager automatically rotates the value of the X-Origin-Verify header. The effect of this rule configuration is that inspected web requests will be allowed if they match either of the two statements.

Through these comprehensive tasks, you verified and reviewed the security mechanisms that underpin your application’s robust protection against potential threats and unauthorized access attempts.

Conclusion

By methodically executing these tasks, you’ve transformed your application into a securely shielded, high-performance platform that offers users a dependable experience.

Through the utilization of AWS services, configuration management, and automation, you’ve successfully deployed and managed a resilient web application that adheres to industry best practices.