This article is part of a series on data security.
Customers can send data to the Datadog service by using a locally installed Agent or through our HTTP API. While use of Datadog does not strictly require use of the Datadog Agent, the vast majority of customers leverage the Agent. This article describes the main security capabilities and features available to customers to ensure their environment is secure.
The official repositories and/or binary packages of the Agent are signed. Verify the distribution channel by checking the signature against one of the following public keys:
21fe8679bdfb16b879a87df228003758b62abf5eFDD2ADF623EA75E62C6DC6DBFBA7520CA549AB7314E660D78B0E3DCCF15B2FBAThe Datadog Agent submits data to Datadog over a TLS-encrypted TCP connection by default. As of version 6, the Agent can be configured to enforce TLS 1.2 when connecting to Datadog. Customers who require the use of “strong cryptography,” for example, to meet PCI requirements, should use Agent v6 and set the force_tls_12: true setting in the Agent’s configuration file.
Datadog is a SaaS product: customers need to establish an outbound connection from their network to the public internet in order to submit monitoring data. Traffic is always initiated by the Agent to Datadog via TLS-encrypted TCP connection by default. No sessions are ever initiated from Datadog back to the Agent. See the Agent’s Network page for more information on configuring firewalls to whitelist the required Datadog domains and ports. Additionally, customers monitoring hosts with no direct connectivity to the public internet, or with restricted outbound traffic, should consider submitting monitoring data via a Proxy.
The Datadog Agent generates local logs in order to support Agent troubleshooting as required. As a safety precaution, these local logs are filtered for some specific keywords and patterns that could indicate a potential credential (e.g. API key, password and token keywords, etc.), which are then obfuscated before being written to disk.
Agent v6 exposes a local HTTPS API to ease communication between a running Agent and Agent tools (e.g. the datadog-agent commands). The API server can only be accessed from the local network interface (localhost/127.0.0.1), and authentication is enforced through a token that’s only readable by the user that the Agent runs as. Communication to the local HTTPS API is encrypted in transport to protect from eavesdropping on localhost.
Agent v6 comes bundled with a Graphical User Interface (GUI) by default, which launches in your default web browser. The GUI is launched only if the user launching it has the correct user permissions, including the ability to open the Agent’s configuration file. The GUI can only be accessed from the local network interface (localhost/127.0.0.1). Finally, the user’s cookies must be enabled, as the GUI generates and saves a token used for authenticating all communications with the GUI server as well as protecting against Cross-Site Request Forgery (CSRF) attacks. The GUI can also be disabled altogether if needed.
Datadog’s Vulnerability Management program includes regular assessments of supporting infrastructure and application components, including active scans of core supporting services. Datadog Security teams perform monthly scans to identify configuration and software vulnerabilities, and track remediation of findings according to Datadog’s Vulnerability Management policy.
Regarding its Container Agent specifically, Datadog performs regular vulnerability static analysis using clair by CoreOS and snyk.io. Additionally, Datadog leverages security scanning as part of its releases of the Container Agent to the Docker Trusted Registry, as well as the Red Hat Container Catalog. In addition to Datadog’s internal Vulnerability Management program, Datadog also partners with container security vendors.
If you believe you’ve discovered a bug in Datadog’s security, get in touch at security@datadoghq.com and we will get back to you within 24 hours. Datadog’s PGP key is available for download in case you need to encrypt communications with us. We request that you not publicly disclose the issue until we have had a chance to address it.
By default, the Agent runs as the dd-agent user on Linux and as the ddagentuser account on Windows. Note the system-probe and security-agent services are an exception to this, and still need to run as root on Linux and LOCAL_SYSTEM on Windows.
Customers with a requirement to avoid storing secrets in plaintext in the Agent’s configuration files can leverage the secrets management package. This package allows the Agent to call a user-provided executable to handle retrieval or decryption of secrets, which are then loaded in memory by the Agent. Users have the flexibility to design their executable according to their preferred key management service, authentication method, and continuous integration workflow.
For more information, see the Secrets Management documentation.
Additional helpful documentation, links, and articles:
