CloudFront Deployment

Introduction

Darwinium can be configured to publish workers to Amazon CloudFront. This enables you to perform decisioning at the edge using your CloudFront infrastructure.

Configuring CloudFront requires an administrator with access to the AWS CloudFront dashboard and the ability to:

• create a Cloudfront Distribution (if there isn't one already)

• create cross-account AWS IAM roles.

This guide assumes familiarity with your organization's Cloudfront configuration and the setup of IAM roles.

Overview

Darwinium uses the following configuration elements:

• CloudFront Distribution ID

• AWS role ARNs to configure deployments to the distribution and workers to AWS Lambda
  
  A typical Cloudfront deployment on a one-edge deployment device takes approximately 1 hour to setup and validate under a standard configuration. Manual configuration involving Terraform will take longer.
  

  Summary of IAM roles & Policies Needed

  Type	Name	Description
  Role	Lambda@Edge Execution role	Role assumed by Darwinium Lambdas on your AWS account when they are running at the edge. Depending on your configuration, this execution role will be setup to write to your events S3 bucket (if bringing your own storage)
  Role	Cloudfront Builder IAM role	Role assumed by Darwinium’s Cloudfront builder tool.
  Policy	Cloudfront builder IAM Policy	Policy associated with the Cloudfront builder IAM role. This is used when you publish changes to your journey. It enables our tool to deploy new lambdas to your infrastructure, create function associations between lambdas and routes on your Cloudfront distribution, and remove these as necessary when there are changes to your Darwinium journey configuration.

Deployment Setup

Step 1 - Get External ID from the  Darwinium Portal

1. In the Darwinium portal, navigate to Admin > Nodes

2. Select the node you wish to configure and click

3. A dialog will appear. Select Cloud Deployment in the top tabs, then CloudFront from the left-pill menu

4. A system generated External ID will appear. Copy this to your clipboard - it will be used to configure cross account roles in AWS.

Step 2 - Note your AWS customer details

Login to the AWS administrator console and click on your username to the top right. Note your AWS Account ID:

Step 3 - Create a CloudFront distribution (if needed)

1. Login to the AWS console and navigate to the CloudFront dashboard. Select Distributions from the navigation menu, then Create Distribution.

2. Set the origin domain - this is essentially the domain that exists behind your AWS private network. This typically points to another AWS resource such as an EC2 instance, load balancer or S3 bucket.

3. Additional settings for accessing your origin are configured below. This is contingent upon your origin's configuration and company communication policies. Darwinium recommends using HTTPS only or Match viewer

   

4. Your Origin path should likely be left blank (however this may differ from implementation to implementation)

5. Give your origin a name: eg

   my-service

6. No custom headers are needed by Darwinium, but may be configured as needed by your organization

7. Enable Origin Shield should be set to No

8. Additional Settings should be left at the AWS defaults:

   • Connection attempts:3

   • Connection timeout:10

   • Response timeout:30

   • Keep-alive timeout:5

Default cache behavior:

The following settings should be set:

• Path Pattern: Default (*)

• Compress objects automatically: Yes

• Viewer protocol policy: Redirect HTTP to HTTPS (this will vary upon your organizations security policies and configuration. Please consult an administrator)

• Allowed HTTP Methods: GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

• Restrict Viewer Access: No (this will vary upon your organizations security policies and configuration)

Cache key and origin requests

Set this to Cache policy and origin request policy:

• Cache Policy: CachingOptimized

• Origin Request Policy AllViewer

• Response Headers Policy: : SimpleCORS (this may vary depending on your organizations security policy

Additional Settings

Additional settings can be configured as part of the organizations policy. Darwinium recommends creating a Real-time log configuration for troubleshooting the operation of the Darwinium Edge workers

Function associations

These are configured automatically by darwinium and left as No association

Settings

Settings Contingent upon your configuration - we recommend selecting Use all edge locations (best performance) and configuring an SSL certificate using the AWS certificate manager. This is also where you will input alternate domain name (CNAME) settings for your edge workers.

Create Lambda Execution Role to allow calling your existing Cloudfront Functions or Lambda@edge

Step 4 - Create Lambda@Edge Execution Roles

This IAM role will be used by the Darwinium Lambda functions during execution. When you are using a Customer Hosted S3 bucket, the Darwinium Lambda@Edge functions will write encrypted PII data directly to your S3 bucket on your infrastructure, with no part of this write process involving Darwinium infrastructure for maximum security and performance.

In the AWS console:

1. Go to IAM > Roles > Create Role

2. Specify a custom trust policy with the following contents:

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Principal": {
                   "Service": [
                       "edgelambda.amazonaws.com",
                       "lambda.amazonaws.com"
                   ]
               },
               "Action": "sts:AssumeRole"
           }
       ]
   }

