Notifications
Clear all
Topic starter
21/08/2026 4:48 pm
TL;DR: Kubernetes teams stall on hardening because they lack runtime evidence to write least-privilege policies safely, according to ARMO, and observe-to-enforce can shrink blast radius by basing enforcement on actual workload behavior rather than assumptions. The governance lesson is that policy quality depends on observation fidelity, especially where service accounts and workload access create identity-driven exposure.
NHIMG editorial — based on content published by ARMO: Observe-to-Enforce: How Progressive Security Policies Reduce Blast Radius
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Apply network policies from observed traffic Generate allowlists from documented runtime connections, then test them in audit mode before blocking anything.
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
👉 Read ARMO's analysis of observe-to-enforce Kubernetes blast-radius reduction →
Kubernetes blast radius: what observe-to-enforce changes for teams?
Explore further
21/08/2026 5:07 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Observe-to-enforce reduces Kubernetes blast radius without breaking prod
