What Is Kubernetes Security?

The Importance of Kubernetes Security

Organizations rely on the cloud and cloud-native architectures, and Kubernetes sits at the core of that ecosystem. Yet securing Kubernetes remains a persistent challenge. In our State of Cloud-Native Security Report, 86% of respondents said security delays software releases, with nearly half regularly facing major hold-ups. Many of these delays stem from unresolved vulnerabilities and misconfigurations in CI/CD pipelines and infrastructure orchestration — areas Kubernetes directly controls. At the same time, 34% flagged CI/CD as a growing attack surface, and 43% cited API risks, both of which implicate Kubernetes. Like many cloud-native tools, in other words, organizations struggle with Kubernetes security.

Every delayed deployment costs the business time and money, on top of fines and revenue loss from security incidents.

Application Security in Kubernetes

Kubernetes orchestrates containerized workloads across cloud infrastructure, managing how applications are deployed, scaled, and operated. While not a security tool, it defines critical enforcement points such as access control, workload isolation, network segmentation, and runtime behavior.

Securing applications within the Kubernetes environment focuses on protecting applications from vulnerabilities and attacks by controlling what can access the cluster, how workloads interact, their privileges, and the flow of traffic.

Effective Kubernetes security requires coordination across the broader cloud environment, including securing CI/CD pipelines, hardened infrastructure, identity management, and monitoring systems that detect drift and anomalous behavior in production.

Infrastructure

Kubernetes runs on infrastructure (e.g., AWS, Azure), and that infrastructure needs strong baseline security standards such as hardened OS, IAM controls, encrypted disks, etc. to prevent Kubernetes from inheriting concerns like node compromise and insecure storage.

If the infrastructure underlying the Kubernetes cluster is weak or vulnerable, the cluster is weak or vulnerable.

Application

At the application layer, Kubernetes orchestrates your containers. Exposed ports and excessive permissions in your Kubernetes configuration can expose your app to compromise.

In 2022, nearly a quarter million Kubernetes clusters were publicly exposed through the default port 10250 used by the kubelet (the agent that runs on each node and ensures that all containers are running in a pod). Attackers can use this as an entry point to mine for crypto or execute commands inside containers or clusters. This vulnerability has its own MITRE ATT&CK framework designation: T1609 - Container Admin Command.

CI/CD

Orchestration begins in your CI/CD pipeline, automating the testing, building, and deployment stages of the application lifecycle. Because Kubernetes deploys code, the CI/CD pipelines that produce that code should be secure via image scanning, configuration validation, and signed manifests.

• Image scanning such as SAST and SCA help find weaknesses in your images early, before they replicate across all containers instantiated from the vulnerable image and enter runtime.
• Configuration validation ensures that the settings and instructions within a CI/CD pipeline’s configuration file are correctly structured and free from errors. This prevents issues during the build, test, and deployment stages.
• Signed manifests verify your software packages and configurations are authentic and haven’t been tampered with or altered. Manifests should be signed with a private key belonging to a trusted entity.

Related Article: Improper Artifact Integrity Validation

Networks and APIs

Kubernetes uses a flat network model, allowing pods to freely communicate within the cluster by default. Default settings, however, are typically less than ideal. In this case, the default enables attackers who compromise one pod to freely access all other resources in the cluster.

Network policies, such as virtual firewalls, secure Kubernetes pod-to-pod communications. Security teams should limit communication to the minimum necessary for workloads to function both ingress and egress and east-west traffic within the cluster.

Kubernetes usually employs service meshes like Istio and Linkerd to manage internal service-to-service traffic. This exposes APIs through ingress controllers and load balancers, so security depends on proper rules and protections within the mesh.

Use TLS to encrypt and secure communications for data transmitted over a network, web application firewalls (WAFs) help enforce rate limiting and enforce zero trust to ensure that only the necessary permissions are granted to each specific element.

Identity and Access Management

Kubernetes comes with its own role based access controls, but it also ties into CIEM and SSO/IDP systems. Because Kubernetes supports so many authentication methods, managing them through RBAC alone can be complex, resulting in oversights that could expose the cluster.

Kubernetes identity controls must be tailored to fit the organization’s broader policies and include IAM security procedures and zero trust enforcement, to ensure only authorized entities can interact with the cluster.

7 Common Kubernetes Security Mistakes

Even one of these common security mistakes and vulnerabilities found in Kubernetes deployments can cause data breaches, allow malicious actors access to vital resources, and cost your business in downtime and regulatory fines.

1. Default security settings: While Kubernetes comes out-of-the-box with many controls to allow for security, the complex default configurations and settings aren’t secure enough.
2. Misconfigurations: Kubernetes’ default settings leave clusters overly permissive, making misconfigurations one of the biggest threats. Admin-level privileges are granted too freely, and public dashboards are exposed.
3. Exposed APIs: If the Kubernetes API server is exposed or misconfigured, attackers can gain full cluster control, particularly if strong network policies haven’t been enacted.
4. Root permissions: Similarly, running containers as root users or with unnecessary capabilities breaks container isolation, giving attackers more ways to persist or cause damage.
5. Disabled or poor encryption: Kubernetes secrets are base 64-encoded, but not encrypted by default, so make sure to enable encryption at rest. Teams may also store secrets (like API keys and passwords) in plaintext or ConfigMaps, making them easy pickings for attackers.
6. Poor network segmentation: Kubernetes security can be compromised without adequate network segmentation. By default, every pod in a cluster can communicate, making lateral movement easy for attackers.
7. Lack of logging and monitoring: Kubernetes clusters generate logs at various levels automatically. However, you might fail to detect suspicious activities and potential breaches if you aren’t monitoring and reporting on these logs, as teams can’t see into pod behavior, API usage, and audit logs.

