When you unbox a new smartphone, it’s designed to be frictionless. The screen is bright, the volume is up, and the apps are ready to connect. Manufacturers prioritize "time to value"—they want you loving the device in seconds, not fumbling with settings.
Kubernetes and cloud-native tools follow a similar philosophy. They are engineered for adoption. When you spin up a cluster, the default settings are calibrated to ensure your applications run immediately. Pods can talk to each other, storage is accessible, and APIs are open for business. The friction is removed so you can build faster.
But in the world of infrastructure, friction is often a synonym for security. By removing the barriers that might stop an application from running, we also remove the barriers that might stop an attacker from moving laterally.
Read: Cloud Native Architecture Trends
The result is a landscape of "invisible" risk. The cluster is healthy, the deployment was successful, and the logs are clean. Yet, beneath the surface, the default configurations have quietly laid out a welcome mat for anyone who manages to breach the perimeter. These aren't bugs in the code; they are Kubernetes security vulnerabilities born from the convenience of defaults.
The Open Floor Plan of Network Policies
Imagine an office building where every door is unlocked. The mailroom clerk can walk into the CEO’s office, the IT server room, and the HR archives without a key card. It’s incredibly convenient for moving boxes around, but it’s a security nightmare.
This is exactly how Kubernetes networking functions out of the box. By default, Kubernetes employs a "flat" network model. Any pod in a given namespace (and often across namespaces, depending on the CNI plugin) can communicate with any other pod. There are no internal firewalls.
Read: How To Create a Powerful Kubernetes Development Workflow
This default setting assumes that all workloads inside the cluster are trusted. In reality, modern microservices are a mix of third-party libraries, public-facing APIs, and sensitive internal databases. If an attacker compromises a frontend web server via a simple injection flaw, the default network policy allows them to pivot immediately to your backend payments service.
Read: What is Container Security and How to Secure Containers?
They don't need to hack a firewall because there isn't one.
Implementing a "deny-all" policy by default and strictly whitelisting allowed traffic is the gold standard, but it breaks things. It requires knowing exactly who needs to talk to whom. Because this adds friction to development, teams often leave the default "allow-all" state in place, rendering the cluster internally defenseless.
Read: DevOps vs DevSecOps
The Silent Danger of Service Account Tokens
Every Kubernetes pod comes with an identity card in its pocket. This is the Service Account token, automatically mounted into the filesystem at /var/run/secrets/kubernetes.io/serviceaccount.
This token is intended to allow the application to talk to the Kubernetes API server. It’s a powerful feature for operators and controllers that need to manage cluster resources. However, for 99% of web applications—like your Nginx server or a Node.js microservice—this token is completely unnecessary.
Yet, by default, Kubernetes gives it to them anyway.
If an attacker gains remote code execution (RCE) on a pod, one of their first moves is to check for this token. If they find it, and if the Role-Based Access Control (RBAC) permissions associated with that account are too loose (another common default), they can start querying the API server. They might list secrets, delete deployments, or even spin up their own malicious pods.
The Center for Internet Security (CIS) Kubernetes Benchmark explicitly recommends disabling the automatic mounting of service account tokens for pods that don't need them (automountServiceAccountToken: false). But because "true" is the default, thousands of pods run today carrying keys they don't need to locks they shouldn't open.
Insecure Storage and the Root Problem
Data persistence brings another layer of default risk. When developers request storage, they often use the default StorageClass without scrutinizing the underlying permissions. In many cloud environments, this can result in storage volumes that are unencrypted at rest or, worse, accessible by nodes that shouldn't see them.
But the more pressing storage issue is access to the host filesystem. By default, Kubernetes does not stop a container from mounting sensitive directories from the host node, such as /proc, /sys, or even the Docker socket.
Read: Top Container Vulnerability Scanners
If a container running as root (which is, unfortunately, the default for many container images) mounts the host's filesystem, the container boundary effectively dissolves. The attacker can escape the container, modify host files, and potentially take over the entire node.
Tools like Kyverno or Open Policy Agent (OPA) can enforce policies to prevent these dangerous mounts, but they are add-ons. The raw Kubernetes platform will happily schedule a pod that mounts the entire root directory of the host, assuming the user knows what they are doing.
The Cost of Convenience
The problem with misconfigured defaults is that they are invisible to standard observability. A dashboard will show you high CPU usage or a crashing pod, but it won't show you that a pod has excessive capabilities. There is no red light blinking to say "This network policy is too open."
To combat this, engineering teams must shift their mindset from "does it work?" to "is it locked down?".
-
Audit Your Defaults: Don't accept the values.yaml from a Helm chart blindly. Review every setting. If a feature is enabled by default, ask if you actually need it.
-
Harden the Base: Use admission controllers to reject pods that rely on insecure defaults. Force developers to explicitly define security contexts, such as running as a non-root user or dropping Linux capabilities.
-
Network Segmentation: Treat the cluster network as untrusted. Implement NetworkPolicies that block all traffic by default and require explicit rules for service-to-service communication.
Defaults are choices made by someone else for a generic use case. Your security context is specific, and your risk tolerance is unique. Accepting the defaults means accepting a generic security posture that prioritizes ease of use over defense. In a hostile digital environment, that is a luxury you cannot afford.