3. Go to IAM > Policies > Create Policy, with the following policy contents

   Code Block
   {    "Version": "2012-10-17",    "Statement": [        {            "Effect": "Allow",            "Action": ["cloudfront:GetFunction", "lambda:GetFunction"],            "Resource": "*"        }    ] }

   Darwinium’s deployment manager automatically finds Lambdas and Cloudfront Functions currently on your site and calls them from inside the newly installed lambdas. If you do not intend to use your own Lambdas/Cloudfront Functions alongside Darwinium, you can skip this step.

   1. cloudfront:GetFunction is needed when you have Cloudfront Functions on path that you wish to protect with Darwinium

   2. lambda:GetFunction is needed when you have a Lambda@Edge bound to a path that you wish to protect with Darwinium.

4. On the Add Permissions menu add the following Policy

   AWSLambdaBasicExecutionRole

   Add policy added in step 3.

5. If you are using a BYO S3 bucket, add the S3 write-only policy that was created when you setup BYO storage.

   BYO S3 Event Storage outlines the process for optionally setting up Darwinium with your own S3 bucket to store event details.

   If your BYO S3 Bucket is in a different AWS account to your Lambdas and Lambda execution role, you must also create a bucket policy for it as described in BYO S3 installation.

   You will also need to create a duplicate S3 write-only IAM policy for attaching to your Lambda execution role in the account with your Lambdas. This should be identical to the main S3 write-only IAM policy created in the account with the S3 bucket.

6. Choose an appropriate name for the role, and note down the role's ARN once created. It will look like

   arn:aws:iam::123456789:role/lambdarole

Step 5 : Create Darwinium CloudFront builder IAM policy

This IAM policy will be used by Darwinium to create Lambda functions and attach them to a CloudFront distribution

1. Go to IAM > Policies > Create Policy

