Kubernetes Security: Guide to Securing Your Clusters

Kubernetes adoption is booming—yet security isn’t keeping pace. According to the CNCF 2023 Annual Survey, more organizations than ever are running Kubernetes in production. But with that scale comes risk. Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.

Why? Because Kubernetes is powerful—but also complex. Default settings are risky. Misconfigurations are common. And a single exposed dashboard or over-permissioned role can compromise an entire cluster.

This guide breaks down the core components of Kubernetes security, from RBAC and network policies to secrets management and audit logging. You’ll also learn how to simplify and strengthen your Kubernetes security with centralized access, dynamic credentials, and full session visibility—so you can move fast, stay compliant, and keep your clusters locked down.

What Is Kubernetes Security?

Kubernetes security is the practice of protecting containerized workloads and cluster components from unauthorized access, misconfigurations, and vulnerabilities. It involves securing the infrastructure, clusters, containers, and application code through layered controls like RBAC, network policies, image scanning, and runtime protection.

Why Kubernetes Needs Its Own Security Focus

Kubernetes has seen explosive adoption since its release. As a result, this has increased the attack surface for threat actors, mainly because security investments haven't kept up with the adoption rate. Additionally, as more and more organizations use Kubernetes, a single vulnerability can lead to widespread incidents because of its open-source nature. 

Kubernetes’ dynamic and distributed nature also demands a unique focus on security. For instance, its highly dynamic clusters make it quite difficult to create a static security perimeter. On the other hand, its distributed architecture introduces an attack avenue because containers communicate with one another across nodes.

What Are the 4 C's of Kubernetes Security?

The four C’s of Kubernetes security are a popular model that you can leverage to effectively protect your Kubernetes environment from vulnerabilities. This model covers the four main controls you should focus on to protect your environment and its applications  — layered security is the goal:

1. Cloud Infrastructure Security

The cloud layer or corporate data center is the physical or cloud infrastructure that runs Kubernetes. Whatever the cluster is built on, you must observe security best practices for controlling access. Practices like the principle of least privilege, cloud scanning, and role-based access control (RBAC) are a good place to start.

2. Cluster Configuration and Hardening

Clusters make up the Kubernetes architecture. These clusters consist of pods, which then contain containers that operate on the same local network. As such, cluster security depends on how effective your security configurations and access policies are. This involves securing the cluster’s applications and its configurable components, such as the application programming interface (API).

3. Container Runtime Protection

Containers consist of images, which then contain the base image, container configuration, dependencies, operating system, and runtime. These components are essential for executing application code. Because of this, attackers may target them, especially runtime environments and base images. Therefore, you must protect them by, for instance, regularly scanning container images for vulnerabilities, implementing access controls to secure pods, and limiting the number of third-party libraries in use. 

4. Code and Application Security

Your code and applications represent the most significant attack surface for threat actors. Therefore, you must secure your code at all costs. While there are several things you can do, you can start with basic access controls and network security as your first line of defense. Next, leverage secure coding practices and regularly scan your code with dedicated tooling.

Understanding the Kubernetes Security Landscape

While it is natively secure, there are several factors that make the Kubernetes environment vulnerable to attacks and breaches.

Architecture Complexity

The Kubernetes architecture is quite complex due to its distributed nature. This essentially means that it has multiple components or layers, such as the control plane, worker nodes, and data plane. Consequently, this complexity makes it hard to effectively secure the environment and its wide attack surface. Moreover, it becomes harder to detect and prevent security issues because of the many configurations it presents and its dynamic nature.

For instance, just one workload requires numerous security configurations, like RBAC settings, pod security policies, network policies, and secrets management — all of which can be extremely technical and effort-intensive. Now, imagine having multiple workloads, and even the most experienced Kubernetes professional will have a problem keeping up.

Insecure Defaults

Like most systems, Kubernetes comes with security defaults that can expose it to attacks if left unchanged. Sure, the default settings can be a quick way to deploy clusters, but they come with risks. Why? Because most of these setups allow anonymous access and even expose dashboards unless you explicitly disable them. Recent versions, however, have improved their security defaults, but you should never assume the defaults are secure, even on newer versions.