Kubernetes Security Best Practices

Organizations are continuously working to improve Kubernetes security, both internally and in the open-source project. These Kubernetes security best practices have been identified over many years to address key security issues in a Kubernetes environment.

RBAC/Least Privilege

Enable role-based access control (RBAC) to limit the access an attacker can gain to the cluster if they compromise one account. When users and accounts are given excessive trust, they increase the attack surface. To mitigate this, create Roles or ClusterRoles, which contain rules representing permissions. A Role sets permissions within a particular namespace. ClusterRoles can grant the same permissions as a Role, but they’re cluster-scoped instead of namespace-scoped, meaning they provide access to cluster-scoped resources, nonresource endpoints, and namespaced resources across all namespaces.

Bind these Roles/ClusterRoles to users, groups, and/or service accounts — and apply least privilege. Support the principle of least privilege by adding namespaces for resource isolation, applying pod security policies, and securely managing secrets.

Use Pod Security Admission (PSA)

PSA enforces security standards on pod definitions at creation, helping you define how to restrict pod behavior. Prevent risky pod configurations using three pod security levels: privileged, baseline, and restricted.

• Privileged: Unrestricted, with the widest level of permissions, and allows for known privilege escalations. Intended for trusted users managing system- and infrastructure-level workloads.
• Baseline: Minimal restrictions and prevents known privilege escalations. Intended for application operators and noncritical app developers.
• Restricted: Heavy restrictions. Intended for security-critical app developers and operators, and lower-trust users.

You can also choose what mode PSA operates in when it detects a potential violation. Enforce rejects a pod, audit allows a pod but triggers an audit annotation to be added to the event and warn allows a pod but triggers a user-facing warning.

Implement Network Policies

By default, Kubernetes pods aren’t isolated. They accept traffic from any source. Network policies act as a mini firewall inside your cluster, controlling which pods can talk to which pods. Without policies, all pods can talk to each other, and an attacker in one pod can easily move laterally.

You can also use service meshes (like Istio or Linkerd) to manage communication between services (clusters, pods, externally, etc.). They add observability, reliability, and security features across all services within the mesh, without needing to encode the features directly into each service.

Encrypt Secrets and etcd

Secrets contain the necessary information to decrypt data you’ve protected through encryption and are often stored in etcd, a key value store used by Kubernetes for all cluster data. Storing secrets as plaintext or ConfigMaps hands attackers the keys to your Kubernetes kingdom.

Use the advanced encryption standard (AES) to encrypt secrets and other sensitive data stored in etcd at rest. Kubernetes offers built-in support for secrets, but you can also integrate external secrets management solutions with stronger security features.

Restrict Access to the Kubernetes API

The API server is the nucleus of your cluster and should only be accessed by trusted users, systems, and IPs. Use TLS to encrypt communications, firewalls and network policies to restrict IP ranges, enforce authentication and authorization, and use audit logs to track access. If integrating with SSO, be sure to enable mTLS and OIDC. The Kubernetes API should be your most protected and monitored resource.

Use Image Scanning Tools

Your containers, clusters, and pods should be scanned to identify vulnerabilities, but manual scanning is time-consuming and inefficient. Image scanning tools automatically review containers, container images, image registries, and dependencies for CVEs and misconfigurations. Run scans at multiple levels during CI/CD:

• Build: As part of the build process, run scans to discover vulnerabilities. If one is detected, the build should fail, preventing the image vulnerability from reaching production.
• Registry: Scan images of software packages after the build is complete, as some vulnerabilities can’t be detected during the build phase.
• Predeployment: Before deploying an image, scan it for vulnerabilities. Kubernetes allows you to call admission webhooks when deploying new workloads, automating the scanning process.
• Runtime Workload: If an image has passed all the previous scans, it will likely be placed into production. Implement scanning to detect vulnerabilities in the running workload as one added layer of protection.

Always block deployments with high-severity CVEs to avoid shipping containers with outdated libraries, rootkits, or cryptominers.

Regularly Audit Cluster Configurations

Auditing allows administrators of Kubernetes environments to review a sequence of actions in a cluster and answer who/what/when/where/why/how questions about certain events. Kubernetes provides native auditing features that continuously log, monitor, and audit all activities to identify vulnerabilities and threats. CNAPPs and other security tools like EDR also offer continuous logging, monitoring, and auditing of activities to identify vulnerabilities and threats,

Monitor with a Cloud Workload Protection Platform (CWPP)

Cloud workload protection platforms (CWPPs) protect workloads by providing visibility into activity, detecting threats, and applying security policies across various environments. They offer container firewalling and forensics and use machine learning and rules-based threat detection to respond with precision.

Kubernetes Security FAQs