What This Lab Tests
A Kubernetes controller maintains the desired workload. Replacing one of its pods does not remove an unchanged setting from the template that creates its successors.
This experiment measures that distinction with an isolated workload, then separately inspects Microsoft Defender for Cloud for the assessed resource and status. It accompanies the October 5, 2026 KSPM scope update, which moves affected misconfiguration recommendations from running container instances to deployments or top-level controllers.
Evidence Boundary
The October 7 live Kubernetes test produced four sanitized comparisons with capture timestamps and source hashes:
| Intervention | Observed result |
|---|---|
| Replace one of two pods | Same Deployment and active ReplicaSet; one new Pod UID; writable-root setting retained |
| Scale from two to four | Same Deployment and active ReplicaSet; two additional pods; writable-root setting retained |
| Set the template root filesystem to read-only | Same Deployment; new active ReplicaSet and four new ready pods; all carried the read-only setting |
| Replace one corrected pod | Same Deployment and active ReplicaSet; one new Pod UID; read-only setting retained across all four ready pods |
The image remained unchanged in each comparison. The pinned results directory contains all four artifacts. These measurements verify configuration propagation and readiness in a minimal pause workload, not application compatibility or filesystem write denial. No matching Defender KSPM assessment was observed in the bounded test window; finding stability, clearance time, and Secure Score effects remain unmeasured.
The two evidence layers remain separate:
| Evidence | Can establish | Cannot establish |
|---|---|---|
| Kubernetes object snapshots | Owner chain, pod/controller UIDs, template setting, replacement behavior, and resulting workload state | That Defender discovered or assessed the workload |
| Defender assessment export | The service’s actual recommendation, assessed resource, status, and observation time | Automatic clearance, universal rollout completion, or an unmeasured Secure Score effect |
| Source and offline checks | Validated artifact structure and checked code paths within their stated scope | Live deployment or product behavior |
Experiment Sequence
- Verify the explicitly selected lab subscription, cluster, namespace, and resource ownership.
- Deploy only the isolated workload supplied by the reviewed companion source.
- Capture the controller, its pod template, owner references, pod UIDs, and ready state.
- Replace an owned test pod and compare its successor with the baseline. Record a new UID even if a StatefulSet retains the same pod name.
- Change the chosen setting in the owning workload template, let the rollout complete, and inspect the resulting pods.
- Collect Defender evidence for the exact selected cluster and workload during a bounded observation window. Preserve an absent or pending assessment as an observation limit.
- Remove only recorded lab resources, verify cleanup, and document any retained resources or subscription-wide settings.
Prerequisites and Scope
Use a disposable Azure environment with sufficient AKS permissions, compatible kubectl, and the applicable Defender configuration for the capability being evaluated. The canonical runbook documents the tested AKS 1.35.8 configuration, required tools, exact commands, capture helpers, and cleanup. The deployment used two Azure Linux nodes in North Central US with an isolated namespace and no application ingress.
Cloud resources incur usage charges while retained. The experiment needs a stated spend allowance, observation deadline, and cleanup plan. A planning target is not an Azure-enforced spending cap. Subscription-wide Defender changes must be reviewed separately from workload creation.
This is a posture and resource-identity experiment. It does not require malware, an exploit, production secrets, host-path mounts, privileged containers, or broad Kubernetes access from the test workload.
Interpreting the Results
Pod replacement proves nothing about remediation unless the relevant configuration changed. Template remediation requires checking the new workload state and application health. Defender clearance additionally requires the service’s own subsequent assessment.
Do not infer a recommendation’s identity schema, exemption migration, ticket deduplication, or Secure Score calculation from a Kubernetes UID result. The article’s integration checks are questions for your actual exported findings.
Retain raw identifiers and unsanitized responses privately. Publish only reviewed aggregates, scoped field descriptions, and redacted images. Preserve the source revision and collection times so another reader can distinguish current results from historical screenshots.