Datadog provides a Terraform provider that allows you to manage your Datadog configuration as code. This includes monitors, dashboards, service level objectives (SLOs), and other resources. Using Terraform for your Datadog configuration enables version control, peer review processes, and automation through CI/CD pipelines. It also helps maintain consistency across different environments.
As someone who has been evangelizing observability-as-code for years, I would propose this for a greenfield setup:
- The first admin creates:
- an API key named Terraform
- a service account named Terraform (with a distribution email of terraform@yourdomain.com) with the Admin role (which you can filter most of to trash, and can be an alias of the admin). If you really want, you could craft a new role, called Terraform (by hand, chicken and egg problem) that has the specific permissions you want.
- an application key named Terraform owned by the service account. You might think to scope this key, but scoped keys can introduce issues in certain obscure cases.
-
Terraform can now be used to:
- Import the role and service account you created earlier (API key and application key imports will probably be deprecated by the time you read this)
- Create a read role with all the read permissions you want to the products and services you will utilize in Datadog
- Create one or more roles with the specific edit permissions you want