Observe-to-enforce reduces Kubernetes blast radius without breaking prod

At a glance

What this is: This is an analysis of how observe-to-enforce uses runtime behaviour to turn Kubernetes security policies from guesses into staged enforcement.

Why it matters: It matters because identity and access controls for workloads and service accounts can either contain compromise or silently widen blast radius across clusters.

By the numbers:

• 93% of organizations have at least one overly privileged service account.
• Only 5.7% of organizations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorized access and broadening the attack surface.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.

👉 Read ARMO's analysis of observe-to-enforce Kubernetes blast-radius reduction

Context

Kubernetes security often fails at the point where teams must enforce least privilege without enough evidence to know what normal workload behaviour looks like. In that environment, access control becomes a compromise between availability risk and security debt, and the gap quickly shows up in service accounts, network paths, and hidden dependencies.

Observe-to-enforce addresses that governance gap by using runtime data to build policies from actual connections, syscalls, and resource access. The identity angle is real here because workload permissions and service account scope determine how far a compromised pod can move, which makes this a workload identity problem as much as a network segmentation problem.

For teams already operating at scale, this is not a novel control so much as a better way to operationalise existing controls. The pattern is especially relevant where policy creation has stalled because developers and security teams cannot agree on what to block safely.

Key questions

Q: What breaks when Kubernetes policies are enforced without runtime evidence?

A: Policies written without runtime evidence often block legitimate traffic or leave dangerous paths open because they are based on assumptions, not actual workload behaviour. In Kubernetes, that usually means network policies, RBAC, and seccomp rules do not match how services really communicate, which increases both outage risk and lateral movement risk.

Q: Why do service accounts create blast-radius risk in Kubernetes?

A: Service accounts define what a pod can do once it is running, so excessive permissions can turn a single workload compromise into cluster-wide access or secret exposure. When those entitlements are broader than observed need, an attacker can use them to move laterally and reach systems the workload should never touch.

Q: How do teams know whether observe-to-enforce is working?

A: The clearest signal is that audit-mode violations decline while legitimate traffic continues normally and enforced policies closely match observed workload behaviour. Teams should also watch for fewer unnecessary permissions, narrower reachable service sets, and a lower rate of policy-related production issues after rollout.

Q: How should security teams roll out progressive enforcement in Kubernetes?

A: Start with high-risk workloads, observe behaviour across normal and batch cycles, and keep the first pass in audit mode. Then tighten network, syscall, and RBAC controls only after owners validate the exceptions. That sequence reduces breakage while steadily shrinking blast radius.

Technical breakdown

How runtime observation turns workload behaviour into policy

Observe-to-enforce starts by collecting runtime telemetry from workloads, usually via eBPF-based sensors. That telemetry captures outbound connections, inbound traffic, file access, system calls, and service account usage. The point is not simply visibility. It is to infer a trustworthy baseline for each workload so admission controls and network policies reflect actual behaviour rather than documentation that may be stale. In Kubernetes, this matters because the same service can behave differently across release cycles, batch windows, and namespaces. The architecture replaces guesswork with evidence, which is what makes least privilege operationally possible at scale.

Practical implication: build baselines from observed runtime behaviour before enforcing policies that could block legitimate traffic.

Why network policies, seccomp, and RBAC need behavioural data

Kubernetes security controls are only as accurate as the rules behind them. Network policies govern which pods can talk to which endpoints, seccomp constrains kernel-level system calls, and RBAC scopes what service accounts can do. None of those controls knows intent. If a workload is allowed to connect to every service or use broad permissions because no one mapped its real dependencies, the control becomes a formality. Behavioural data narrows the gap between declared configuration and actual use, which is why runtime discovery improves both segmentation and privilege scoping.

Practical implication: use runtime evidence to tighten network, syscall, and RBAC rules around observed workload needs.

What progressive enforcement changes about blast radius

Progressive enforcement reduces blast radius by applying controls first in audit mode, then to the riskiest workloads, and only later across the wider estate. That sequencing matters because it separates policy generation from policy enforcement. Instead of forcing a binary choice between open access and hard blocking, teams can validate what would break, adjust for legitimate edge cases, and then enforce with confidence. For Kubernetes, that means compromise of one pod no longer implies broad lateral movement or cluster-wide access. The method is especially useful when service accounts and inter-service traffic are the primary exposure paths.

Practical implication: stage enforcement in audit mode first, then expand only after violations are understood and tuned.

Threat narrative

Attacker objective: The attacker aims to expand from one compromised workload into broader cluster access, secrets exposure, and lateral movement across connected services.

1. Entry occurs when an attacker compromises a pod or workload that still has broad connectivity and over-scoped service account access.
2. Escalation follows if that workload can read unnecessary secrets, call undocumented services, or use cluster-wide permissions to expand access.
3. Impact is reduced or amplified depending on whether the compromised workload can move laterally across namespaces and reach sensitive systems.

