Skip to content

docs: Update README to indicate that using DD_API_KEY directly is not the recommended approach #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 11, 2025
Merged

docs: Update README to indicate that using DD_API_KEY directly is not the recommended approach #55

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ Please refer to the official Datadog [`datadog-serverless-functions`](https://gi
There are several factors to keep in mind when working with and/or using this module that largely revolve around the decisions made based on security implications.

1. Based on the functionality provided by the Datadog team at [`datadog-serverless-functions`](https://github.com/DataDog/datadog-serverless-functions/tree/master/aws), the recommended approach for providing your Datadog API key is through AWS Secrets Manager. The creation of this secret is not facilitated by this module and should be created manually (or through some other means where the secret is not passed as plain text into Terraform as input).
- Note: even though this is the recommended approach, the pattern used in the past of providing the `DD_API_KEY` as an environment variable is still supported by the module. Users are able to provde any and all environment variables to the forwarders through inputs (i.e. - `log_forwarder_environment_variables`) to configure the forwarders as desired. See [`settings.py`](https://github.com/DataDog/datadog-serverless-functions/blob/master/aws/logs_monitoring/settings.py) for more details on what environment variables are supported to configure the forwarders.
- Note: even though this is not the recommended approach, the pattern used in the past of providing the `DD_API_KEY` as an environment variable is still supported by the module. Users are able to provde any and all environment variables to the forwarders through inputs (i.e. - `log_forwarder_environment_variables`) to configure the forwarders as desired. See [`settings.py`](https://github.com/DataDog/datadog-serverless-functions/blob/master/aws/logs_monitoring/settings.py) for more details on what environment variables are supported to configure the forwarders.
2. The use of a KMS key to encrypt/decrypt API and APP keys is required by the [`rds_enhanced_monitoring_forwarder`](./modules/rds_enhanced_monitoring_forwarder) and [`vpc_flow_log_forwarder`](./modules/vpc_flow_log_forwarder) modules/functions per the upstream source at [`datadog-serverless-functions`](https://github.com/DataDog/datadog-serverless-functions/tree/master/aws). The creation of a KMS key has been left out of this module so that users are able to better manage their KMS CMK key (and therefore the policies and usage of said key) as they see fit without over-complicating this module.
3. The roles and their permissions created by this module have several built in conditional checks in order to provide permission sets that allow the desired functionality while following the recommended approach of least privelege access. Nearly all attributes for the IAM roles and their permissions are accessible via inputs - even allowing users to provide their own IAM roles and/or policies to meet their organizational requirements.

Expand Down