- Print
- DarkLight
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.
Follow security best practices!
Darwinium highly recommends that you follow this guide for setting up a user with a role granted the minimum privileges necessary to perform a deployment to your CloudFront distribution.
Never use the root user for any configuration or operations
Deployment Setup
Step 1 - Get External ID from the Darwinium Portal
In the Darwinium portal, navigate to Admin > Nodes
Select the node you wish to configure and click
A dialog will appear. Select Cloud Deployment in the top tabs, then CloudFront from the left-pill menu
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:
Note your AWS Account ID
This will be used in subsequent steps. In the example above, an Account ID of "1234-5678-9012" will be entered as "123456789012" in role ARNs
Step 3 - Create a CloudFront distribution (if needed)
Login to the AWS console and navigate to the CloudFront dashboard. Select Distributions from the navigation menu, then Create Distribution.
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.
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
Your Origin path should likely be left blank (however this may differ from implementation to implementation)
Give your origin a name: eg
my-service
No custom headers are needed by Darwinium, but may be configured as needed by your organization
Enable Origin Shield should be set to No
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.
Take note of your domains and Distribution ID
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:
Go to IAM > Roles > Create Role
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" } ] }
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.
cloudfront:GetFunction
is needed when you have Cloudfront Functions on path that you wish to protect with Darwiniumlambda:GetFunction
is needed when you have a Lambda@Edge bound to a path that you wish to protect with Darwinium.
On the Add Permissions menu add the following Policy
AWSLambdaBasicExecutionRole
Add policy added in step 3.
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.
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
Go to IAM > Policies > Create Policy
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:
Move
lambda:GetFunction
andlambda:ListVersionsByFunction
from the clause with Resource"*"
to the clause with Resource"arn:aws:lambda:*:AWSACCOUNTID:function:dwn"
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
Go to IAM > Roles > Create Role
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.
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/*"
}
}
}
]
}
(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/*" } } } ] }
Next, on the Add Permissions menu, select the Darwinium CloudFront builder policy that you created above
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
Navigate to the Darwinium portal and login as a user who has sufficient privileges to edit node settings.
Select Node settings from the side menu:
Select the node you wish to configure, and select settings
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
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.
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.