Merge pull request #23732 from newrelic/Daily-merge/04-14-26/night

Daily merge/04 14 26/night

Author: PallaviWrite

src/content/docs/apm/agents/net-agent/getting-started/net-agent-compatibility-requirements.mdx

@@ -216,7 +216,8 @@ Want to try out our .NET agent? [Create a New Relic account](https://newrelic.co
                     * Windows Server 2025
                     * Windows 10
                     * Windows 11
-                    * Windows containers running on Server 2016 (NanoServer based images are not supported)
+
+                    Containerized versions of these operating systems are also supported, with the exception of `nanoserver`.
                 </td>
                 </tr>
 
@@ -226,7 +227,7 @@ Want to try out our .NET agent? [Create a New Relic account](https://newrelic.co
                 </td>
 
                 <td>
-                    All x64 Linux distributions supported by the .NET Core 2.0+/.NET 5+ runtime are supported by the .NET agent. For a full list, refer to Microsoft's documentation for the version of the runtime you are using.
+                    All x64 Linux distributions supported by the .NET Core 2.0+/.NET 5+ runtime are supported by the .NET agent (including containerized versions). For a full list, refer to [Microsoft's documentation](https://learn.microsoft.com/en-us/dotnet/core/install/linux) for the version of the runtime you are using.
                 </td>
                 </tr>
 
@@ -236,7 +237,7 @@ Want to try out our .NET agent? [Create a New Relic account](https://newrelic.co
                 </td>
 
                 <td>
-                    All ARM64 Linux distributions supported by the .NET 5+ runtime are supported by the .NET agent, with the following known exceptions:
+                    All ARM64 Linux distributions supported by the .NET 5+ runtime are supported by the .NET agent (including containerized versions), with the following known exceptions:
                     * Alpine Linux
                 </td>
                 </tr>
@@ -1229,7 +1230,8 @@ Want to try out our .NET agent? [Create a New Relic account](https://newrelic.co
                 * Windows 10
                 * Windows 11
                 * Windows Azure (OS Family 1, 2, and 3)
-                * Windows containers running on Windows 2016 (NanoServer based images are not supported)
+
+                The agent supports running in containerized versions of all supported Windows operating systems with the known exception of `nanoserver`.
             </Collapser>
             <Collapser
                 className="freq-link"

src/content/docs/infrastructure/host-integrations/host-integrations-list/oracle-database-monitoring-integration.mdx

@@ -177,7 +177,7 @@ In the Oracle database, execute the following statements to create a new user an
    To collect PDB metrics, grant `gv$con_sysmetric` privileges by running:
 
    ```
-   GRANT SELECT ON gv$con_sysmetric TO USERNAME;
+   GRANT SELECT ON gv_$con_sysmetric TO USERNAME;
    ```
 
 ### Configure the integration [#config]

src/content/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-privileged-mode.mdx

@@ -5,38 +5,38 @@ template: 'GuideTemplate'
 freshnessValidatedDate: never
 ---
 
-The New Relic Kubernetes integration runs in **privileged mode** by default, enabling the Infrastructure Agent (running as a DaemonSet sidecar) to directly access the underlying host's information.
+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.
 
-Although the default value for `privileged` in the [common library](https://github.com/newrelic/helm-charts/blob/master/library/common-library/README.md) is `false`, 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:
+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 does not allow `privileged` in your pods' security context, you can disable it by setting `privileged` to `false`.
+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
 
 <Callout variant="important">
-  Disabling privileged mode will result in the loss of **host-level metrics** and metadata.
+  Disabling privileged mode will result in the loss of **host-level metrics** and metadata. Host entities won't be created in New Relic.
 </Callout>
 
-When unprivileged, the Infrastructure Agent cannot see the host's resource usage. You will lose access to the standard host metrics, including:
+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, please refer to the [Linux agent running modes documentation](/docs/infrastructure/infrastructure-agent/linux-installation/linux-agent-running-modes/#mode-metrics).
+For a detailed list of exactly which attributes and metrics are unavailable in unprivileged mode, see the [Linux agent running modes documentation](/docs/infrastructure/infrastructure-agent/linux-installation/linux-agent-running-modes/#mode-metrics).
 
 ### How to configure it
 
@@ -47,8 +47,80 @@ global:
   privileged: false
 ```
 
-### Windows in unprivileged mode
+### Windows nodes
 
-Standard Windows containers cannot directly access host infrastructure due to container isolation. HostProcess containers could provide this access but introduce additional security risks and are not currently used by the New Relic Kubernetes integration. Therefore, Windows DaemonSets run only in unprivileged mode; privileged mode is not supported for 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.
 
-For more details on what metrics are collected in this mode, see [Limitations to the Kubernetes integration for Windows](/docs/kubernetes-pixie/kubernetes-integration/troubleshooting/troubleshooting-windows/#k8-windows-limitations).
+#### 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](/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=<YOUR_KEY>
+  ```
+
+  ```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.

src/content/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-version2/kubernetes-windows.mdx

@@ -11,14 +11,14 @@ redirects:
 freshnessValidatedDate: 2025-07-01
 ---
 
-<Callout title="important">
-  With the release of Windows Support for the New Relic Kubernetes Integration v3, it is not recommended to use the installation guidelines listed here. Please follow the [Kubernetes integration installation guide](/install/kubernetes) for the latest instructions.
+<Callout variant="important">
+  **Windows node monitoring is now generally available (GA) in New Relic Kubernetes integration v3.** The v2 installation approach described on this page is deprecated and will be removed in a future release. Use the [Kubernetes integration installation guide](/install/kubernetes) for current installation instructions, which support Windows nodes natively.
 </Callout>
 
 
-Use this option when you've a Windows-based Kubernetes system. Note that Windows integration has several [limitations](#k8-windows-limitations).
+Use this option when you have a Windows-based Kubernetes system. Note that Windows integration has several [limitations](#k8-windows-limitations).
 
-## Compatibility and requirements [#compability-requirements]
+## Compatibility and requirements [#compatibility-requirements]
 
 Before you install the [Kubernetes integration](/docs/integrations/kubernetes-integration/get-started/introduction-kubernetes-integration), review the [compatibility and requirements](/docs/integrations/kubernetes-integration/get-started/kubernetes-integration-compatibility-requirements).
 
@@ -152,7 +152,7 @@ For a useful mapping between release IDs and OS versions, see [here](https://hub
 
 The Windows agent only sends the [Kubernetes samples](/docs/kubernetes-pixie/kubernetes-integration/understand-use-data/find-use-your-kubernetes-data/#event-types), such as `K8sNodeSample` or `K8sPodSample`. These limitations apply to the Kubernetes integration for Windows:
 
-* `SystemSample`, `StorageSample`, `NetworkSample`, and `ProcessSample` are not generated.
+* `SystemSample`, `StorageSample`, `NetworkSample`, and `ProcessSample` aren't generated.
 * Some [Kubernetes metrics](/docs/integrations/kubernetes-integration/understand-use-data/understand-use-data#metrics) are missing because the Windows kubelet doesn't have them:
   * Node:
     * `fsInodes`: not sent

src/content/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-version2/windows-linux-hybrid-cluster.mdx

@@ -12,8 +12,7 @@ freshnessValidatedDate: 2025-07-01
 ---
 
 <Callout variant="important">
-  The New Relic Kubernetes integration v3 now supports monitoring Windows nodes with the new [`nri-kubernetes` v3 architecture](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-version2/changes-since-v3/). 
-  To enable monitoring for your Windows nodes, use the [guided install process.](/install/kubernetes/) This process supports both Linux and Windows nodes, allowing hybrid cluster installations by default.
+  **Windows node monitoring is now generally available (GA) in New Relic Kubernetes integration v3.** The hybrid installation approach described on this page (using a separate `newrelic-infrastructure` v2 chart for Windows) is deprecated and will be removed in a future release. Use the [guided install process](/install/kubernetes/) instead — it supports both Linux and Windows nodes in a single installation by default.
 </Callout>
 
 This document explains how to install the Kubernetes integration for a hybrid cluster. The instrumentation process installs the `nri-bundle` chart on the Linux nodes and then creates a `newrelic-logging` sub-chart. This sub-chart enables the integration to run on both Windows and Linux nodes.
@@ -86,7 +85,7 @@ To use this integration, you should:
 
     Here are some important things to keep in mind:
 
-    * Other subcharts may exist in `nri-bundle` that are not represented in this file. If you'd like to add those subcharts, then add their key or value pairs to your yaml file.
+    * Other subcharts may exist in `nri-bundle` that aren't represented in this file. If you'd like to add those subcharts, then add their key or value pairs to your yaml file.
     * The `newrelic/nri-bundle` chart contains the latest updates for Linux-based nodes.
     * You can also configure the `newrelic-logging` chart during this step to install to both Linux and Windows nodes.
     * You must configure a `NodeSelector` to avoid scheduling to Windows. If an installation fails on a mixed cluster using default values from guided install, add the `nodeSelector` values.

src/content/docs/kubernetes-pixie/kubernetes-integration/get-started/kubernetes-integration-compatibility-requirements.mdx

@@ -43,14 +43,15 @@ If custom manifests have been used instead of Helm, you will need to first remov
 
 ### Compatibility and requirements for Windows [#req-windows]
 
-<Callout title="preview">
+To monitor Windows nodes with the New Relic Kubernetes integration, your environment must meet the following requirements.
 
-  We're still working on this feature, but we'd love for you to try it out!
+Windows monitoring supports two modes: 
 
-  This feature is currently provided as part of a preview program pursuant to our [pre-release policies](/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy). Check the [Kubernetes integration installation guide](/install/kubernetes) for the latest instructions.
-</Callout>
+* **Privileged mode**, which uses Windows HostProcess containers to collect full node-level metrics. The privileged mode is enabled by default.
+* **Unprivileged mode**, which runs as a standard container user with reduced host visibility.  
+
+For details on how these modes work and guidance on configuring them securely, see [Privileged vs. unprivileged mode](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-privileged-mode). For complete setup instructions, see [Monitor Windows nodes](/docs/kubernetes-pixie/kubernetes-integration/installation/windows).
 
-To monitor Windows nodes with the New Relic Kubernetes integration, your environment must meet the following requirements.
 
 ## Privileged mode requirements
 
@@ -73,6 +74,7 @@ Due to limitations in cloud provider offerings and Kubernetes itself, several ke
 * Windows nodes running in Red Hat OpenShift clusters.
 * Amazon EKS Fargate clusters, as Fargate supports only Linux nodes.
 * Google GKE Autopilot clusters, as Autopilot supports only Linux nodes.
+* Windows privileged mode on Google GKE clusters, as GKE doesn't support Windows `HostProcess` containers. You can still monitor Windows nodes on GKE in [unprivileged mode](/docs/kubernetes-pixie/kubernetes-integration/advanced-configuration/k8s-privileged-mode/#windows-nodes).
 
 ## Container runtime [#containers]