Cloud-Native Security Architecture: Why Your Kubernetes Clusters Are Probably Exposed

Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25, and they represent the single most impactful security control available in a Kubernetes cluster. Yet in our audits, only 31% of enterprise clusters had PSS enforcement enabled in any namespace beyond kube-system.

PSS defines three profiles — Privileged, Baseline, and Restricted — each enforced at the namespace level through the Pod Security Admission controller. The Privileged profile is essentially unrestricted and should only be used for system-level workloads that genuinely require elevated access. The Baseline profile prevents known privilege escalations, blocking host network access, host PID sharing, and privileged containers. The Restricted profile goes further, requiring non-root execution, read-only root filesystems, and dropping all capabilities.

Here is the problem: most organizations deploy their applications into namespaces with no PSS enforcement at all, which defaults to Privileged. That means any pod in those namespaces can run as root, mount host paths, access the host network, and effectively break out of its container isolation. We discovered a critical example of this in late 2025 when CVE-2025-4271 — a container runtime escape vulnerability — could only be exploited when containers ran with the SYS_PTRACE capability, a capability that the Baseline profile would have blocked.

By default, every pod in a Kubernetes cluster can communicate with every other pod. No network boundaries. No access controls. No segmentation. In a cluster running 500 services — which is typical for a mid-size enterprise deployment — that means 250,000 possible communication paths, the vast majority of which are unnecessary and should not exist.

Kubernetes NetworkPolicy resources provide basic L3/L4 segmentation by defining ingress and egress rules for pods. But here is the catch: NetworkPolicy is only enforced if your CNI plugin supports it. If you are running a CNI that does not implement NetworkPolicy — and some popular choices do not enforce them by default — your policies are syntactically valid but operationally meaningless. We have seen this exact scenario in 17% of our audits: organizations that had carefully crafted NetworkPolicy manifests deployed to their clusters, with a CNI that silently ignored every single one.

Even when NetworkPolicy enforcement is active, the standard Kubernetes NetworkPolicy API has significant limitations. It operates at L3/L4 only — you can restrict by IP and port, but you cannot write policies based on HTTP methods, paths, or headers. It does not support deny rules natively — policies are additive only, meaning you select pods and define allowed traffic, and everything not explicitly allowed is denied once any policy selects a pod. And it has no concept of policy ordering or priority, which makes complex rule sets difficult to reason about.

For enterprise deployments, we strongly recommend implementing a zero-trust network model using a policy engine that supports L7 filtering, DNS-based policies, and identity-aware network controls. Start with a default-deny posture for every namespace and explicitly whitelist only the communication paths each service requires. Yes, this is tedious. Yes, it requires mapping all service dependencies. But a flat network in a multi-tenant Kubernetes cluster is an invitation for lateral movement.

Role-Based Access Control is Kubernetes' authorization framework, and it is simultaneously powerful and dangerously easy to misconfigure. The most common anti-pattern we encounter is what I call cluster-admin sprawl: organizations that have liberally granted the cluster-admin ClusterRole to service accounts, CI/CD pipelines, and even individual developers because it was the fastest way to resolve permission errors.

In our audits, 28% of enterprise clusters had cluster-admin bound to at least one service account that did not require it. The cluster-admin role grants unrestricted access to every resource in every namespace — including the ability to create new RBAC bindings, read secrets, exec into pods, and modify webhook configurations. A compromised service account with cluster-admin access is functionally equivalent to root access on the entire cluster.

CVE-2025-3187, disclosed in September 2025, demonstrated this risk dramatically. A vulnerability in a popular monitoring operator allowed unauthenticated access to its API, which used a service account with cluster-admin privileges. Attackers could leverage this to read all secrets in the cluster, including database credentials, API keys, and TLS certificates. The monitoring operator genuinely needed broad read access for metrics collection, but it absolutely did not need write access or the ability to exec into pods.

Container image supply chain attacks have become one of the most significant threat vectors in cloud-native environments. The attack surface is enormous: the average enterprise Kubernetes deployment pulls from 847 unique container images, spanning official vendor images, open-source community images, and internally built images. Each of those images contains dozens or hundreds of software packages, any of which could harbor vulnerabilities or malicious code.

In January 2026, CVE-2026-0142 revealed a sophisticated supply chain attack where a widely used base image on a popular container registry was backdoored through a compromised maintainer account. The malicious image included a cryptominer that only activated after 72 hours of runtime, evading most CI/CD-time scanning tools. Over 14,000 organizations pulled the compromised image before it was detected. Organizations that relied solely on vulnerability scanning at build time — without runtime detection or image provenance verification — were exposed for an average of 11 days.

