Discovered policies are generated from observed workload behavior, so they reflect how an application actually runs. Hardening policies are compliance or security guardrails that restrict behavior according to a required baseline. In practice, discovery helps teams understand normal operations, while hardening enforces the stricter controls needed to reduce attack surface and support governance.
Why This Matters for Security Teams
In Kubernetes runtime security, this distinction determines whether a policy is describing reality or enforcing restraint. Discovered policies are built from observed behaviour, so they are best for understanding what a workload actually needs before enforcement begins. Hardening policies are intentionally narrower, because they define what should be allowed according to a baseline, not what the workload happened to do during observation.
That difference matters operationally because teams often discover too late that a workload has been granted behaviour it does not truly need, or that a baseline blocks essential traffic that discovery never saw. For containerised environments, runtime controls should align with the broader container security guidance in NIST SP 800-190 Container Security, which treats image, orchestration and runtime protections as connected layers rather than isolated settings. Hardening is the enforcement layer; discovery is the calibration layer.
In practice, many security teams first learn the gap between the two only after a denied request or an exposed runtime path reveals that “normal” and “safe” are not the same thing.
How It Works in Practice
Discovered policies are usually generated by monitoring live workload activity over a period of time and extracting the permissions, network flows, file paths, process launches, or system calls that appear to be normal for that service. The result is a behaviour profile that helps reduce guesswork and exposes what the application actually depends on. That profile is valuable during assessment, tuning, and exception handling, especially in environments where operators do not have complete documentation.
Hardening policies are different because they start from a security objective. They may block interactive shell access, restrict outbound destinations, deny sensitive filesystem writes, or limit syscalls and capabilities that are unnecessary for the workload. In other words, discovery asks “what is this workload doing?”, while hardening asks “what should this workload be allowed to do?”.
- Use discovery to establish a baseline from observed production behaviour.
- Review the discovered policy for unexpected access, broad network reach, or unused permissions.
- Apply hardening rules where the security baseline needs to be stricter than observed behaviour.
- Expect exceptions when a workload has seasonal, batch, or failover behaviour that was not captured during the observation window.
This is why runtime policy management is usually iterative, not one-time: discovery reduces blind spots, while hardening reduces attack surface. Teams that rely on discovery alone often inherit whatever the workload already drifted into, and teams that harden too early can break valid application flows. A practical baseline approach is reinforced by CIS Benchmarks, which model hardening as a controlled baseline rather than an observational one. These controls tend to break down when workloads are highly dynamic or short-lived, because the observation window is too small to capture all legitimate runtime paths.
Common Variations and Edge Cases
Tighter hardening often increases operational overhead, so teams have to balance security gain against the risk of blocking legitimate workload behaviour. In practice, that tradeoff becomes sharper in Kubernetes because workloads can be ephemeral, scaled horizontally, or updated frequently, which makes a static baseline go stale quickly.
One common variation is to use discovered policies as a starting point and then manually remove unnecessary privileges before turning them into enforced hardening rules. Another is to keep discovery permanently enabled for visibility while only enforcing a subset of hardening controls in production. Current guidance suggests this is reasonable when application behaviour is still changing, but it should be paired with review discipline so that “temporary” exceptions do not become permanent drift.
Edge cases also appear with jobs, sidecars, and maintenance containers. A discovery policy may capture admin-style access during troubleshooting, but that does not mean such access belongs in the hardened runtime posture. The same is true for noisy applications that touch many files or open many connections during startup; those behaviours may be normal, but they are not automatically acceptable for long-term enforcement. For container operators, the practical rule is that discovery tells you what to validate, while hardening tells you what to constrain. The best outcome is a policy set that is narrow enough to reduce blast radius but flexible enough to survive real deployment patterns. Teams that cannot distinguish those two roles usually end up either over-permitting or endlessly whitelisting failures.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC — Access Control | Runtime policies govern what workloads may do in production. |
| PR.PS — Platform Security | Kubernetes runtime hardening is a platform security control. | |
| DE.CM — Continuous Monitoring | Discovery policies rely on observed workload behaviour and monitoring. | |
| Recommendation — Limit workload runtime permissions to the minimum required by policy. Apply hardened runtime baselines to reduce attack surface across clusters. Continuously monitor workload behaviour to keep discovered policies current. | ||
| CIS Controls v8 | 4 — Secure Configuration of Enterprise Assets and Software | Hardening policies enforce secure baseline behaviour in Kubernetes runtime. |
| 5 — Account Management | Runtime policy enforcement limits over-broad access paths and privileges. | |
| Recommendation — Define and enforce secure runtime baselines for containerised workloads. Review and remove unnecessary access paths before enforcing runtime policy. | ||
Practitioner Guidance
What to prioritise: Treat discovered policies as an input to review, not as an enforcement target. The first question is whether the observed behaviour is genuinely required for business function, because anything unnecessary should be removed before hardening is finalised.
What to verify: Confirm that the observation window covered normal peaks, failover paths, and routine maintenance activity. If it did not, the discovered policy may under-represent legitimate needs and create avoidable breakage when hardening is applied.
Decision rule: If a behaviour is only seen during troubleshooting or exceptional operator activity, keep it out of the hardened policy unless there is a formal production requirement for it. If the behaviour is part of the normal service path, document it before constraining it.
Practitioner takeaway: Discovery is about understanding workload reality, but hardening is about setting the minimum acceptable runtime posture, and the quality of the final policy depends on how carefully those two are separated.
Related resources from NHI Mgmt Group
- What is the difference between runtime detection and posture scanning for Kubernetes security?
- What is the difference between admission control and runtime security in Kubernetes?
- What is the difference between image scanning and runtime protection in Kubernetes security?
- What is the difference between prompt hardening and runtime AI security controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
