### Release notes On GitLab Self-Managed instances that use a private or self-signed CA, GitLab Duo Agent Platform's sandboxed (SRT) execution environment does not propagate `NODE_EXTRA_CA_CERTS` and related TLS environment variables, causing sandboxed flows to fail certificate validation. This request asks for these variables to be forwarded into the sandboxed execution environment so custom CA trust works without disabling sandboxing. ### Problem to solve Self-managed customers running GitLab Duo Agent Platform foundational flows (including Duo Code Review) with a private/company CA or self-signed certificate chain hit certificate validation failures inside the sandboxed (SRT, privileged-mode) execution environment, even when `NODE_EXTRA_CA_CERTS` and related TLS variables are correctly set at the runner/job level (for example, in `config.toml` under `[[runners]]` or `[runners.docker]`). Symptoms include: - `unable to get local issuer certificate` - `UNABLE_TO_VERIFY_LEAF_SIGNATURE` - Duo CLI initialization logs showing `NODE_EXTRA_CA_CERTS: (not set)` even though the variable is set at the runner/job level. The only documented workaround (building a custom Docker image with the CA certificate baked into the system trust store and declaring `ENV NODE_EXTRA_CA_CERTS=...` in the Dockerfile) only works when the runner is not running in privileged/sandboxed mode. Once SRT sandboxing is enabled, the same custom image still fails to pick up the certificate. This is due to variables being un-set when the srt tool is started: ``` $ export GITLAB_WORKFLOW_SANDBOX=true $ unshare -m env -i DUO_WORKFLOW_ADDITIONAL_CONTEXT_CONTENT="$DUO_WORKFLOW_ADDITIONAL_CONTEXT_CONTENT" DUO_WORKFLOW_BASE_PATH="$DUO_WORKFLOW_BASE_PATH" DUO_WORKFLOW_DEFINITION="$DUO_WORKFLOW_DEFINITION" DUO_WORKFLOW_FLOW_CONFIG="$DUO_WORKFLOW_FLOW_CONFIG" DUO_WORKFLOW_FLOW_CONFIG_ID="$DUO_WORKFLOW_FLOW_CONFIG_ID" DUO_WORKFLOW_FLOW_CONFIG_SCHEMA_VERSION="$DUO_WORKFLOW_FLOW_CONFIG_SCHEMA_VERSION" DUO_WORKFLOW_FLOW_VERSION="$DUO_WORKFLOW_FLOW_VERSION" DUO_WORKFLOW_GOAL="$DUO_WORKFLOW_GOAL" DUO_WORKFLOW_SOURCE_BRANCH="$DUO_WORKFLOW_SOURCE_BRANCH" DUO_WORKFLOW_WORKFLOW_ID="$DUO_WORKFLOW_WORKFLOW_ID" DUO_WORKFLOW_SERVICE_SERVER="$DUO_WORKFLOW_SERVICE_SERVER" DUO_WORKFLOW_SERVICE_REALM="$DUO_WORKFLOW_SERVICE_REALM" DUO_WORKFLOW_GLOBAL_USER_ID="$DUO_WORKFLOW_GLOBAL_USER_ID" DUO_WORKFLOW_INSTANCE_ID="$DUO_WORKFLOW_INSTANCE_ID" DUO_WORKFLOW_INSECURE="$DUO_WORKFLOW_INSECURE" DUO_WORKFLOW_DEBUG="$DUO_WORKFLOW_DEBUG" LOG_LEVEL="$LOG_LEVEL" DUO_WORKFLOW_GIT_HTTP_BASE_URL="$DUO_WORKFLOW_GIT_HTTP_BASE_URL" DUO_WORKFLOW_GIT_HTTP_USER="$DUO_WORKFLOW_GIT_HTTP_USER" DUO_WORKFLOW_GIT_USER_EMAIL="$DUO_WORKFLOW_GIT_USER_EMAIL" DUO_WORKFLOW_GIT_USER_NAME="$DUO_WORKFLOW_GIT_USER_NAME" DUO_WORKFLOW_GIT_AUTHOR_EMAIL="$DUO_WORKFLOW_GIT_AUTHOR_EMAIL" DUO_WORKFLOW_GIT_AUTHOR_USER_NAME="$DUO_WORKFLOW_GIT_AUTHOR_USER_NAME" DUO_WORKFLOW_METADATA="$DUO_WORKFLOW_METADATA" DUO_WORKFLOW_PROJECT_ID="$DUO_WORKFLOW_PROJECT_ID" DUO_WORKFLOW_NAMESPACE_ID="$DUO_WORKFLOW_NAMESPACE_ID" GITLAB_BASE_URL="$GITLAB_BASE_URL" GITLAB_PROJECT_PATH="$GITLAB_PROJECT_PATH" AGENT_PLATFORM_GITLAB_VERSION="$AGENT_PLATFORM_GITLAB_VERSION" AGENT_PLATFORM_MODEL_METADATA="$AGENT_PLATFORM_MODEL_METADATA" AGENT_PLATFORM_FEATURE_SETTING_NAME="$AGENT_PLATFORM_FEATURE_SETTING_NAME" GITLAB_ENABLE_GLOBAL_SKILLS="$GITLAB_ENABLE_GLOBAL_SKILLS" GIT_TERMINAL_PROMPT="$GIT_TERMINAL_PROMPT" GIT_CONFIG_NOSYSTEM="$GIT_CONFIG_NOSYSTEM" GIT_CONFIG_GLOBAL="$GIT_CONFIG_GLOBAL" GIT_AUTHOR_NAME="$GIT_AUTHOR_NAME" GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" GIT_COMMITTER_NAME="$GIT_COMMITTER_NAME" GIT_COMMITTER_EMAIL="$GIT_COMMITTER_EMAIL" GIT_CONFIG_COUNT="$GIT_CONFIG_COUNT" GIT_CONFIG_KEY_0="$GIT_CONFIG_KEY_0" GIT_CONFIG_VALUE_0="$GIT_CONFIG_VALUE_0" GIT_CONFIG_KEY_1="$GIT_CONFIG_KEY_1" GIT_CONFIG_VALUE_1="$GIT_CONFIG_VALUE_1" GITLAB_OAUTH_TOKEN="$GITLAB_OAUTH_TOKEN" DUO_WORKFLOW_SERVICE_TOKEN="$DUO_WORKFLOW_SERVICE_TOKEN" DUO_WORKFLOW_GIT_HTTP_PASSWORD="$DUO_WORKFLOW_GIT_HTTP_PASSWORD" GITLAB_TOKEN="$GITLAB_TOKEN" GIT_PASSWORD="$GIT_PASSWORD" NPM_CONFIG_CACHE="$NPM_CONFIG_CACHE" GITLAB_LSP_STORAGE_DIR="$GITLAB_LSP_STORAGE_DIR" TMPDIR="$TMPDIR" PATH="$PATH" GITLAB_WORKFLOW_SANDBOX="$GITLAB_WORKFLOW_SANDBOX" srt --settings /var/tmp/.gitlab-sandbox/srt-settings.json duo run --existing-session-id 6 --connection-type websocket ``` **Steps to reproduce** 1. Create a GitLab instance with a self-signed certificate. 2. Set up a runner for the environment with privileged mode enabled (`privileged = true`) and the certificate added to the runner. 3. In the project's `.gitlab/duo/agent-config.yml`, set: ```yaml setup_script: - export NODE_EXTRA_CA_CERTS=path/to/cert.crt ``` 4. Run a GitLab Duo flow, such as the Duo Code Review flow. 5. Observe that the flow fails with an error such as: ``` 2026-07-02T15:42:51:891 [error]: Error: request to https://<instance_url>/api/v4/version failed, reason: self-signed certificate ``` 6. Re-run the same flow with the runner in unprivileged mode (`privileged = false`, sandboxing disabled) and observe that it completes successfully. ### Proposal Forward `NODE_EXTRA_CA_CERTS` (and ideally the related TLS/proxy variables — `NODE_TLS_REJECT_UNAUTHORIZED`, `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`) from the runner/job environment into the sandboxed (SRT) execution environment, so custom CA trust works for sandboxed Duo Agent Platform flows without requiring sandboxing to be disabled. Possible approaches: - Add `NODE_EXTRA_CA_CERTS` (and the other TLS/proxy variables listed above) to the explicit list of environment variables forwarded by the `env -i` invocation used to launch the sandboxed `srt`/Duo CLI process, rather than stripping them. - Alternatively (or additionally), provide a documented, supported mechanism — for example, a field in `agent-config.yml` — to explicitly inject these variables into the sandboxed environment, since the `setup_script` workaround for directory creation issues does not currently resolve this for TLS trust. - Update the existing knowledge article / troubleshooting documentation once a supported mechanism exists, since current guidance for the Duo Workflow Docker runner path does not account for the sandboxed case. ### Intended users * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) ### Does this feature require an audit event? No — this is an infrastructure-level environment propagation change internal to the sandboxed execution runtime, not a user-facing security control or permission change.