What is Kubernetes runtime security?
Kubernetes runtime security protects containerized applications and infrastructure during the execution phase. Execution is a critical layer because container runtimes don’t provide the same level of isolation as hypervisors. While build-time security scans static images before deployment, runtime security monitors and defends against threats that emerge only when workloads are active. Static scanning fails to capture runtime configurations, active network connections, or real-time process behavior.
Runtime defenses detect unauthorized access attempts, identify anomalous process behavior, enforce network policies between pods, and protect against kernel-level exploits. Because containers are ephemeral and dynamic, traditional security built for static infrastructure often misses threats that only manifest at runtime. Industry frameworks emphasize securing the entire container lifecycle to mitigate these production risks, even when images pass initial checks.
Kubernetes Security Best Practices Cheat Sheet
Get actionable Kubernetes hardening guidance in a single reference.
Why runtime security matters for production Kubernetes
Build-time scanning creates a false sense of security because it can’t see production activity. Images passing CI/CD checks often adopt different configurations at runtime, and new vulnerabilities may surface after deployment, including the critical CVE-2019-5736. Attackers target running workloads to exploit live connections and active processes.
Production Kubernetes environments face specific runtime threats that static analysis can’t detect. Containers may drift from their declared state via configuration changes, while attackers with initial access attempt lateral movement between pods. Privilege escalation exploits target misconfigured RBAC or overly permissive security contexts. Without runtime visibility, these threats go unnoticed until a breach occurs.
The ephemeral nature of containers compounds the challenge, as pods spin up and terminate in seconds. Short-lived workloads make traditional security tools designed for long-lived servers ineffective. You need security controls that operate at the speed of container orchestration.
Leverage built-in Kubernetes security controls
Lock down what your workloads can do by default before adding more tooling. Kubernetes provides several built-in controls that reduce common runtime escape and privilege escalation paths.
Start with a strict pod security context and relax it only when you have a clear requirement.
Here’s an example of a hardened pod spec:
yaml apiVersion: v1 kind: Pod metadata: name: hardened-pod spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: app image: example/app:1.0 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - ALL
Linux ca
pabilities
Linux capabilities provide fine-grained privileges that containers inherit. Since most apps don’t need the default set, drop all capabilities first, and then add back only the ones the workload truly requires.
Here’s an example of configuring capability handling:
yaml securityContext: capabilities: drop: - ALL add: - NET_BIND_SERVICE
Seccomp profiles
Seccomp restricts the Linux system calls a container can make. The RuntimeDefault profile is a solid baseline because it blocks many high-risk syscalls—out of the over 300 available on Linux machines—without writing a custom profile.
Here’s an example of a seccomp configuration:
yaml securityContext: seccompProfile: type: RuntimeDefault
AppArmor and SELinux
AppArmor and SELinux provide mandatory access control at the OS level, restricting which files, network resources, and capabilities a process can access, even during a compromise. In Kubernetes, you’ll use these frameworks to constrain file access and the sensitive operations attackers rely on after they breach a container.
Your choice often depends on the underlying Linux distribution. Ubuntu defaults to AppArmor, which is generally easier to configure, while RHEL and CentOS rely on SELinux and offer more granular control. Since overly strict profiles can break legitimate behavior, always test in staging and apply them to your highest-risk workloads first.
Tools for Kubernetes runtime security
While native Kubernetes security controls provide foundational runtime protection, the open-source ecosystem offers specialized tools for deeper visibility, policy enforcement, and threat detection. Native mechanisms often require manual configuration and lack advanced detection capabilities. Open-source tools extend these native controls by automating scanning, enforcing policies, and providing real-time monitoring.
Each tool category addresses a specific layer of runtime security. Selecting the right combination depends on your threat model, compliance requirements, and operational maturity.
Misconfiguration and vulnerability scanning: kube-bench and Kubescape
kube-bench assesses Kubernetes cluster configurations against CIS Kubernetes Benchmarks. It checks control plane components like the API server, etcd, and controller manager for security misconfigurations, including disabled audit logging, weak authentication settings, or insecure TLS configurations.
Run kube-bench after cluster provisioning and before promoting configurations to production. The tool outputs pass/fail results for each benchmark check, simplifying the identification and remediation of configuration gaps.
Kubescape is a comprehensive tool for assessing the security posture of Kubernetes clusters. It scans for vulnerabilities, misconfigurations, and deviations from best practices to provide insights into potential security risks.
By integrating these tools into your Kubernetes security best practices, you build a more secure and resilient Kubernetes environment capable of tackling the challenges of the modern cloud infrastructure landscape.
Network security and service mesh: Calico
Calico provides robust network security capabilities within K8s environments. It implements network policies that control traffic flow between pods, segmenting the network and reducing the potential attack surface.
Policy management and enforcement: Open Policy Agent (OPA)
OPA provides a sophisticated declarative language for creating and implementing policies across a Kubernetes ecosystem. It integrates seamlessly with K8s, offering a unified toolset for managing security policies, admission control, and configuration validation.
Watch 12-min demo
See how Wiz connects container vulnerabilities, misconfigurations, and identity risk across your Kubernetes environments.
Real-time threat detection: Falco
Falco is an open-source project that provides real-time threat detection within Kubernetes environments. It monitors container runtime behavior at the kernel level, detecting anomalous activity and potential security threats in real time.
Best practices for Kubernetes runtime security
Combine the advanced tooling detailed above with these core, operational practices to harden your production environment.
Regularly scan for vulnerabilities and misconfigurations
Regular audits of your Kubernetes environment are essential for maintaining a secure posture. By scanning your Kubernetes clusters, control planes, data planes, and containers, you can uncover vulnerabilities and misconfigurations that threat actors could exploit.
Use Kubernetes audit logs, admission controllers, and tools like Kubescape to review actions in your clusters, identify potential security issues, and verify compliance with your security policies.
These audits reveal unauthorized access attempts, misconfigurations, and other security risks that require immediate attention.
Implement network policies for controlled access
Network policies control traffic flow between pods, but Kubernetes allows all pod-to-pod communication by default. This permissive default enables lateral movement if an attacker compromises a single container.
Start with a default-deny ingress policy for each namespace, then explicitly allow only the required traffic paths. Inverting the security model isolates new pods until you deliberately permit communication.
The following Calico network policy restricts inbound and outbound traffic for the "myapp" application, allowing communication only with specified trusted applications and external services:
yaml apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: restrict-traffic namespace: production spec: selector: app == "myapp" ingress: - action: Allow source: selector: app == "trustedapp" egress: - action: Allow destination: selector: app == "external-service"
Develop and enforce strong security policies
The foundation of Kubernetes runtime security lies in developing and enforcing comprehensive security policies. These should address access controls, resource limitations, network policies, and other components in your K8s ecosystem.
OPA plays a critical role in policy management within Kubernetes environments. By defining policies as code, you can automate the enforcement of security controls, making your security posture robust and scalable.
The following OPA policy ensures that only container images from a specified trusted registry can deploy, preventing unauthorized or potentially malicious images from running in your environment:
rego package kubernetes.admission deny[msg] { input.request.kind.kind == "Pod" not input.request.object.spec.containers[_].image.startsWith("trustedregistry/") msg = "Only images from trustedregistry/ are allowed." }
Utilize runtime monitoring and threat detection
Kubernetes operates in a dynamic environment, where continuous monitoring detects and responds to runtime security threats in real time. This level of monitoring immediately alerts you to unauthorized access attempts or other security concerns, enabling swift action to mitigate potential issues.
Integrating real-time threat-detection tools like Falco with your security incident response protocols allows you to automate responses to discovered threats, such as isolating affected pods or triggering alerts to security teams.
Manage container runtimes and images
Container runtime security is an essential aspect of Kubernetes runtime security. Securely configuring and updating your container runtime environment significantly reduces vulnerability risk. Scan container images for vulnerabilities before deployment, sign them to establish provenance, and verify them at runtime to ensure only trusted images run in your cluster.
This chain of trust prevents attackers from injecting malicious images into your registry or modifying images after they pass initial scans:
bash # Scan an image for vulnerabilities trivy image my-application:latest # Sign a container image (using Cosign) cosign sign -key cosign.key my-registry/my-application:latest # Verify a signed image (using Cosign) cosign verify -key cosign.pub my-registry/my-application:latest
Integrate these steps into your CI/CD pipeline so that unsigned or vulnerable images can’t reach production.
How Wiz secures Kubernetes runtime environments
Wiz solves the pain points of modern cloud security: alert fatigue, disconnected context, and visibility gaps.
By connecting container vulnerabilities to workload context, Wiz Security Graph identifies the toxic combinations of container vulnerabilities and misconfigurations that create real risk. This approach treats Kubernetes issues as part of the entire environment rather than isolated cluster findings.
Runtime context through unified visibility
Wiz scans containers, VMs, serverless functions, and appliances for vulnerabilities without requiring agents on each workload. Agentless scanning delivers complete coverage across multi-cloud environments, while the Wiz Cloud Sensor adds runtime context to identify which vulnerabilities threat actors can actively exploit in production.
Wiz discovers Kubernetes clusters, workloads, images, and configurations across all connected cloud accounts. The Security Graph correlates container risks with cloud infrastructure context, identity, and data exposure. Mapping these relationships shows how a vulnerable container with excessive IAM permissions and network exposure creates a higher-priority attack path than an identical vulnerability in an isolated workload.
Container attack path analysis
Every alert demands an immediate assessment of potential impact and lateral movement. Attack path analysis reveals if a compromised pod can pivot to higher-value targets, such as secrets, control-plane access, or sensitive data stores.
Consider a container with a critical CVE. If that workload also has direct internet exposure, excessive IAM permissions, and access to sensitive data, it poses a much higher risk than the same CVE in an isolated, least-privileged workload. The pod with the exposed service, elevated privileges, and service account capable of reading secrets across namespaces is the critical path to fix first, even if other findings have higher CVSS scores.
Wiz unifies container, Kubernetes, and cloud security within a single platform, giving security teams the context they need to prioritize runtime risks. Focusing remediation on actual attack paths rather than raw vulnerability counts reduces alert fatigue and speeds up your response to genuine threats. Correlating runtime signals with cloud configuration, identity, and data exposure ensures you don’t waste time on low-impact noise. Ready to see how unified context transforms your Kubernetes runtime security? Get a demo to experience attack path analysis across your container environments.
See Wiz in Action
Wiz unifies container vulnerability, identity, and exposure context so your team fixes the attack paths that matter.
