Datadog has 600+ out-of-the-box integrations that cover a variety of technologies, from web servers to databases to 3rd party SaaS services. For many of these integrations, there are agent configuration files that require storing credentials for the technology. The larger issue is around how to store those credentials. Many security-minded engineers would prefer not to store those secrets in plaintext in case of unauthorized access to their servers or shared access to Datadog configuration. What not everyone knows is that the Datadog agent has a mechanism to run an executable at agent startup in order to reach out to a secrets management tool of your choosing and decrypt those secrets, storing them in memory for use by the agent.
Secrets Configuration
If you want to utilize Datadog’s secrets management capabilities, there is a specific notation that the agent recognizes. Let’s take the Datadog MySQL integration as an example. While the integration, by default, only collects information from performance-related tables, you might grant additional access to other database tables to ingest more business-specific metrics into the platform via custom queries. This may require additional permissions for more sensitive data, so you might want to ensure that the credential is not stored in plaintext in the integration configuration.
