--- title: Privileged vs. unprivileged mode source: https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-privileged-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](https://github.com/newrelic/helm-charts/blob/master/library/common-library/README.md) is `false`. However, this chart sets it to `true` by default (see [`values.yaml`](https://github.com/newrelic/helm-charts/blob/master/charts/nri-bundle/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](https://docs.newrelic.com/docs/infrastructure/infrastructure-agent/linux-installation/linux-agent-running-modes/#mode-metrics). ### How to configure it Update your custom values file to set the global privileged flag to `false`: ```yaml 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](https://docs.newrelic.com/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/troubleshooting-windows/#k8-windows-limitations). #### 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: ```yaml 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= ``` ```yaml 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: ```yaml 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: ```yaml 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.