2. Edit the policy template provided below as follows:

   • For

     arn:aws:lambda:*:AWSACCOUNTID:function:dwn*

     and

     arn:aws:cloudfront::AWSACCOUNTID:function/*

     replace

     AWSACCOUNTID

     with your AWS account ID from step 2. For example:

     arn:aws:lambda:*:123456789:function:dwn*

     and

     arn:aws:cloudfront::123456789:function/*

   • For

     arn:aws:cloudfront::AWSACCOUNTID:distribution/DISTRIBUTION

     replace

     AWSACCOUNTID

     as above, and

     DISTRIBUTION

     with your CloudFront DistributionID. For example:

     arn:aws:cloudfront::123456789:distribution/ABCDEFGHIJKL

   • For

     EXECUTIONROLEARN

     replace the whole string with the execution role ARN you created above. For example:

     arn:aws:iam::123456789:role/lambdarole

{
    "Statement": [
        {
            "Action": [
                "lambda:UpdateFunctionConfiguration",
                "lambda:UpdateFunctionCode",
                "lambda:PublishVersion",
                "lambda:EnableReplication*",
                "lambda:DeleteFunction",
                "lambda:CreateFunction"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:lambda:*:AWSACCOUNTID:function:dwn*"
            ]
        },
        {
            "Action": [
                "iam:PassRole",
                "iam:GetRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "EXECUTIONROLEARN"
            ]
        },
        {
            "Action": [
                "cloudfront:UpdateDistribution",
                "cloudfront:GetDistributionConfig",
                "cloudfront:GetDistribution"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:cloudfront::AWSACCOUNTID:distribution/DISTRIBUTION"
            ]
        },
        {
            "Action": [
                "cloudfront:UpdateFunction",
                "cloudfront:PublishFunction",
                "cloudfront:DescribeFunction",
                "cloudfront:CreateFunction",
                "cloudfront:DeleteFunction"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:cloudfront::AWSACCOUNTID:function/dwn*"
            ]
        },
        {
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:iam::AWSACCOUNTID:role/aws-service-role/replicator.lambda.amazonaws.com/AWSServiceRoleForLambdaReplicator",
                "arn:aws:iam::AWSACCOUNTID:role/aws-service-role/logger.cloudfront.amazonaws.com/AWSServiceRoleForCloudFrontLogger"
            ]
        },
        {
            "Action": [
                "lambda:ListFunctions",
                "lambda:GetFunction",
                "lambda:ListVersionsByFunction",
                "cloudfront:ListResponseHeadersPolicies",
                "cloudfront:ListOriginRequestPolicies",
                "cloudfront:ListFunctions",
                "cloudfront:ListDistributions",
                "cloudfront:ListCachePolicies"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "2012-10-17"
}

Scoping:

Darwinium always prefaces its own Lambdas and Cloudfront Functions with “dwn”, so create/update/publish/delete access is limited to these names.

Darwinium needs get/list access to all Lambdas and Functions in order to detect which functions are already configured on routes that Darwinium is to protect.

Note:

If you do not have an existing Lambda@Edge function on your CloudFront distribution, you can further restrict your Darwinium CloudFront builder IAM policy as follows:

Movelambda:GetFunction and lambda:ListVersionsByFunction from the clause with Resource "*" to the clause with Resource "arn:aws:lambda:*:AWSACCOUNTID:function:dwn"

3. Save the edited result as the JSON Policy for your new IAM policy

Step 6: Create Darwinium CloudFront builder IAM Role

This IAM Role will be assumed by Darwinium to create Lambda functions and attach them to a CloudFront distribution

1. Go to IAM > Roles > Create Role

2. Edit the policy template provided below, replacing

   EXTERNALID

   EXTERNALID = The ExternalID that you obtained in step 1

   DWNACCOUNTID

   DWNACCOUNTID = Will be supplied directly by Darwinium upon install.

3. Use the edited result as the custom trust policy for your new IAM Role

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::DWNACCOUNTID:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "EXTERNALID"
                },
                "ArnLike": {
                    "aws:PrincipalArn": "arn:aws:iam::DWNACCOUNTID:role/crossaccountassumers/*"
                }
            }
        }
    ]
}

3. (optional, only if duplicate targets required) If multiple identical Darwinium targets EXTERNALID1 , EXTERNALID2 need the same Cloudfront distribution, they can be listed within the StringEquals parameter. This is unusual but can happen when sharing repositories between nodes with unbalanced targets (eg. sandbox has single distribution for everything, production has multiple distributions).
   

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Sid": "",
               "Effect": "Allow",
               "Principal": {
                   "AWS": "arn:aws:iam::DWNACCOUNTID:root"
               },
               "Action": "sts:AssumeRole",
               "Condition": {
                   "StringEquals": {
                       "sts:ExternalId": [
                           "EXTERNALID1",
                           "EXTERNALID2"
                       ]
                   },
                   "ArnLike": {
                       "aws:PrincipalArn": "arn:aws:iam::DWNACCOUNTID:role/crossaccountassumers/*"
                   }
               }
           }
       ]
   }

4. Next, on the Add Permissions menu, select the Darwinium CloudFront builder policy that you created above

5. Choose an appropriate name for the role, and note down the role's ARN once created. It will look like

   arn:aws:iam::123456789:role/cloudfrontbuilderrole

Step 7: Apply CloudFront fields in Darwinium Portal

1. Navigate to the Darwinium portal and login as a user who has sufficient privileges to edit node settings.

2. Select Node settings from the side menu:

3. Select the node you wish to configure, and select settings

4. Navigate to the CloudFront Deploymentsection, and enter details for

   Distribution ID

   (from step 3),

   Lambda@Edge execution role ARN

   (from step 4) ,

   Deployment Role ARN

   (from step 6).

Publish your first Journey

In order to complete your first deployment, you will need to publish a journey.

see: Editing Overview

Monitoring & Alerting

Darwinium suggests using monitoring & alerting for tracking: Request Errors and Lambda execution times

Additional AWS Considerations

There are AWS imposed limits to be aware of when Darwinium is in operation; always check AWS documentation for the latest guidance.

See: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-general

Headers & URL size limit

Requests served by CloudFront have a limit of 20,480 bytes for the combined size of URL and Headers.

• The Darwinium profileBlob that is collected and inserted into header can feasibly be up to ~6KB with all toggles enabled (eg. geolocation) and multiple keyboard behavioural biometrics fields profiled. It should be validated in a staging environment that your existing requests are not exceeding the overall limit by including the Darwinium profiling with desired toggles.

• “Custom Headers” are those added to the request to the origin by CloudFront and have size and number limits. The Darwinium profileBlob does not impact the limits here as it is not added by CloudFront. It is not the case by default, but the Darwinium journey file can be configured to insert additional derived values into the headers; those should be reviewed if configured, but are typically single attribute values that are well under the 1,783 character limit.
  
  See Inserting Darwinium JS Profiling for context and approaches that reduce this if needed.

Cache Behaviour Limits

Darwinium creates a bespoke behaviour for each journey step configured.

On journeys with many steps or if behaviours are already in use too, the default number provisioned by AWS (25) can be exceeded. The Darwinium Deployment manager will not be able to deploy any more steps when at this soft limit.

This is a limit you can request AWS to increase directly from their limits page, under
General quotas on distributions > Cache behaviors per distribution
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html#limits-general

You may need written justification; an example of requesting higher limit:

We request increasing the cache behaviors limit on CloudFront distributions from 25 to 100. We use ‘Darwinium’, who are on the AWS Marketplace for security and fraud detection. That necessitates more cache behaviors to cover our site journeys. This enhancement will better support our growing infrastructure and security needs.