Container runtime security exposes the limits of image-only controls

At a glance

What this is: This is an analysis of container runtime security, showing why live workload behavior and Kubernetes control-plane exposure matter more than image-only scanning once containers are deployed.

Why it matters: It matters because IAM, NHI, and platform teams must govern service accounts, tokens, and runtime privileges as active attack paths, not just as deployment-time configuration.

👉 Read Orca Security's guide to container runtime security and Kubernetes risk

Context

Container runtime security is the control layer that watches workloads after deployment, when process activity, file access, and network connections can diverge from what build-time checks predicted. In practice, that means the security problem is not whether the image looked clean last week, but whether the running container now has the ability to escape, steal credentials, or reach systems it should not.

For identity programmes, the issue is broader than container hardening. Service account tokens, cloud metadata credentials, Kubernetes RBAC, and host-level privileges all turn runtime behaviour into an identity problem as much as a platform problem. Teams that treat runtime as a purely infrastructure concern usually miss the blast-radius question: what can this workload do, right now, with the identity it has been given?

Key questions

Q: How should security teams reduce container runtime risk in Kubernetes environments?

A: Start by treating runtime privilege as an identity issue. Map service accounts, pod permissions, host access, and network reachability for each workload, then remove anything the application does not need. Runtime detections should be paired with admission controls and segmented networks so a compromise cannot immediately become cluster-wide movement.

Q: Why do containers create more risk at runtime than at build time?

A: Because build-time controls only validate the artifact, while runtime controls must govern what the workload actually does with live credentials and privileges. A container can be clean at deploy and still become dangerous if it can read secrets, spawn shells, or reach metadata services after startup.

Q: How do teams know whether runtime security is actually working?

A: Look for fewer unchecked privileged workloads, faster containment of suspicious processes, and alerts that are tied to real reachability rather than raw noise. If a runtime alert cannot tell you which identity, data store, or control-plane path is exposed, the programme is still immature.

Q: Who should own container runtime security outcomes?

A: It should be shared across developers, platform engineering, and security operations. Developers shape expected process behaviour, platform teams control cluster and node settings, and security teams tune detections and response. If any one group owns it alone, the runtime layer will keep gaps between code, configuration, and incident response.

Technical breakdown

Why runtime security is different from image scanning

Image scanning answers a narrow question: what vulnerabilities or misconfigurations were visible before deployment. Runtime security answers a different one: what the workload is actually doing after it starts, including syscalls, process trees, file access, and outbound connections. That distinction matters because many attacks do not rely on a new CVE. They abuse valid credentials, spawn shells, call unexpected tools, or exploit container isolation failures that only show up during execution. Runtime controls therefore combine prevention and detection, using kernel hooks, eBPF sensors, and policy enforcement to observe living behaviour rather than frozen artefacts.

Practical implication: keep image scanning for pre-deploy hygiene, but use runtime telemetry to catch live abuse that static checks cannot see.

Kubernetes runtime risk is a control-plane and identity problem

Kubernetes expands runtime risk beyond the container itself. The API server, etcd, RBAC bindings, admission policies, and pod security settings all shape whether a compromised workload can move laterally or reach metadata services and secrets stores. A pod with host networking, a mounted host path, or an over-broad service account can turn a single container issue into cluster-wide exposure. That is why runtime security in Kubernetes cannot be reduced to a node agent alone. The control plane and identity layer define the practical blast radius of every runtime alert.

Practical implication: review service accounts, RBAC, admission policies, and network segmentation together, not as separate teams' problems.

Behavioral analytics and graph context turn noise into incident priority

Behavioural analytics work by learning what normal looks like for a workload identity, then flagging deviations such as unexpected child processes, reverse shells, or unusual DNS patterns. On their own, those alerts can be noisy. The stronger model adds graph context, mapping pods, services, identities, and data stores so analysts can see whether a suspicious process can actually reach sensitive systems. That combination changes triage from 'something odd happened' to 'something odd happened with real path-to-data exposure'. It is the difference between a logged anomaly and an actionable incident.

Practical implication: tie runtime detections to identity and network path data so responders can prioritise real blast radius over raw alert volume.

Threat narrative

Attacker objective: The attacker wants to turn one running container into a durable position for credential abuse, host escape, or lateral movement across the cluster.

1. Entry occurs when an attacker reaches a container through a vulnerable workload, an exposed service, or stolen credentials that were valid at runtime.
2. Escalation follows when the container is used to abuse privileges, read secrets, spawn shells, or attempt escape to the host or other namespaces.
3. Impact appears when the workload is turned into a foothold for lateral movement, data access, cryptomining, or broader cluster compromise.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime security is now an identity governance problem, not just a detection problem. Containers do not fail safely when service accounts, metadata credentials, or cluster roles are over-scoped. The running workload becomes the executor of the identity, so governance has to ask what the workload can do at runtime, not merely what image was approved at build time. Practitioners should treat runtime blast radius as part of identity governance, not an afterthought.

