Kubernetes has become the de facto container orchestrator, and its adoption in production environments continues to grow rapidly. As the cloud-native ecosystem matures, securing every layer of the stack — from base images to running workloads — is no longer optional. The Cloud Native Computing Foundation (CNCF) has published findings from a formal security audit of Kubernetes, highlighting vulnerabilities and providing recommendations for both cluster administrators and developers.
Whether you are building a new cluster or hardening an existing one, the following ten questions provide a practical framework for identifying security gaps across your container and Kubernetes environment. Bring these to your DevOps and security teams as a starting checklist.
1. Are We Running the Latest Versions of Kubernetes and the Container Runtime?
The majority of exploited vulnerabilities are ones for which a patch already exists. Keeping Kubernetes, your container runtime (such as containerd or CRI-O), and any managed platform components up to date is one of the highest-impact actions you can take. The CNCF security audit identified a number of vulnerabilities in the Kubernetes codebase; subsequent releases addressed many of them. Establish a process to track release notes and apply updates promptly — ideally within a defined SLA based on the severity of disclosed CVEs.
2. Are There Images That Have Not Been Scanned Within a Defined Threshold?
An image that passed a vulnerability scan at build time may be exposed to newly disclosed CVEs days or weeks later. Define a maximum acceptable scan age (for example, seven days) and enforce it as a policy gate. Any image exceeding that threshold should trigger a rescan before it is permitted to run in production. This is especially important for zero-day vulnerabilities discovered after the initial scan. Integrate image scanning into your CI/CD pipeline and enforce it at the admission-control layer in Kubernetes.
3. Where Are Our Images Coming From — and Can We Verify Their Provenance?
Developers under delivery pressure will sometimes pull base images from public or unofficial registries that lack security controls. Every image used in production should originate from a registry that is trusted, access-controlled, and fully integrated with your vulnerability scanner. Enforce this through an admission controller or OPA/Gatekeeper policy that rejects pods referencing images from non-approved registries. Consider implementing image signing (for example, with Sigstore/Cosign) so that provenance and integrity can be cryptographically verified at deploy time.
4. Are There Pods Without Any Network Policies?
By default, Kubernetes allows unrestricted pod-to-pod communication across a cluster. A NetworkPolicy resource restricts which pods can communicate with a given pod, effectively isolating it. Any pod without an associated network policy can reach — and be reached by — every other pod in the namespace. In the event of a breach, this dramatically expands the blast radius. Audit your namespaces for pods that lack network policies and apply a default-deny ingress/egress rule as a baseline, then explicitly allow only the traffic that is required.
# Example: default-deny-all NetworkPolicy for a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-all
namespace: production
spec:
podSelector: {}
policyTypes:
- Ingress
- EgressCode language: PHP (php)5. Are There Permitted Network Paths That Are No Longer Needed?
Overly permissive network policies accumulate over time as services evolve. An allowed communication path that is no longer used still represents an attack surface. Periodically review your NetworkPolicy rules and cross-reference them with observed network flows (many CNI plugins and service meshes can expose this data). Remove any rules that permit traffic between services that no longer need to communicate. The principle of least privilege applies to network access just as much as it does to IAM.
6. Is Role-Based Access Control (RBAC) Actually Enforced?
Kubernetes RBAC is the primary mechanism for controlling who — and what — can interact with the Kubernetes API. Modern Kubernetes distributions enable RBAC by default, but clusters that were upgraded from older versions may still have the legacy Attribute-Based Access Control (ABAC) authorizer active alongside RBAC, which can undermine it. Verify that RBAC is enabled and that ABAC is disabled. Beyond that, audit your ClusterRoleBinding and RoleBinding objects for overly broad grants — particularly any binding that references the cluster-admin role or uses wildcard resource/verb permissions.
7. Are Any Containers Running With the Privileged Flag?
A container launched with securityContext.privileged: true receives all Linux capabilities and has the same access to the host kernel as a root process running directly on the node. If a privileged container is compromised, an attacker effectively has host-level access — including the ability to escape the container entirely. Audit running workloads for the privileged flag and remove it wherever it is not strictly necessary. For workloads that require elevated privileges, prefer granting only the specific Linux capabilities needed rather than enabling full privilege.
# Check for privileged containers across all namespaces
kubectl get pods --all-namespaces -o json \
| jq '.items[] | select(.spec.containers[].securityContext.privileged == true) \
| .metadata.namespace + "/" + .metadata.name'Code language: PHP (php)8. Are All Container Root Filesystems Mounted as Read-Only?
One of the key benefits of container-based deployments is immutable infrastructure: a container image represents a known, fixed state. Enforcing a read-only root filesystem (readOnlyRootFilesystem: true in the container’s security context) prevents an attacker who has gained code execution inside the container from writing malicious files, installing tools, or modifying application binaries at runtime. Applications that legitimately need to write data at runtime should use explicitly mounted volumes rather than writing to the root filesystem.
9. Are Any Containers Sharing the Host Network Namespace?
Setting hostNetwork: true in a pod spec causes the container to share the network namespace of the underlying node. This means the container can see and interact with all network interfaces on the host, including traffic to and from other pods that would otherwise be isolated. A compromised container running in the host network namespace can sniff traffic, bind to privileged ports, and interfere with node-level networking. Restrict hostNetwork usage with a Pod Security Admission policy or OPA/Gatekeeper constraint, allowing it only for specific, justified system-level workloads.
10. Can We Observe Which Processes Are Running Inside Containers Across All Clusters?
Runtime visibility is essential for threat detection. Knowing which processes are expected to run inside a container allows you to detect anomalies — for example, a shell spawned inside an application container, or a network-scanning tool executed post-compromise. Tools such as Falco, Sysdig Secure, and similar eBPF-based runtime security tools can monitor syscall activity and alert on unexpected process executions. Define a baseline of expected process behavior for each workload and treat deviations as security events that require investigation.
Putting It Together: A Security Assessment Checklist
- Kubernetes and container runtime versions are current and patched.
- All images are scanned on a defined schedule; stale scans block deployment.
- Images are only pulled from approved, scanner-integrated registries.
- Every pod has an associated
NetworkPolicy; namespaces default to deny-all. - Network policies are reviewed periodically and unused paths are removed.
- RBAC is enabled and enforced; ABAC is disabled; bindings follow least privilege.
- No production workload runs with
privileged: truewithout documented justification. - Container root filesystems are mounted read-only; writable volumes are explicit.
- Use of
hostNetwork: trueis restricted to approved system-level pods. - Runtime process visibility is in place and anomalous executions trigger alerts.
Security in a Kubernetes environment is not a one-time configuration exercise — it is an ongoing practice. Revisit these questions regularly as your cluster evolves, new workloads are deployed, and new CVEs are disclosed.
Original source: containerjournal.com