Security Considerations for Synthetics Canaries - Amazon CloudWatch

Security Considerations for Synthetics Canaries

The following sections explain security issues that you should consider when creating and running canaries in Synthetics.

Use Secure Connections

Because canary code and the results from canary test runs can contain sensitive information, do not have your canary connect to endpoints over unencrypted connections. Always use encrypted connections, such as those that begin with https://.

Canary Naming Considerations

The Amazon Resource Name (ARN) of a canary is included in the user-agent header as a part of outbound calls made from the Puppeteer-driven Chromium browser that is included as a part of the CloudWatch Synthetics wrapper library. This helps identify CloudWatch Synthetics canary traffic and relate it back to the canaries that are making calls.

The canary ARN includes the canary name. Choose canary names that do not reveal proprietary information.

Additionally, be sure to point your canaries only at websites and endpoints that you control.

Secrets in Canary Code

We recommend that you don't include secrets, such as access keys or database credentials, in your canary source code. For more information about how to use AWS Secrets Manager to help keep your secrets safe, see What is AWS Secrets Manager?.

Permissions Considerations

We recommend that you restrict access to resources that are created or used by CloudWatch Synthetics. Use tight permissions on the Amazon S3 buckets where canaries store test run results and other artifacts, such as logs and screenshots.

Similarly, keep tight permissions on the locations where your canary source code is stored, so that no user accidentally or maliciously deletes the Lambda layers or Lambda functions used for the canary.

To help make sure you run the canary code you intend, you can use object versioning on the Amazon S3 bucket where your canary code is stored. Then when you specify this code to run as a canary, you can include the object versionId as part of the path, as in the following examples.

Stack Traces and Exception Messages

By default, CloudWatch Synthetics canaries capture any exception thrown by your canary script, no matter whether the script is custom or is from a blueprint. CloudWatch Synthetics logs both the exception message and the stack trace to three locations:

  • Back into the CloudWatch Synthetics service to speed up debugging when you describe test runs

  • Into CloudWatch Logs according to the configuration that your Lambda functions are created with

  • Into the Synthetics log file, which is a plaintext file that is uploaded to the Amazon S3 location specified by the value you set for the resultsLocation of the canary

If you want to send and store less information, you can capture exceptions before they return to the CloudWatch Synthetics wrapper library.

Scope Your IAM Roles Narrowly

We recommend that you do not configure your canary to visit potentially malicious URLs or endpoints. Pointing your Canary to untrusted or unknown websites or endpoints could expose your Lambda function code to malicious user’s scripts. Assuming a malicious website can break out of Chromium, it could have access to your Lambda code in a similar way to if you connected to it using an internet browser.

Run your Lambda function with an IAM execution role that has scoped-down permissions. This way, if your Lambda function is compromised by a malicious script, it is limited in the actions it can take when running as your canary’s AWS account.

When you use the CloudWatch console to create a canary, it is created with a scoped-down IAM execution role.

Header Logging

By default, canary header logging logs only the request URL, response code, and response status. Within your canary script, you can customize the logging to log more or less information.