In a Kubernetes cluster with autoscaling, workload IP addresses change every time pods are rescheduled, and IP-based security rules keep breaking or matching the wrong workloads. How should the workload security policy be written instead?
Select an answer to reveal the explanation.
Short Explanation
Addressing mail to "whoever lives at the corner house" breaks the day they move. Attribute-based policy addresses the person — the label or tag — so the rule follows the workload wherever it lands. The trap is widening to the subnet; you stop the breakage by letting everybody in.
Full Explanation
In dynamic environments such as Kubernetes and autoscaling groups, IP addresses are ephemeral and say little about what a workload is. Attribute-based policy defines sources and destinations by labels, tags, namespaces, service accounts or other metadata, and the enforcement system resolves those attributes to the current set of workloads continuously. When a pod is rescheduled with a new address, its labels are unchanged, so it automatically inherits the correct rules and stops matching rules meant for something else. Reserving static addresses for every pod fights the orchestration model, wastes address space and breaks autoscaling, and it still ties security to a value that has no meaning about the workload. Widening rules to the entire cluster subnet removes the breakage only by allowing every workload in the cluster to match, which destroys segmentation and enables lateral movement. Weekly manual review cannot keep pace with changes that happen in seconds and leaves long windows of incorrect policy. Exam caveat: attributes must be governed, because anyone who can set a label can change which policy applies; restrict who can label workloads. Operational check: scale a deployment up and down, confirm new pods immediately receive the intended policy, and verify that a pod without the label cannot reach the protected service.