Add proxy configuration instructions for Operator and Helm#37798
Add proxy configuration instructions for Operator and Helm#37798beommoyang wants to merge 10 commits into
Conversation
Added configuration instructions for using Squid proxy with the Datadog Agent across different setups.
|
/review |
Preview links (active after the
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
This PR adds Operator and Helm tabs to the Agent configuration section, which is a useful expansion. Main finding: the new tabs reference a Squid service running inside Kubernetes (squid-proxy.proxy-namespace.svc.cluster.local), but the earlier sections of the page only cover installing Squid on a Linux/Windows host and configure Squid with an ACL that only accepts 127.0.0.1 traffic. Users following the Operator/Helm path won't have a working setup without additional steps that aren't documented here. A few smaller nits inline.
Reviewed dcd0e7f77f7b8d15839c2651752c10a0e6d96ee0 — workflow run
| {{% /tab %}} | ||
| {{% tab "Operator" %}} | ||
|
|
||
| Modify the DatadogAgent CR to include the following: |
There was a problem hiding this comment.
Issue: The example points to a Squid service running inside Kubernetes (squid-proxy.proxy-namespace.svc.cluster.local), but earlier on this page Squid is installed only on a Linux/Windows host, and the squid.conf example sets acl local src 127.0.0.1/32 which rejects traffic from other pods. Users who follow these new Operator/Helm tabs won't have a working setup. Consider adding a short note (or a link) covering how to deploy Squid in-cluster and how to adjust the ACL to allow the cluster's pod CIDR — otherwise this section gives a configuration that can't connect to the Squid built earlier in the doc.
| @@ -82,6 +85,36 @@ | |||
|
|
|||
| After saving these changes, [restart the Agent][1]. | |||
There was a problem hiding this comment.
Suggestion: Only the Host tab tells users to restart the Agent for changes to take effect. For parity, consider adding a one-liner to the Operator and Helm tabs noting how the change is applied (Operator reconciles automatically once the CR is updated; Helm requires helm upgrade to roll out the new pods).
|
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Updated instructions for configuring Squid proxy, including examples for wildcard and explicit domain access control. Clarified modification of the DatadogAgent custom resource.
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
Reviewed the Squid proxy doc additions: alternative explicit endpoint list, and Operator/Helm tabs for Agent configuration. Findings are mostly style/clarity — no blockers. The most substantive concern is that the new Operator/Helm tabs assume Squid is running inside the Kubernetes cluster (using a *.svc.cluster.local address), which is a different deployment posture from the Squid install steps earlier on the page — worth a sentence of context.
Reviewed 7d2daa6944c6287b1ad0ec7babbb1aac955b44f1 — workflow run
| acl Datadog dstdomain agent.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain process.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain logs.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain api.{{< region-param key="dd_site" >}} |
There was a problem hiding this comment.
Suggestion: Squid does merge multiple acl directives that share a name, but listing every domain on its own line obscures that intent and is unusual in published Squid examples. Combining them into a single acl definition is clearer and matches the wildcard example above (which uses one line):
| acl Datadog dstdomain api.{{< region-param key="dd_site" >}} | |
| acl Datadog dstdomain agent.{{< region-param key="dd_site" >}} process.{{< region-param key="dd_site" >}} logs.{{< region-param key="dd_site" >}} api.{{< region-param key="dd_site" >}} |
| http_access allow local manager | ||
| ``` | ||
|
|
||
| Alternatively, if you require more granular control, you can explicitly list each Datadog endpoint instead of using a wildcard. For the full list of domains and IP ranges the Agent needs to reach, see [Network Traffic][7]. For example: |
There was a problem hiding this comment.
Issue: The list agent, process, logs, api is a non-exhaustive sample (the Network Traffic page lists many more intake subdomains: trace., dbm-metrics-intake., instrumentation-telemetry-intake., orchestrator., ndm-intake., and so on). Without that caveat, a reader who copies this block to gain "more granular control" will silently lose telemetry from any product whose intake isn't in the four lines below. Consider explicitly noting this is a minimal example and that the user must add the subdomains for every Datadog product they use, per the Network Traffic link.
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
/review |
There was a problem hiding this comment.
🤖 Automated review by Claude. AI-generated; verify before acting.
One suggestion on parallel structure between the new Host, Operator, and Helm tabs. The new content reads well; nice Vale-compliant rewording of "is able to" → "can".
Reviewed 71d9f05da256bd95830ad7a7a613a2b1db338748 — workflow run
| acl Datadog dstdomain agent.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain process.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain logs.{{< region-param key="dd_site" >}} | ||
| acl Datadog dstdomain api.{{< region-param key="dd_site" >}} |
There was a problem hiding this comment.
Suggestion: This example only covers four endpoints, but the Agent reaches many more (process, trace, profiling, DBM, telemetry, NDM, and others depending on enabled products). The intro text already points to [Network Traffic][7] for the full list, but consider making it explicit that this snippet is a pattern to extend — not a complete allowlist — so copy-paste users don't end up with a broken proxy after enabling additional products.
Updated language for clarity and precision in the proxy_squid.md documentation.
Bits is fixing CI🟢 Investigated · 🔵 Preparing fix · ⚪ Validate · ⚪ Ready View in Datadog | Reviewed commit 25edc4c |
brett0000FF
left a comment
brett0000FF
left a comment
There was a problem hiding this comment.
Thanks! Approving, but please fix the warning shortcode before merging.
| {{< warning >}} | ||
| The example below only includes a subset of Datadog endpoints. Make sure to include all domains required by the Datadog features you use. See [Network Traffic][7] for the complete list. | ||
| {{< /warning >}} |
There was a problem hiding this comment.
There is no warning shortcode, so we should use the alert classes. Also, in case you are curious, our styling is backwards, so danger will render as a yellow callout.
| {{< warning >}} | |
| The example below only includes a subset of Datadog endpoints. Make sure to include all domains required by the Datadog features you use. See [Network Traffic][7] for the complete list. | |
| {{< /warning >}} | |
| <div class="alert alert-danger"> | |
| The example below only includes a subset of Datadog endpoints. Make sure to include all domains required by the Datadog features you use. See [Network Traffic][7] for the complete list. | |
| </div> |
2 participants
Added configuration instructions for setting up a proxy in the Datadog Agent using different methods: Host, Operator, and Helm.
What does this PR do? What is the motivation?
What does this PR do? What is the motivation?
The existing proxy configuration documentation only covered the Host (datadog.yaml) setup. This PR expands coverage in two areas:
Kubernetes deployment methods: Adds configuration instructions for Kubernetes environments using the Datadog Operator and Helm, alongside the existing Host tab.
Squid ACL configuration options: Expands the Squid setup guide to document both the wildcard approach (.datadoghq.com) and the explicit per-endpoint ACL approach for users who require more granular traffic control. References the Network Traffic page for the full list of Datadog endpoints.
Merge readiness
For Datadog employees:
<name>/<description>convention and include the forward slash (/). If you've already created your PR with an incorrect branch name, please rename your branch and open a fresh PR./reviewto run an automated check that catches common issues before a Documentation team member reviews your PR.AI assistance
Used Claude Code for research and drafting.
Additional notes