Container escape and credential theft are the same governance failure seen from different angles. One path breaks isolation, the other abuses valid access, but both rely on the assumption that execution context is bounded enough to trust. That assumption fails in Kubernetes when host paths, privileged pods, or broad tokens are already present. The implication is that runtime policy, identity scope, and cluster segmentation have to be designed as one control surface.

Identity blast radius is the named concept this category keeps exposing. The article shows that a container is only as safe as the identities and network paths attached to it. When service accounts map directly to cloud roles, and when runtime access is broader than the application truly needs, one compromised process can become a multi-system incident. Practitioners should measure blast radius per workload identity, not per image.

Shared ownership is essential because runtime failures cross team boundaries. Developers influence process behaviour, platform teams shape node and cluster controls, and security teams interpret detections and containment. When any one of those groups assumes the others have covered the runtime layer, gaps appear in admission policy, alert tuning, or incident response. The result is not just slower detection, but slower containment.

Unified visibility changes prioritisation, but only if identity is part of the model. Correlating image findings with runtime events, service accounts, and network reachability helps teams rank what matters. That correlation becomes valuable when the organisation uses it to decide which workload can reach secrets, databases, or control-plane resources. Practitioners should centre identity-linked context in every runtime triage workflow.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.
• For the broader breach pattern, review The 52 NHI breaches Report for recurring identity-driven compromise patterns and control failures.

What this signals

Identity-linked runtime telemetry is becoming the difference between noise and containment. The next maturity step is not more alerts, but tighter correlation between workload identity, network reachability, and sensitive data paths. That is where runtime security starts to support IAM, NHI, and cloud operations as one programme instead of three disconnected queues.

Runtime programmes need to expect faster abuse of exposed credentials. When secrets or tokens reach production, the question is no longer whether they are well documented. The operational question is how quickly the environment can detect misuse and limit the blast radius before the workload completes lateral movement.

The governance model is shifting toward workload-centric review, where the unit of control is the running identity plus its network path, not the container image alone. Teams that still separate posture, identity, and runtime response will keep discovering problems after the attacker has already moved.

For practitioners

• Map workload identity to runtime reach Inventory which service accounts, metadata credentials, and cloud roles each workload can use, then verify what those identities can reach from the running container. This should include secrets stores, databases, and control-plane endpoints.
• Harden Kubernetes admission and pod security Block privileged pods, host namespaces, and unnecessary hostPath mounts by default, and require explicit exceptions with named owners and expiry dates. Pair admission policy with review of RBAC bindings so runtime privilege and identity scope stay aligned.
• Baseline workload behaviour before production Define expected process trees, outbound destinations, and file access patterns for each workload class before relying on runtime analytics. Batch jobs, APIs, and admin tools need different baselines, or the detections will be either noisy or blind.
• Connect runtime alerts to containment runbooks Ensure alerts can be acted on with steps for cordoning nodes, isolating pods, preserving process trees, and capturing evidence without breaking the cluster. The goal is to contain the workload before the attacker can complete lateral movement.

Key takeaways

• Container runtime security addresses the gap between a trusted image and untrusted behaviour in production.
• The highest-value controls are the ones that connect runtime alerts to identity scope, network reachability, and containment actions.
• Organisations that treat service accounts and pod privileges as runtime attack surfaces will reduce blast radius faster than teams focused only on image scanning.

Key terms

• Container Runtime Security: Container runtime security is the set of controls that monitor and limit what a container does after it starts running. It focuses on live process activity, file access, network behaviour, and privilege use, which is where many real attacks surface even when the image looked clean at deployment time.
• Runtime Blast Radius: Runtime blast radius is the amount of systems, data, and control paths a running workload can reach if it is compromised. In practice, it is shaped by service account scope, Kubernetes permissions, network segmentation, host access, and any secrets the workload can use at execution time.
• Behavioral Analytics: Behavioral analytics in runtime security means learning the normal patterns of a workload and flagging meaningful deviations. It is most useful when process trees, DNS requests, and outbound connections are evaluated in context, because a suspicious action only matters if the workload can actually act on it.
• Pod Security Admission: Pod Security Admission is a Kubernetes policy layer that restricts risky pod settings such as privilege escalation, host namespace access, and broad Linux capabilities. It is not a complete runtime control, but it helps prevent the kinds of configurations that make runtime compromise much easier to turn into impact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: Container runtime security guidance and best practices. Read the original.