Common Misconfigurations

While leaving the default settings as they are is a risk in itself, making too many custom configurations can also make your Kubernetes environment vulnerable due to unmanaged configuration drift. Leaving all of the defaults may be insecure, sure, but if your settings deviate too much from the baseline, you may end up with misconfigurations. Some of the potential issues include overly permissive network policies, misused RBAC,  secrets stored in plaintext, and open ports.

Lack of Observability

Observability is the ability to retrieve insights into the health and performance of Kubernetes clusters. It’s crucial for ensuring the availability and reliability of Kubernetes' containerized applications. Because of Kubernetes’ complexity, you may need to rely on traditional monitoring tools for observability, which may not be entirely reliable. This can lead to missed security issues that expose your Kubernetes clusters to breaches and attacks.

Human Factors

Kubernetes’ complex nature makes managing it extremely taxing. Without enough experience, you risk misconfigurations, missed security patches, and other human-related errors. This can lead to devastating security issues in your environment. 

Kubernetes Security Architecture Explained

To fully implement Kubernetes container security, you must understand its foundational components, which can be categorized into three main areas.

Control Plane Security

The Kubernetes control plane is what controls a cluster’s operations. Because of this, compromising any of the control plane’s components can easily make the entire cluster vulnerable. Therefore, securing control plane services should be the starting point for your Kubernetes security. Below, we recommend security practices for several components of the Kubernetes control plane.

API Server Access Restrictions

"kube-apiserver" receives and validates API requests for creating and modifying resources. This makes it the central component for cluster communications. As such, it’s a prime target for attackers. While applying security patches or upgrading your Kubernetes version can help secure your Kubernetes API server, restricting access is more significant. 

You can achieve this by:

• Determining who can access what using Kubernetes RBAC
• Leveraging authentication for all API clients 
• Leveraging Transport Layer Security (TLS) encryption for all API traffic

Scheduler and Controller Manager Integrity

The scheduler component handles how pods are scheduled on worker nodes. It depends on the availability, allocation, and required resources, as well as toleration requests, affinity, and other policy constraints. 

As for the controller manager, it runs the processes that maintain, regulate, and adjust nodes, services, service accounts and access tokens, and pod replicas. 

For the two components, you should restrict their file permissions and configuration files. You should also configure the services to only serve HTTPS and bind them to a localhost interface so they don't reveal metrics and health information. 

'etcd' Protection

Kubernetes uses the "etcd" control plane component as a key-value store for cluster data, such as configurations and API objects. Therefore, you must protect this data from threat actors because access to it can reveal sensitive details about your environment. To protect "etcd," you can leverage Kubernetes’ support for encrypting data at rest (secrets) and access controls. With access controls, you can control who reads and writes in the "etcd" component and the entire cluster.

Node Security

Nodes are the basic unit of deployment that contain the services needed to run pods. Each node consists of components, such as "kube-proxy," "container runtime," and "kubelet."

kubelet

"kubelet" manages the individual containers that run in pods. It also manages the containers as a file with the "kubectl" command-line interface (CLI), or PodSpecs passed through the Kubernetes API server. To secure this component, you can leverage authentication and authorization mechanisms to limit its access. Additionally, promptly upgrading to the latest version and applying patches can help prevent known vulnerabilities. 

kube-proxy

This network proxy enables the external exposure of Kubernetes services by handling request forwarding based on established network rules. It supports protocols such as TCP and UDP. If this component uses a file-based configuration file, you should restrict permissions by implementing controls for authentication and authorization.

Secrets Management

Secrets in Kubernetes are objects that store and handle confidential information, such as SSH keys, passwords, and OAuth tokens. If these secrets were to fall into the wrong hands (read hackers), security breaches and system takeovers would be the next likely occurrences. Secrets security is, therefore, vital. To achieve this, you can use encryption to safeguard secrets at rest or external secrets managers like StrongDM.