The fundamental problem is that most organizations treat container images as trusted artifacts once they pass a vulnerability scan. But a clean scan does not mean a safe image. Vulnerability databases have detection gaps. New vulnerabilities are disclosed daily. And sophisticated attackers can embed malicious behavior that no scanner will detect because it is not a known vulnerability — it is intentional backdoor code.

This should not need to be said in 2026, but Kubernetes Secrets are base64-encoded, not encrypted. By default, they are stored in etcd in plaintext. Anyone with read access to the etcd datastore — or to the Kubernetes API with the appropriate RBAC permissions — can read every secret in the cluster. I bring this up because 34% of the clusters we audit still do not have encryption at rest enabled for etcd, and 22% have overly permissive RBAC rules that allow broad secret read access.

The architectural answer is to never store sensitive credentials in Kubernetes Secrets at all. Use an external secrets manager — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager — and inject secrets into pods at runtime through a sidecar or init container. The Kubernetes Secret object should reference the external secret, not contain the actual credential.

Beyond storage, secrets rotation is a critical operational concern. Static credentials that never rotate are ticking time bombs. Our core infrastructure platform implements automatic credential rotation with zero-downtime rollover, ensuring that even if a credential is exfiltrated, its window of usefulness is limited to hours rather than months. We recommend a maximum credential lifetime of 24 hours for database credentials and 1 hour for API tokens in high-sensitivity environments.

Vulnerability scanning and policy enforcement are preventive controls. They are necessary but insufficient. You also need detective controls that identify malicious behavior at runtime — after a workload is deployed and running. This is the layer that catches zero-day exploits, compromised dependencies, and insider threats that no amount of scanning will prevent.

Runtime detection in Kubernetes environments works by establishing behavioral baselines for each workload and alerting on deviations. A web server that suddenly spawns a shell process is anomalous. A database pod that initiates outbound connections to an unknown IP is suspicious. A batch processing container that starts reading /etc/shadow is almost certainly compromised.

The challenge is signal-to-noise ratio. A naive runtime detection deployment in an enterprise cluster will generate thousands of alerts per day, most of them false positives triggered by legitimate but unusual operations — deployments, debugging sessions, cron jobs. The key is workload profiling: learning the normal behavior of each workload during a baseline period and tuning detection rules to the specific characteristics of each service.

Our platform uses eBPF-based sensors that attach to the Linux kernel to observe system calls, network connections, and file access patterns without requiring any modification to the monitored workloads. After a 7-day baseline period, the detection engine can identify anomalous behavior with a false positive rate under 0.3%. When a genuine threat is detected, automated response policies can isolate the affected pod, capture forensic data, and alert the security team — all within 200 milliseconds of detection.

Service meshes like Istio, Linkerd, and Cilium Service Mesh are frequently deployed as the answer to service-to-service security. And they do provide significant value — automatic mTLS between services, L7 traffic policies, and observability into service communication patterns. But a service mesh is not a silver bullet, and there are several common misconfigurations that undermine its security guarantees.

The most dangerous is permissive mTLS mode. When a service mesh is configured in permissive mode, it accepts both mTLS and plaintext connections. This is intended as a migration aid — allowing services to gradually adopt mTLS — but in practice, organizations deploy in permissive mode and never switch to strict. Forty-six percent of the mesh deployments we audit are still in permissive mode, which means an attacker who compromises a pod outside the mesh can communicate with meshed services without any authentication.

The second common issue is inadequate authorization policies. mTLS ensures that service A is who it claims to be, but it does not control what service A is allowed to do. Without explicit authorization policies, any service in the mesh can communicate with any other service. This is the L7 equivalent of a flat network, and it is just as dangerous. You need both authentication (mTLS) and authorization (policies that define which services can call which endpoints with which HTTP methods) to achieve meaningful zero-trust at the service layer.

For organizations looking to implement a comprehensive zero-trust posture at the network and service layer, our Zero-Trust Migration Playbook provides a phased approach that includes service mesh deployment as part of the Phase 2 microsegmentation work.

Security is a journey, not a destination. But if I had to prioritize the most impactful changes you can make to your Kubernetes security posture in the next 30 days, here is what I would focus on. These are ordered by impact-to-effort ratio — the first items give you the biggest security improvement for the least disruption.

Kubernetes security is not a single problem with a single solution. It is a layered discipline that requires attention at every level — from the container runtime to the application layer, from build-time scanning to runtime detection, from network policies to RBAC. The good news is that the Kubernetes ecosystem has matured significantly, and the tools to build a genuinely secure cluster exist today. The bad news is that those tools require deliberate configuration and ongoing operational attention.

If there is one takeaway from this article, let it be this: default Kubernetes configurations are optimized for developer convenience, not security. Every default is a decision you did not make, and in security, unmade decisions are vulnerabilities. Audit your defaults. Question your assumptions. And treat your Kubernetes cluster with the same security rigor you would apply to any other production infrastructure — because that is exactly what it is.