[OTAGENT-980] Reference v1.0.5 WorkloadAllowlist exemption when OTel collector is enabled#3022
[OTAGENT-980] Reference v1.0.5 WorkloadAllowlist exemption when OTel collector is enabled#3022songy23 wants to merge 3 commits into
Conversation
…l collector is enabled When the OTel collector is enabled on GKE Autopilot, the otel-agent (ddot-collector image) container's hostPath mounts (e.g. /var/run/containerd) are rejected by Warden because no current partner exemption permits them. Add the v1.0.5 exemption path to the AllowlistSynchronizer that the operator provisions whenever the DatadogAgent renders an otel-agent container. The matching v1.0.5 exemption YAML is published separately in the partner allowlist repo. Mirrors the helm-charts change in OTAGENT-980 (follow-up to OTAGENT-448). Changes: - ComputeAllowlistPaths returns the set of exemption paths for the synchronizer, appending v1.0.5 when otelCollectorEnabled is true. - CreateAllowlistSynchronizer takes an otelCollectorEnabled flag. - applyExperimentalAutopilotOverrides detects the otel-agent container in the rendered pod template and passes the flag through. - New unit tests cover ComputeAllowlistPaths and hasOtelAgentContainer. Refs: OTAGENT-980 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3022 +/- ##
==========================================
+ Coverage 41.50% 41.75% +0.24%
==========================================
Files 335 335
Lines 28714 28735 +21
==========================================
+ Hits 11919 11998 +79
+ Misses 16001 15936 -65
- Partials 794 801 +7
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
🎯 Code Coverage (details) 🔗 Commit SHA: 9437b3c | Docs | Datadog PR Page | Give us feedback! |
GKE Autopilot plumbing testTested on a fresh GKE Autopilot cluster (
As expected,
Result: PASS. The refactor correctly threads the Cluster has been deleted. |
Extract reconcileAllowlistSynchronizer from CreateAllowlistSynchronizer so the Get/Create reconciliation can be exercised against a fake client (the k8s plumbing wrapper that loads kubeconfig and builds the rest client remains out of scope for unit tests). In the experimental autopilot package, expose a package-level createAllowlistSynchronizer var so tests can stub the synchronizer creator and cover applyExperimentalAutopilotOverrides without hitting kubeconfig. New tests: - TestReconcileAllowlistSynchronizer: covers the create-when-absent, no-op-when-exists, Get-error, AlreadyExists, and other-Create-error branches (100% line coverage). - TestCreateAllowlistSynchronizerResource: verifies the rendered resource for both the OTel-enabled and disabled cases. - TestApplyExperimentalAutopilotOverrides_SynchronizerInvocation: asserts the autopilot override path invokes the synchronizer creator with the correct otelCollectorEnabled flag derived from the pod template. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f3b538ac1
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Address PR review (#3022): the previous early-return on Get success meant that an AllowlistSynchronizer left over from an older operator version (or from a prior install with OTel disabled) would never get the v1.0.5 path added when OTel is enabled later. Warden would then keep rejecting the otel-agent pod even though the operator had reconciled. reconcileAllowlistSynchronizer now compares the existing spec.allowlistPaths against ComputeAllowlistPaths(otelCollectorEnabled) and issues an Update when they differ. Same direction in reverse: if OTel is disabled later, v1.0.5 is dropped from the spec. New test cases: - no-op when existing paths match desired - update when stale paths are missing v1.0.5 - update when stale paths still have v1.0.5 after OTel is disabled - silent return when Update fails Refs: OTAGENT-980 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 participants
Summary
Mirror of DataDog/helm-charts#2667 for the operator-managed AllowlistSynchronizer. When the OTel collector is enabled on GKE Autopilot, the
otel-agent(ddot-collector image) container's hostPath mounts (e.g./var/run/containerd) are rejected by Warden because no current partner exemption permits them.This PR has
CreateAllowlistSynchronizerappend thev1.0.5exemption path whenever the rendered pod template contains theotel-agentcontainer. The matchingv1.0.5exemption YAML is published separately indatadog-gke-workload-allowlist.Follow-up to OTAGENT-448. Issue: OTAGENT-980.
Changes
pkg/allowlistsynchronizer/allowlistsynchronizer.go:ComputeAllowlistPaths(otelCollectorEnabled bool)returns the right set of exemption paths.CreateAllowlistSynchronizertakes theotelCollectorEnabledflag and uses it.internal/controller/datadogagent/experimental/autopilot.go:hasOtelAgentContainerhelper inspects the rendered PodTemplateSpec for theotel-agentcontainer name and passes the flag intoCreateAllowlistSynchronizer.ComputeAllowlistPaths,newAllowlistSynchronizer, andhasOtelAgentContainer.Test plan
go test ./internal/controller/datadogagent/experimental/... ./pkg/allowlistsynchronizer/... -vpassesgo build ./...succeedsfeatures.otelCollector.enabled: trueon GKE Autopilot and verify Warden admits the pod (depends on the matchingv1.0.5partner allowlist YAML being published)🤖 Generated with Claude Code