Kubernetes Security Best Practices

Apart from the security practices described in previous sections, there are several additional tried and proven methods you can leverage to take your Kubernetes security a notch higher.

Keep Kubernetes Up to Date on the Latest Version

This is the most basic best practice for Kubernetes cluster security. However, it’s the most neglected. Updating your Kubernetes environment ensures that you enjoy the most recent security features and bug fixes. This way, you minimize the risk of attacks from known vulnerabilities. 

Enable RBAC During Cluster Setup

While the default security setting in Kubernetes is based on RBAC, you must enable it during setup. Additionally, misconfigurations may end up disabling this setting and granting overly permissive roles. 

To enforce RBAC, you can set the parameter as shown below:

--authorization-mode=RBAC

Additionally, instead of using the default service accounts created by Kubernetes, you should use your own service accounts. This provides you with granular access control and allows you to enforce access control on a per-application basis. 

Disable Anonymous 'kubelet' Access

If attackers access "kubelet," they can access the APIs and compromise your cluster security. You can prevent this from happening by using the "–anonymous-auth" flag and setting it to "false," as shown below:

--anonymous-auth=false

Next, ensure the API server will authenticate to "kubelet" and stop anonymous connections with the following flags:

--kubelet-client-certificate 
 --kubelet-client-key

Lastly, close the read-only API ports using this command: 

--read-only-port=0 to prevent attackers from accessing the cluster’s sensitive information

Note: Authentication alone is not sufficient. You must also enforce authorization. To do this, it's recommended to pair the setting above with:

--authorization-mode=Webhook

Use TLS for All Traffic

All communications and connections with the API server should be only via TLS. While most managed Kubernetes platforms enforce this by default, it’s still important to verify on self-hosted setups. You can achieve this by providing a TLS certificate and private key to the server using a configuration file or CLI option.

Leverage Service Meshes for Observability

Service meshes are infrastructure layers that help reduce the complexity of managing deployments and microservices. They do this by handling communication between services in a secure and reliable way. 

Additionally, service meshes provide an efficient way for resolving issues that come up when you're running those microservices and containers. They also offer fine-grained traffic policies, mutual TLS, and observability features (e.g., Istio, Linkerd).

Use Namespaces for Multi-Tenancy

A typical Kubernetes cluster will usually consist of multiple users, applications, and clients sharing resources. To protect these resources, boundaries are essential. That’s where namespaces come in. 

Namespaces help you achieve three primary things: limit the scope of user permissions, create logical partitions, and separate your resources. This makes it easier to enforce security controls, though managing multiple namespaces can be complex and overwhelming. Worth noting is that namespaces are logical isolation, not security boundaries, by default — network and RBAC policies are still needed.

Apply Kubernetes Network Policies

By default, Kubernetes allows all pods to contact one another. This is dangerous because a compromised application can transfer the vulnerability to other applications through lateral movement. That’s why segmenting networks is essential, so only approved containers can communicate with one another. 

While this sounds easy, it isn’t, especially in the cloud. The dynamic nature of container IPs makes implementing network policies especially challenging, but it’s still achievable.

Enable Kubernetes Audit Logs for Compliance

Audit logging is a stable and essential feature in Kubernetes (GA since version 1.13), recording and storing all activities that occur in the containers into a central log hub. However, you must enable this feature as a standard best practice. Audit logs are especially important for compliance purposes because they help you understand what happened, when, and who did it, in chronological order.

Real-World Kubernetes Breaches and Lessons

If you want to understand just how serious Kubernetes security-related incidents can be, these two incidents paint a perfect picture.

Tesla Breach

In 2018, attackers hijacked Tesla’s Kubernetes cluster to mine cryptocurrency. Discovered by a cloud security firm, RedLock, the incident occurred because Tesla’s Kubernetes console didn’t require authentication, and you could access it over the internet. This made it easy for the hackers to deploy cryptocurrency mining software, which leveraged the Stratum Bitcoin mining protocol.

