# Check both Kubernetes collection controls before excluding a namespace

> Why can logs from an excluded namespace still reach Azure Monitor?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-497-check-both-kubernetes-collection-controls-before-excluding-a-namespace/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:23:39+00:00
- Modified: 2026-09-10T02:08:05+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

Why can logs from an excluded namespace still reach Azure Monitor?

## Potentially affected

Kubernetes clusters using Azure Monitor agent log collection with ConfigMap and data collection rule configuration.

## DSE recommendation

Specify namespace exclusion separately for container output and other collected logs, and verify both paths.

## Article

## Source facts

Azure Monitor’s Kubernetes namespace filters have different reach: the ConfigMap filters container output, while the data collection rule filters other logs. Completely excluding a namespace requires configuration in both places. Container output must also be enabled in both the ConfigMap and the DCR’s ContainerLogV2 stream; ConfigMap can independently disable stdout or stderr. These are complementary controls, not interchangeable copies of one setting. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-data-collection-configure).

## Applicability

Use this distinction only where ConfigMap-based Azure Monitor log collection is supported and in use. Identify whether the requirement excludes all namespace logs or only selected container output. Do not translate an output-only request into a broader loss of operational records.

## DSE recommendation

Specify namespace exclusion separately for container output and other collected logs, and verify both paths. Ask the workload owner to identify records that must remain available during an incident. Have the collection owner review the effective ConfigMap and associated log DCR together before approving the scope. Keep an explicit reason for any intentional difference between their namespace selections.

## Verification

In an authorized test namespace, produce recognizable stdout and stderr messages and an appropriate non-container log event. Check the expected destination for each record class after the proposed change. Record which classes should disappear and which should remain, then investigate any mismatch against the corresponding control. Preserve the before-and-after configuration with the observed results; a saved exclusion field alone is not the acceptance evidence.

## Official references

[Microsoft Learn: Kubernetes data collection customization](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-data-collection-configure). Source reviewed September 9, 2026.

## Primary reference

- Name: Filter and customize data collection for Kubernetes clusters - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-data-collection-configure
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Check both Kubernetes collection controls before excluding a namespace,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-497-check-both-kubernetes-collection-controls-before-excluding-a-namespace/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.