Conversation
Run CWS and CSPM without the security agent: - DD_RUNTIME_SECURITY_CONFIG_ENABLED=true enables runtime security in system-probe.yaml with direct_send_from_system_probe, and leaves security-agent.yaml alone. - DD_COMPLIANCE_CONFIG_ENABLED=true enables compliance_config with run_in_system_probe in datadog.yaml. An existing security-agent.yaml gets direct_send_from_system_probe so it stops sending CWS events, but it is never created.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b6b7b456a1
ℹ️ 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".
| if $sudo_cmd sed -n "/^$section:/,/^[^[:space:]#]/p" "$config_file" | grep -qE "^[[:space:]]+$option:"; then | ||
| printf "\033[34m\n* $section.$option is already set in $config_file, skipping the update.\n\033[0m\n" | ||
| return |
There was a problem hiding this comment.
When a retained configuration already contains any of these keys with false (for example, compliance_config.enabled: false in datadog.yaml or direct_send_from_system_probe: false in system-probe.yaml), this presence-only check skips the requested update. Consequently, DD_NO_SECURITY_AGENT_INSTALL=true DD_COMPLIANCE_CONFIG_ENABLED=true can leave CSPM disabled or leave CWS sending through the security Agent, despite the migration option explicitly requesting that they run in system-probe. Update the existing value when it conflicts with the required true value rather than treating every pre-existing key as idempotent success.
Useful? React with 👍 / 👎.
❌ ErrorsYour PR has failed checks. Please review the issues below and take necessary action before merging. 🚦 1 Pipeline job failed
ℹ️ InfoNo other issues found (see more)🧪 All tests passed Useful? React with 👍 / 👎 This comment will be updated automatically if new data arrives.🔗 Commit SHA: b6b7b45 | Docs | View more details | Give us feedback! |
Adds
DD_NO_SECURITY_AGENT_INSTALL, to run CWS and CSPM in system-probe instead of the security agent.When it is set:
DD_RUNTIME_SECURITY_CONFIG_ENABLED=true→system-probe.yamlgetsruntime_security_config: {enabled: true, direct_send_from_system_probe: true}DD_COMPLIANCE_CONFIG_ENABLED=true→datadog.yamlgetscompliance_config: {enabled: true, run_in_system_probe: true}security-agent.yamlis never created. If it already exists, it gets bothruntime_security_config.direct_send_from_system_probeandcompliance_config.run_in_system_probe:the
datadog-agent-securityservice starts as soon as that file exists, so the security agentneeds to read those to know it has nothing to do and stop.
These settings are applied after the configuration files have been written, outside of the
"keeping old configuration file" block, otherwise nothing would happen when reinstalling over an
existing
datadog.yaml. Adatadog.yamlkept from a previous installation that has CSPM enabledalso gets
run_in_system_probe, so compliance doesn't silently stop running.Everything is idempotent: running the script again reports the options as already set and changes
nothing.
set_config_optiononly looks for an option inside its own section, since names likeenabledare used all over the configuration files.Also reported in the install telemetry as
no_security_agent.Test
Unit tests for the new functions, and a new
TestInstallNoSecurityAgentSuitee2e suite covering afresh install (picked up by the existing catch-all e2e jobs).
Manually, in a container: install with CWS + CSPM, uninstall, reinstall with
DD_NO_SECURITY_AGENT_INSTALL=true→ the three files get the expected settings, pass yamllint andkeep their ownership; a third run changes nothing.