Reports indicated that once inside, the hackers used several tactics to prevent detection, including dialing down the CPU resources they used for mining and hiding the malware behind a Cloudflare-hosted IP address. After RedLock researchers identified the breach, they reported it to Tesla through its bug bounty program and received a payment of more than $3,000. This is one of the biggest impacts of breaches — immediate financial losses. 

There are several lessons you can take away from this incident. For one, you must secure your Kubernetes clusters with strong authentication and authorization practices, such as requiring passwords or secret keys before allowing access. Secondly, network segmentation can help limit attackers' lateral movement if they do gain access to one resource. And lastly, continuous monitoring and logging are non-negotiable because they can help flag and thwart suspicious behavior immediately.

Shopify Bug Bounty

In the same year that the Tesla breach occurred, Shopify also experienced a near-miss Kubernetes-related incident. This was through its bug bounty program, which rewards researchers for disclosing flaws. 

A researcher found that if hackers were to access a Kubernetes pod, they could easily break out and reach the underlying cluster. This container-escape vulnerability can be extremely dangerous because attackers can grant themselves root access and take over the entire system. Luckily, this was reported and resolved via the bug bounty program — it wasn’t an actual breach.

One of the major lessons learned here is that RBAC isn’t a nice-to-have security measure — it’s mandatory, especially in container-escape situations. This is vital because even if an attacker manages to break out of one pod, they can’t escalate their privileges and access other vital resources.

StrongDM’s Approach to Kubernetes Security

Kubernetes is powerful—but it’s not secure by default. One misconfigured role or exposed dashboard can unravel your entire cluster. As usage explodes, security incidents are following close behind. The truth? Most Kubernetes breaches happen not because the tech fails, but because access isn’t managed properly.

StrongDM helps teams get Kubernetes security right from the start. Instead of juggling YAML, RBAC policies, and rotating secrets manually, you get centralized, real-time control over who can access what—without slowing down deployments.

Here’s how StrongDM secures Kubernetes environments

Identity-Based Access, Not Static Credentials

• Replace shared kubeconfigs and long-lived tokens with short-lived, identity-bound credentials.
• Grant access dynamically based on roles, context, or workflow triggers.
• Automatically expire access after the task is done—no cleanup required.

Enforce Least Privilege with One Policy Engine

• Eliminate over-permissioned service accounts and misused RBAC rules.
• Grant access per user, per cluster, per namespace—no guesswork.
• Easily audit and revoke access in real time from a centralized platform.

Full Visibility, Audit Trails & SIEM Integration

• Record every kubectl command, API call, and session interaction.
• Replay sessions for forensics, or send logs directly to tools like Splunk, Elastic, or Datadog.
• Get answers fast: who accessed this pod, when, and what did they do?

Strengthen Multi-Tenancy & Namespace Isolation

• Enforce fine-grained access controls across multiple namespaces and clusters.
• Prevent lateral movement with clear boundaries and automatic logging.
• Combine with service meshes and network policies for layered defense.

Simplify Security for DevOps & Platform Teams

• No need to manage RBAC across dozens of clusters by hand.
• No manual token distribution or shared service accounts.
• Integrates with your IdP (Okta, Azure AD, etc.) for seamless provisioning and offboarding.

StrongDM is how modern teams build Zero Trust for Kubernetes—without adding friction or risk. 

Book a demo and see how StrongDM locks down your Kubernetes access, simplifies compliance, and keeps developers moving fast.

Frequently Asked Questions

Does Kubernetes need antivirus?

Not in the traditional sense—Kubernetes requires specialized security tools like image scanners, runtime protection, and network policies, not standard antivirus software.

What are the risks of Kubernetes?

Risks include misconfigurations, insecure defaults, over-permissioned roles, exposed dashboards, and lack of visibility—all of which can lead to breaches.

What is Kubernetes security context?

A security context defines privilege and access settings for a pod or container, such as user ID, capabilities, and whether it can run as root.