Privileged vs. unprivileged mode

The New Relic Kubernetes integration runs in privileged mode by default. This enables the Infrastructure Agent to directly access the underlying host's information.

While this provides the most complete telemetry, some security policies (such as Pod Security Standards or OpenShift SCCs) may require you to run workloads in unprivileged mode.

Why privileged mode is required

The New Relic Infrastructure Agent is included in the Kubelet pod and requires low-level access to the node's operating system to collect deep system metrics.

The default value for privileged in the common library is false. However, this chart sets it to true by default (see values.yaml) to ensure the agent can:

Read the host's /proc and /sys filesystems.
Collect accurate CPU, memory, storage, and network statistics for the underlying host.
Gather full process lists and metadata that correlate infrastructure health with your Kubernetes objects.

Running in unprivileged mode

If your cluster security policy doesn't allow privileged in your pods' security context, you can disable it by setting privileged to false.

Impact on data collection

Important

Disabling privileged mode will result in the loss of host-level metrics and metadata. Host entities won't be created in New Relic.

In unprivileged mode, the Infrastructure Agent can't see the host's resource usage and host entities won't be created. You'll lose access to the standard host metrics, including:

SystemSample: Host-level CPU, memory, and load averages.
StorageSample: Disk usage and I/O for the node's filesystem.
NetworkSample: Physical network interface statistics.
ProcessSample: Data on processes running outside the New Relic container.

For a detailed list of exactly which attributes and metrics are unavailable in unprivileged mode, see the Linux agent running modes documentation.

How to configure it

Update your custom values file to set the global privileged flag to false:

global:
  privileged: false

Windows nodes

Windows nodes support both privileged and unprivileged modes. Unlike Linux, where privileged mode operates via the container security context, Windows privileged mode uses HostProcess containers — the Windows-native mechanism for granting a container direct access to host resources.

What are HostProcess containers?

When you deploy with windows.privileged=true (the default for Windows nodes), the monitoring containers run as Windows HostProcess containers. This is a fundamentally different execution model from standard Windows container isolation:

The container's processes run directly in the Windows host OS process space — they are visible in Task Manager on the node, not isolated in a container namespace.
hostNetwork: true is automatically applied, giving the process access to all network interfaces on the node.
The container has access to the host filesystem and registry.
It runs as NT AUTHORITY\Local Service, a built-in Windows account with limited local privileges but the ability to authenticate to network resources as the computer account.

HostProcess mode is required to collect host metrics — CPU, memory, disk, and network interfaces — from the Windows node itself.

Unprivileged mode for Windows

When you set windows.privileged=false, containers run as standard ContainerUser without host network access. The agent operates in forward-only mode — it forwards data from the kubelet integration scraper but doesn't directly access host resources. Node-level samples (SystemSample, StorageSample, NetworkSample) aren't collected in this mode.

Many node-related metrics are still available in unprivileged mode via the K8sNodeSample event. For the full list of metrics unavailable in unprivileged mode, see Limitations to the Kubernetes integration for Windows.

Security considerations for Windows privileged mode

Because HostProcess containers run with direct access to the host OS, New Relic recommends the following practices when using windows.privileged=true:

Enable fine-grained kubelet authorization to restrict RBAC to the specific read-only endpoints the integration uses, rather than the broader nodes/proxy subresource. This requires Kubernetes 1.32+ with the KubeletFineGrainedAuthz feature gate.

In the newrelic-infrastructure Helm chart:

rbac:
  kubeletFineGrainedAuth: true

Store the license key as a Kubernetes Secret rather than embedding it in values.yaml or passing it via --set, where it would be visible in shell history and helm get values:
bash
```
$kubectl create secret generic newrelic-license \
>  --namespace newrelic \
>  --from-literal=licenseKey=<YOUR_KEY>
```
```
global:
  customSecretName: newrelic-license
  customSecretLicenseKey: licenseKey
```
Pin the DaemonSet to designated nodes using kubelet.windowsNodeSelector. If your cluster has Windows nodes with different workload classifications, you can restrict monitoring to only those nodes you intend to monitor.
Enforce network egress at the node level using Windows Defender Firewall rules or a proxy. Kubernetes NetworkPolicy objects don't apply to HostProcess pods because hostNetwork: true bypasses pod networking entirely. Note that NetworkPolicy enforcement also depends on your CNI plugin — not all CNI plugins enforce network policies by default. If you are relying on NetworkPolicy for egress control elsewhere in your cluster, verify that enforcement is actually active before depending on it. If you use a proxy:
```
global:
  proxy: "http://your-proxy:3128"
```
Set resource limits to protect node stability, since HostProcess containers compete for node resources directly. The chart sets a memory limit by default — you may keep this or set your own:
```
kubelet:
  windows:
    agent:
      resources:
        limits:
          memory: 300Mi
```
A CPU limit is not set by default. For a monitoring agent, a hard CPU cap risks missing scrape intervals under node load. If your cluster policy requires one, weigh that tradeoff before setting it.
Run the monitoring stack in a dedicated namespace and restrict who can create or modify resources in it. Because HostProcess pods run with direct host access, lateral access to this namespace should be treated as equivalent to node access.
Ensure your existing Windows security monitoring covers these nodes. HostProcess container processes run directly in the host OS process space and are visible to the host like any other process. They appear in Get-Process output and, with process creation auditing enabled, in Security log events 4688 (process creation) and 4689 (process exit).
The identifiable signal for a HostProcess container launch in the Security log is containerd-shim-runhcs-v1.exe as the Creator Process spawning cmd.exe as NT AUTHORITY\Local Service, followed by the agent processes (newrelic-infra.exe and nri-kubernetes) further down the chain.
Note that process creation auditing is disabled by default on Windows and requires Administrator or SYSTEM privileges to enable and to read the Security log - it can't be configured from within the New Relic container itself. If your organization uses a SIEM, Windows Event Forwarding, or an EDR tool to collect event logs from Windows hosts, make sure that coverage extends to your Kubernetes Windows nodes.