NHI Mgmt Group analysis

Policy paralysis is a governance failure, not a tooling failure. Teams already have network policy, admission control, seccomp, and RBAC, but they often lack evidence for safe enforcement. That creates a backlog of controls that are technically available but operationally unusable. The lesson is that security architecture fails when proof of impact is missing, not when the control catalog is incomplete.

Workload identity is the hidden control plane in Kubernetes security. Service accounts, namespace scope, and secret access determine how far a compromised pod can travel. That is why workload behaviour and identity governance must be treated as one problem, not separate ones. The relevant discipline is to map runtime behaviour back to the entitlement model so cluster access is bounded by observed need.

Blast-radius reduction is the right objective for progressive enforcement. The article’s model is not about perfect prevention, but about making compromise materially less useful. That aligns well with NIST CSF and Zero Trust thinking, and it also surfaces a specific concept worth naming: evidence-based least privilege: policy that is generated from observed behaviour rather than assumed dependency graphs. Practitioners should treat this as an operating model, not a one-time hardening project.

Runtime-generated policy will increasingly shape how security teams negotiate with developers. If policies are derived from observed behaviour, the argument shifts from “will this break production?” to “what does production actually need?” That should reduce policy friction, but only if teams maintain continuous observation and governance around change. Otherwise the same drift returns in a new form.

This pattern validates a broader identity principle that NHIs cannot be secured by static assumptions alone. Workloads, service accounts, and ephemeral connections change too quickly for manual policy writing to keep up. The practical outcome is a stronger case for machine identity governance that is measured continuously, not reviewed sporadically.

What this signals

Evidence-based least privilege: Kubernetes teams are moving toward a model where policy is justified by observed workload behaviour rather than declared intent. That shift matters because service-account scope and network reach are identity decisions, not just platform settings, and they need continuous review as workloads change.

Runtime-first enforcement will make policy disagreements more concrete. Instead of debating theoretical breakage, teams can validate actual connections and permissions, then tighten controls around what the workload truly uses. For identity programmes, that means workload identity, secrets access, and access review must be managed as part of the same operational loop.

The long-term signal is that static entitlement models will keep drifting out of sync with production reality. As clusters become denser and more automated, organisations will need tighter links between runtime discovery, NHI governance, and the policies that govern how services talk and what they can reach.

For practitioners

• Instrument workloads before enforcing Deploy runtime sensors in a limited set of clusters and capture at least one to two deployment cycles before writing hard controls. Use the resulting data to identify real connections, syscalls, and secret access patterns.
• Scope service accounts to observed access Review service accounts that show cluster-wide or cross-namespace permissions and reduce them to the namespaces and resources actually used. Prioritise accounts attached to internet-facing or sensitive workloads.
• Apply network policies from observed traffic Generate allowlists from documented runtime connections, then test them in audit mode before blocking anything. Include internal services, external endpoints, and batch-job paths that only appear during non-standard cycles.
• Use seccomp to remove unused kernel capabilities Build seccomp profiles from observed syscall usage so containers cannot invoke kernel functions they never need. This reduces the impact of code execution inside a pod and narrows exploit options.
• Treat audit mode as the control gate Do not move a workload into enforcement until audit logs are clean, legitimate exceptions are understood, and application owners agree the policy reflects real behaviour. Progressive enforcement only works when policy drift is reviewed continuously.

Key takeaways

• Kubernetes hardening fails when teams cannot prove that least privilege will preserve production behaviour.
• Runtime observation changes the governance model by exposing actual workload connections, syscalls, and service-account access.
• Progressive enforcement reduces blast radius only when audit mode, scoped entitlements, and continuous drift review work together.

Key terms

• Observe-to-Enforce: A policy generation approach that starts by monitoring workload behaviour and then converts that behaviour into blocking rules. It is useful when teams need evidence-based policy, because audit mode can validate the controls before they are activated.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Application Profile DNA: A behavioural baseline built from what a workload actually does in production, including processes, network destinations, and system calls. It is used to derive least-privilege controls from evidence rather than from guessed or static entitlement models.
• Progressive Policy Enforcement: Progressive policy enforcement is an incremental control approach that applies broad restrictions first and then tightens rules as the organisation learns more about application dependencies. It is useful when perfect policy modelling would take too long, because it reduces exposure before the full design is complete.

What's in the full article

ARMO's full blog covers the operational detail this post intentionally leaves for the source:

• Runtime-generated network policy examples for Kubernetes services and namespaces
• Step-by-step audit-mode rollout guidance for progressive enforcement
• Measured overhead and rollout considerations for eBPF-based observation
• Operational examples of Application Profile DNA and anomaly detection

👉 The full ARMO post covers runtime policy generation, audit-mode rollout, and enforcement examples in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners translate identity controls into operational policy across modern environments.