Network configuration
This page covers the two network settings the chaos runner (DDCR) and the Discovery Agent expose on Kubernetes chaos infrastructure: mTLS for stronger client authentication on top of Harness token auth, and proxy (your own proxy or Harness Network Proxy) for outbound traffic from restricted clusters.
Before you begin
- Familiarity with Delegate mTLS. Go to Delegate mTLS support for the platform-level concepts.
- An installed Delegate (DDCR). Go to Set up Kubernetes infrastructure if you do not have one yet.
- Cluster-side TLS material. A client certificate and key, ideally stored in a Kubernetes secret on the cluster where the chaos runner executes.
How traffic flows
The chaos runner authenticates to Harness with a token by default. The Discovery Agent runs in the same cluster and uses the same outbound path.

- Inbound connections to the runner always come through the Delegate.
- Outbound calls go straight to the Harness control plane if the cluster has connectivity.
- If the cluster cannot reach the control plane directly, route outbound traffic through your own proxy or through Harness Network Proxy (HNP). Each is configured the same way: set
HTTP_PROXY,HTTPS_PROXY, andNO_PROXYon the Delegate and the Discovery Agent.
HNP supports custom certificates, so you can pin TLS material to the proxy rather than spread it across every target cluster.
Use mTLS with DDCR and the Discovery Agent
For both components, the configuration is the same: store the client cert and key in a Kubernetes secret in the cluster the component runs in, then point the component at that secret in the UI.
Configure mTLS on DDCR
-
Create a Kubernetes secret containing the client certificate and key on the target cluster.
-
Edit the Kubernetes chaos infrastructure and reference the secret in the mTLS fields.

If you do not want to provision a secret in every target cluster, install HNP with the cert and key, then point the chaos runner at the HNP URL instead.

Configure mTLS on the Discovery Agent
Same pattern. Create the secret on the cluster the Discovery Agent runs in, then reference it in the discovery agent settings under Resilience Testing → Project Settings → Discovery.

The HNP fallback applies here too.

Configure proxy settings
If the cluster cannot reach the Harness control plane directly, the chaos runner and Discovery Agent can be put behind a proxy. Either use a proxy you already operate, or install Harness Network Proxy (HNP).
Both components understand the standard environment variables:
HTTP_PROXYHTTPS_PROXYNO_PROXY(include the in-clusterkubernetesservice IP in thedefaultnamespace so intra-cluster traffic bypasses the proxy)
You can also set PROXY_URL directly on the component, which has the same effect for Harness-portal communication.
Set the proxy on DDCR
-
Go to Resilience Testing → Project Settings → Environments and pick the environment that hosts the Delegate.

-
Open the Delegate, click the ⋮ menu, and select Edit.

-
Set
HTTP_PROXY,HTTPS_PROXY,NO_PROXY(orPROXY_URL) and save.

Set the proxy on the Discovery Agent
-
Go to Resilience Testing → Project Settings → Discovery.

-
Open the discovery agent and click Edit.

-
Set the proxy environment variables (or
PROXY_URL) and save.

Install Harness Network Proxy (HNP)
HNP is an in-cluster proxy that consolidates outbound calls from the chaos runner and Discovery Agent. It can be deployed with or without mTLS.
helm repo add harness-chaos https://harness.github.io/chaos-infra-helm-chart
helm upgrade --install chaos-agent-proxy harness-chaos/chaos-infra \
-n hce -f override.yaml
Without mTLS
tags:
agentProxy: true
global:
serverAddress: https://app.harness.io
With mTLS
Create the client certificate first. Go to Enable mTLS on delegate.
tags:
agentProxy: true
global:
serverAddress: https://<customer-name>.agent.app.harness.io
agent-proxy:
volumes:
- name: client-certificate
secret:
secretName: client-certificate
volumeMounts:
- mountPath: /etc/mtls
name: client-certificate
readOnly: true
env:
- name: CLIENT_CERT_PATH
value: /etc/mtls/client.crt
- name: CLIENT_KEY_PATH
value: /etc/mtls/client.key
Replace <customer-name> with the subdomain assigned to your Harness account.
Next steps
- Set up Kubernetes infrastructure: install the Delegate-driven runner.
- Cluster permissions: review the Kubernetes RBAC the chaos service account needs.
- Delegate mTLS support: platform-level mTLS reference.