This article is based on reporting originally published at enterprisersproject.com (2020). Quotes and attributed statements are preserved from the original source.
Kubernetes Is Mature — But Still New to Many Teams
Kubernetes reached version 1.0 in July 2015, making it a well-established project within the Cloud Native Computing Foundation (CNCF) ecosystem. Despite that maturity, it remains relatively new to many engineering teams, and the learning curve it imposes creates real security exposure. Understanding where the risks lie — and recognising that most of them are not novel — is the first step toward a defensible Kubernetes environment.
Kubernetes Has Strong Native Security Capabilities
Before cataloguing the risks, it is worth acknowledging what Kubernetes provides out of the box. According to Kirsten Newcomer, a security strategist at Red Hat, Kubernetes enables automated scaling, high availability, and resiliency for cloud-native applications. Those capabilities come with a correspondingly complex architecture, and complexity is itself a risk factor.
“As noted in last year’s CNCF-sponsored Kubernetes security audit, Kubernetes is a complex system,” Newcomer says. “And that complexity can lead to increased risk if not appropriately managed.”
The CIS Kubernetes Benchmark is a widely adopted starting point for hardening a Kubernetes deployment. It does not introduce new security principles, but it translates established hardening guidance into Kubernetes-specific configuration recommendations — a practical reference for teams new to the platform.
Namespaces and RBAC: Core Isolation Mechanisms
Luis Pabon, an engineer at Portworx, draws a useful analogy: “Kubernetes provides users with a secure, multi-tenant model to access resources like containers. Cloud providers have been doing the same thing for a decade, just for VMs.”
Kubernetes implements this isolation primarily through two mechanisms:
- Namespaces — logical partitions that group and isolate resources such as secrets, services, applications, and persistent volumes.
- Role-Based Access Control (RBAC) — fine-grained control over which users and service accounts can perform which actions against which API objects and resources within a namespace.
Both mechanisms are powerful, but neither is configured securely by default in all scenarios. Getting them right requires deliberate effort.
Six Security Risks That Are Old Problems in a New Context
“Kubernetes changes the approach to application security in some ways, but not in as many ways as most people think,” Pabon says. “Because security comes in layers, you still have to think about many of the same things, whether you are running apps on Kubernetes or in a more traditional manner.”
The following areas represent security concerns that predate Kubernetes but present themselves in new forms when teams adopt it.
1. Neglecting Foundational Security Hygiene
Kubernetes does not change the basics. Physical data centre security, operating system and application patching, and credential rotation for cloud services and databases are all still required. Pabon is direct on this point: “Kubernetes doesn’t change these security fundamentals.”
Teams excited by Kubernetes’ capabilities can inadvertently deprioritise hygiene tasks that feel mundane. That is a mistake. Unpatched nodes and stale credentials remain easy entry points regardless of the orchestration layer above them.
2. Treating Security as an Afterthought
One of the most persistent risks in software delivery is embedding security only at the end of the pipeline — or reacting to it only after an incident. Maksim Yankovskiy, VP of Engineering at Zettaset, traces this pattern to earlier generations of infrastructure design:
“Legacy systems were not engineered with security in mind; it was added later, in stages, in most cases to address bare minimum regulatory and compliance requirements.”
Maksim Yankovskiy, VP of Engineering, Zettaset
The consequences Yankovskiy identifies include overly permissive access policies, application services running under privileged accounts, inadequate separation of duties between data administrators and security administrators, and encryption key mismanagement — such as using a single key across multiple databases and applications.
Practices like DevSecOps and shift-left security exist precisely to counter this tendency — integrating security controls and reviews earlier in the development lifecycle rather than bolting them on at the end. These are not Kubernetes-specific concepts, but Kubernetes environments benefit from them as much as any other infrastructure paradigm.
3. Misconfigured Settings and Overly Broad Privileges
Misconfiguration has been a leading attack vector across virtually every technology generation, and Kubernetes is no exception. Sam Bisbee, Chief Security Officer at Threat Stack, is unambiguous: “Misconfigurations are still a primary concern with k8s, as they are with traditional apps and infrastructure. With k8s in particular, organisations are still learning how to run k8s, which makes it easy to make mistakes that can increase risk.”
Kubernetes-specific misconfigurations often arise at the intersection of three layers:
- The cloud provider’s underlying infrastructure (IAM roles, VPC networking, managed node groups)
- The Kubernetes orchestration layer (RBAC policies, network policies, pod security settings)
- The containerised workloads themselves (image configurations, runtime privileges, secret handling)
Teams that do not understand how these layers interact are prone to configurations that appear correct in isolation but create exposure when combined. A pod granted a broad IAM role, for instance, can undermine namespace-level isolation entirely.
Common privilege mistakes to watch for include:
- Running containers as root when it is not required
- Binding the
cluster-adminClusterRole to service accounts or users more broadly than necessary - Leaving the default service account token automounted in pods that do not need API access
- Not restricting privilege escalation via
allowPrivilegeEscalation: falsein security contexts
4. Reusing Credentials and Encryption Keys
Encrypting different databases with the same key is a long-standing bad practice. So is reusing passwords or credentials across cloud providers and services. Neither habit becomes acceptable in a Kubernetes context. Kubernetes Secrets are the native mechanism for injecting sensitive values into workloads, but they come with their own considerations: by default, Secrets are stored unencrypted in etcd. Enabling encryption at rest for etcd is a concrete step teams should take early in cluster configuration.
5. Underestimating the Complexity of Multi-Cloud and Hybrid Environments
Kubernetes is frequently deployed across multiple cloud providers or in hybrid on-premises and cloud configurations. Each environment introduces its own identity, networking, and storage abstractions, all of which need to be secured consistently. Teams that have siloed their security practices by environment will find this consistency difficult to achieve.
Network policies in Kubernetes are namespace-scoped and must be explicitly configured; by default, all pods can communicate with all other pods across the cluster. This is appropriate for early development but inappropriate for production workloads carrying sensitive data.
6. Skipping Ongoing Audit and Monitoring
Kubernetes emits rich audit logs covering API server activity, but those logs are only useful if they are collected, stored, and analysed. Teams that do not have an audit strategy in place are flying blind. The same logging and monitoring discipline that applied to traditional infrastructure applies here — with the added dimension of container-level and pod-level observability.
Practical Starting Points
- Apply the CIS Kubernetes Benchmark to your cluster configuration and review findings against your threat model.
- Audit your RBAC configuration regularly. Identify any cluster-admin bindings that are broader than necessary and reduce them.
- Enable etcd encryption at rest to protect Secrets stored in the cluster datastore.
- Define NetworkPolicy resources to restrict pod-to-pod traffic to only what is required by your application architecture.
- Enforce Pod Security Standards (or their predecessors, PodSecurityPolicy, depending on your Kubernetes version) to prevent containers from running with unnecessary privileges.
- Integrate security scanning into your CI/CD pipeline for container images and Kubernetes manifests before they reach production.
- Review the CNCF Kubernetes security audit findings, which remain a useful reference for understanding known architectural risk areas in the platform.
The Bottom Line
Kubernetes does not introduce entirely new categories of risk. It presents familiar risks — misconfiguration, excessive privilege, poor credential hygiene, security as an afterthought — in a more complex and distributed context that makes those risks harder to spot and easier to underestimate. Teams that bring solid security discipline to their Kubernetes adoption will find that much of what they already know applies directly. Teams that do not will find that Kubernetes amplifies, rather than corrects, their existing weaknesses.
Original reporting by enterprisersproject.com. Quotes attributed to Kirsten Newcomer (Red Hat), Luis Pabon (Portworx), Maksim Yankovskiy (Zettaset), and Sam Bisbee (Threat Stack) are drawn from the original source article.