Configure multi-account routing for the New Relic eBPF agent

Important

Multi-account routing requires the nr-ebpf-agent Helm chart version 1.5.0 or higher. This feature is only available for Kubernetes deployments of the eBPF agent.

If your Kubernetes cluster hosts multiple teams or tenants, you can configure the New Relic eBPF agent to route telemetry to a different New Relic account based on the Kubernetes namespace a workload runs in. This lets each team's data land in its own account while a single eBPF agent daemonset covers the whole cluster.

How multi-account routing works

The eBPF agent daemonset reads a namespace-to-license-key map from a Kubernetes secret, injected as the NAMESPACE_LICENSE_KEY_MAP environment variable. You provide this map in one of two ways, and they're mutually exclusive:

namespaceLicenseKeys — Define the map directly in your values.yaml. The chart stores it in a secret it creates for you.
customSecretNamespaceLicenseKeys — Point to a Kubernetes secret you create and manage yourself, so license keys never appear in values.yaml or in source control.

Tip

If you set both namespaceLicenseKeys and customSecretNamespaceLicenseKeys, namespaceLicenseKeys takes precedence and the custom secret is ignored. Set only one.

For a given pod, the agent looks up the pod's namespace in the map:

If the namespace is a key in the map, telemetry from that namespace routes to the corresponding account.
If the namespace isn't in the map, telemetry falls back to the cluster's global licenseKey or customSecretName.

Configure multi-account routing

Choose one of the following options based on whether you want license keys inline in values.yaml or in a secret you manage separately.

Add a namespaceLicenseKeys map to your values.yaml, with one entry per namespace you want to route to its own account:

namespaceLicenseKeys:
  team-a: "NRAK-aaa..."
  team-b: "NRAK-bbb..."

Then apply the change:

bash

$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

Caution

This stores license keys directly in values.yaml. If you commit this file to source control, use the custom secret option instead.

Create a Kubernetes secret with a data key named exactly NAMESPACE_LICENSE_KEY_MAP, whose value is a JSON-encoded namespace-to-license-key map. The secret must live in the same namespace as the eBPF agent release.

apiVersion: v1
kind: Secret
metadata:
  name: my-nr-namespace-keys
  namespace: newrelic
type: Opaque
stringData:
  NAMESPACE_LICENSE_KEY_MAP: '{"team-a":"NRAK-aaa...","team-b":"NRAK-bbb..."}'

Then reference the secret in values.yaml, and leave namespaceLicenseKeys empty:

namespaceLicenseKeys: {}
customSecretNamespaceLicenseKeys: "my-nr-namespace-keys"

Apply the change:

bash

$helm upgrade --install nr-ebpf-agent newrelic/nr-ebpf-agent -n newrelic --values values.yaml

Important

The secret's data key must be exactly NAMESPACE_LICENSE_KEY_MAP — the chart doesn't rename it. The value must be valid JSON with double-quoted keys and values; a malformed map disables routing entirely (the agent treats it as empty).

Things to know

Create the custom secret in the same namespace as the eBPF agent release (for example, newrelic), not in the workload namespaces you're routing (such as team-a).
Don't set both namespaceLicenseKeys and customSecretNamespaceLicenseKeys. If both are non-empty, the inline map silently wins.
Namespaces that aren't listed in the map continue to use the cluster's global licenseKey or customSecretName. See K8s configuration parameters for details on those settings.

Configure multi-account routing for the New Relic eBPF agent

Important

How multi-account routing works .css-21sua1{background:none;border:none;width:0;padding:0;}

Tip

Configure multi-account routing

Caution

Important

Things to know

How multi-account routing works