Best Practices for Keeping Kubernetes Secure

When implementing Kubernetes, too many organizations get excited about the orchestrated containerization capabilities and efficiencies they’ll gain, and don’t think enough about Kubernetes security. 

It’s a common (and dangerous) mistake. The 2024 Kubernetes Benchmark Report from the Cloud Native Computing Foundation found that 28% of organizations have more than 90% of workloads running with insecure capabilities. If you don’t implement Kubernetes security basics and best practices, you open yourself up to bad actors, dangerous privilege escalation and resource inefficiencies. 

Whether you’re looking to beef up security on your existing Kubernetes or whether you’re preparing to install your first Kubernetes cluster, this guide will have tips and tricks for you as well as wise strategies. Here’s the background on Kubernetes security and the essential best practices you should know to protect your organization.

Why Kubernetes is difficult to keep secure

As hacking techniques become more sophisticated, companies face increasingly tough challenges to securing their Kubernetes. Security is also difficult because Kubernetes has very low security by default, and many security protocols have to be implemented. Some of the common security hurdles companies face include:

• API attacks. APIs are a particularly vulnerable point in Kubernetes. If an API endpoint is unprotected, it leaves the door open to denial of service (DoS) attacks and other risks. 
• Container images. If your organization has insecure container images or outdated dependencies, you risk a container running a workload that has malicious code, running a container on root permissions that allows hackers to access information or accidentally baking API keys into a container and exposing that information to bad actors. This risk is very common as developers download containers, dependencies and software to build their applications.
• Distributed environment. Kubernetes has an inherently distributed environment with many benefits. However, the disadvantages of a distributed environment include unique risks. It’s harder to gain full visibility into your containerized environment, and you’ll need to correlate audits and logs frequently. The more distributions you have, the more permissions you have to manage to keep your Kubernetes secure and the harder it is to keep your environment compliant. 
• Pod replacement. If a pod crashes and is managed by a Deployment or ReplicaSet, Kubernetes will launch a new one. In many ways, that’s a good thing, and it’s one of the unique features that makes Kubernetes resilient. However, if updates or patches were applied only to a running pod (instead of updating the container image or Deployment), those changes will be lost when the pod is replaced, leaving data vulnerable. 
• Default configurations. Kubernetes’s default configurations are a double-edged sword. The default flat network model allows any pod to communicate with any other pod, which is great for flexibility. However, it also means that if an attacker can access one pod, then all other pods could potentially be compromised. Kubernetes also lets pods run as root by default. When containers run with root access as default, an attacker could potentially take control of a pod, escalate privileges and wreak havoc on the host system.
• Insecure workload configurations. Kubernetes gives users granular control over workload configuration. That enables users to tailor access and security to your organizations’ specific needs. However, if it’s not done properly, it can also lead to major data breaches. Host namespace sharing can lead to data leakage, and elevated privileges can allow bad actors to modify host files.

What is Kubernetes security?

Kubernetes security includes anything you do — techniques, processes, software and more —- to keep your Kubernetes platforms and their applications safe. Kubernetes security covers all tools and methods for securing the entire process and architecture of Kubernetes.

For a comprehensive Kubernetes security approach, consider the “4 Cs.” The 4 Cs refer to four layers of security that keep Kubernetes safe from threats and form a top-down paradigm for an overall Kubernetes security strategy. 

The four Cs: Cloud, cluster, container and code

Cloud 

The first “C” stands for cloud. Generally, this refers to your organization’s server infrastructure. That may be the cloud, whether private or public, whether self-hosted or managed Kubernetes. However, it can also refer to an on-premises data center. If you have a hybrid environment, it can include that too. Whatever your server infrastructure looks like, you need to keep it safe by implementing strategies such as backing up data, enforcing access controls and constantly monitoring your Kubernetes for suspicious activity. 

Cluster

Kuberetes runs on clusters, or groups of nodes. Cluster security is an important part of overall Kubernetes security. To keep clusters safe, you must also consider best security practices for the cluster’s APIs, applications and associated microservices. Store passwords and other sensitive information in Kubernetes Secrets. We also recommend implementing network policies to manage communication between pods and prevent unauthorized traffic between containers. 

Container

Part of Kubernetes security is making sure the containers it’s orchestrating are secure. A major aspect of container security is pulling information from only trusted container registries. Another big part of Kubernetes container security is having the proper permissions. For example, run containers as non-root as much as possible, stick to the principle of least privilege and enable role-based access control.  

Code

Kubernetes code manages containerized applications by defining resources like deployments, services and pods through configuration files. The code is one of the most commonly attacked areas of Kubernetes. The good news? It’s also the most within your business’s control. Start by scanning your code regularly, then reduce the attack surface as much as possible by reducing code, disabling unused ports and encrypting transmission control protocol (TCP).

Why Kubernetes security is vital for your organization

Many of the benefits and strengths Kubernetes gives organizations also come with downsides. These downsides mean Kubernetes presents unique security challenges. It’s a tough balance to strike; organizations need the freedom and collaboration they get from containerization orchestration with Kubernetes, but they’re often not prepared to keep the processes secure. 

Kubernetes security is so vital due to its unique default configurations. For example, Kubernetes does not enforce resource limits by default. Kubernetes also lets pods run as root and isn’t great at managing secrets. Because of its inherent permissiveness, Kubernetes is particularly vulnerable to DoS attacks and other risks.

If a security breach occurs in Kubernetes, your organization faces serious consequences. Kubernetes frequently interacts with sensitive data such as user credentials and API keys, which could be accessed in an attack. If a Kubernetes API server is hacked, your container could stop working, and your company could experience significant data breaches and business disruption.

One of the top reasons companies invest in Kubernetes is because of its ability to intelligently schedule workloads across nodes and auto-scale workloads. Security breaches threaten your workloads. Not only will a compromised container be less efficient and cost your organization more, it also risks data breaches that can cause PR nightmares and reputational damage for the whole company. 

Best practices to keep Kubernetes secure

To keep your data safe and your business running smoothly, follow these top Kubernetes security best practices. These build on the 4 Cs of Kubernetes security and will give you more concrete, specific and actionable best practices. 

Kubernetes cloud security

To keep your Kubernetes cloud security in prime condition, make sure you secure your API server. API servers are a major point of attack. To increase cloud security, best practices include disabling anonymous access and using role-based access control. You’ll also want to restrict API server access, which you can do with a VPN or an API gateway. These best practices apply regardless of whether you’re using an entirely cloud environment or a hybrid environment. 

Kubernetes cluster security

The Kubernetes API server is the control plane for the entire cluster. To keep your clusters secure, make sure you protect the API server. Specific best practices for this include disabling anonymous access to the API server and using strong authentication methods. 

It’s also best practice to keep a close eye on your cluster activity. We recommend enabling Kubernetes audit logs so you can catch suspicious activity. You can also monitor cluster health and resource usage. If you find any anomalies there, those could be red flags that an attack may be occurring on your cluster. 

Kubernetes container security

One of the most important actions you can take to increase Kubernetes cluster security is to only use trusted and verified container images. In fact, the Cloud Native Computing Foundation’s 2024 Kubernetes Benchmark Report listed 14 of the top security configuration issues, and three of them were about images (image vulnerability, unscanned images and outdated container images). 

Additionally, the container runtime can be vulnerable to exploits that allow containers to escape and interact with the host. To further strengthen your Kubernetes container security, harden your container runtime by disabling unnecessary features like privileged mode. You can also use container security tools to provide an additional layer of isolation between the containers and the host.

Other best practices for Kubernetes container security include always running containers as a non-root user and using Kubernetes Resource Quotas to prevent abuse of cluster resources.

Kubernetes code security

Keeping your Kubernetes code secure starts with the basics: enforce role-based access control, use audit logging and and regularly scan your code for vulnerabilities. If you have implemented those strategies already, you can move on to more sophisticated best practices, like storing secrets in Kubernetes Secrets and encrypting them at rest, implementing network policies to enforce communication rules across pods and using pod security standards (PSS). 

Kubernetes design security

Set yourself up for success with careful Kubernetes design security. As you design your Kubernetes architecture, you’ll have to make a lot of choices. Ultimately, what is safest is the design type that serves your business best. 

For example, will you be using a managed Kubenetes service, like Amazon AKS or Azure Kubernetes Service, or will you be managing your own Kubernetes? Using a service has the security advantages of having a professional company monitor threats for you and create safe pre-configured settings. However, there are often limitations to managed services. If the one-size-fits-all approach doesn’t work for your organization, you may be more secure managing your own Kubernetes because you can customize the privacy settings, integrate with your existing infrastructure more easily, and air-gap your clusters from the internet. 

Essentially, when it comes to design security, there are many factors to consider. However, whichever design you choose, you might want to follow some basic best practices. Make sure that your design can secure container images and registries, secure data both in transit and rest and enforce strict network and role policies.

Kubernetes build security

As you build your Kubernetes and its applications, you can implement best practices to increase security. It’s important to use minimal base images. You can keep your build pipeline secure by using isolated, dedicated CI/CD environments to build and test containers. You can also integrate automated vulnerability scanning in the build pipeline to make sure your application code and dependencies are solid. 

Of course, like the rest of Kubernetes security practices, you’ll also want to check permissions. You’ll want to change the Kubernetes default settings and start limiting privileges quickly. Limit build-time privileges by using container user namespaces and (as always) applying the principle of least privilege.

Kubernetes deployment security

Keep your Kubernetes deployment secure by enforcing the principle of least privilege so that there are no permissions escalations while you deploy. Another best practice for Kubernetes deployment security is to keep your deployment pipeline secure with CI/CD tools. 

As you deploy, make sure your configurations are secure with Pod Security Policies (PSP) or Pod Security Standards (PSS). Make sure networking is secure, too, with network security policies. As always, keep your role-based access controls restricted and automate vulnerability scanning to make sure your deployment runs smoothly. 

Kubernetes runtime security

Once your Kubernetes is up and running, your job isn’t done. There are more best practices to implement to keep it running securely. 

As you deploy and scale apps, you’ll need to continuously monitor runtime environments and enforce security policies. Make sure you’re using role-based access control to prevent unauthorized access. It’s best practice to regularly monitor for threats (or, better yet, get real-time threat detection) and apply updates and patches. It may be helpful to research Kubernetes monitoring strategies and tools as well. 

You’ll also want to keep an eye on container runtimes and images. In addition to being early indicators of an attack, these are also things you should monitor for container efficiency, better operations and improved resource use.

Secure your Kubernetes with SUSE

Whether your enterprise is cloud, multi-cloud or hybrid, SUSE can help manage your Kubernetes security. We’ll help your containers run safely and smoothly across your environment, especially with the SUSE Application Collection, which provides trusted containers and helm charts. Our enterprise-level security makes compliance easy and straightforward. To help keep your distributed environment secure, SUSE Security offers deep integration with Kubernetes security policies, ensuring tighter control and compliance across all deployments.

No matter how many clusters you have, SUSE enables organizations to manage Kubernetes clusters in a centralized manner, making it easier to deploy, scale and secure containerized applications. Learn more about SUSE Security today. 

FAQs about Kubernetes security

Have questions about Kubernetes security? We have answers. Here are some FAQs and our answers to give you some background and explain answers.

Is Kubernetes a security risk?

No, Kubernetes is not inherently a security risk in and of itself. Kubernetes will not harm your company in any way. However, if Kubernetes isn’t configured properly or doesn’t have the right permissions, bad actors can easily obtain unauthorized access to your containers. 

It’s worth noting that Kubernetes has very accessible default settings. Default settings include root access, has no inherent encryption for secrets and does not automatically enable pod security policies. To keep your Kubernetes secure, you’ll need to assign roles based on the principle of least privilege, use role-based access control, implement network policies and enforce other security measures. 

How secure are Kubernetes containers?

If used directly out of the box, Kubernetes containers are not secure. In order to be secure, they must be configured properly. However, many organizations do not configure their Kubernetes correctly, and many organizations experience security incidents as a result. 

If configured correctly, Kubernetes containers are very secure. One of the advantages of Kubernetes is that it’s highly configurable, so you can tailor permissions and security settings to your business’s specific needs. As long as you do it correctly and update it regularly, your containers will be fine. You can keep your containers secure by following the “4 Cs” of Kubernetes security. 

What are the 4Cs of Kubernetes security?

The 4 Cs of Kubernetes security are cloud, cluster, container and code. These refer to the four major layers of security needed to keep Kubernetes functional and secure. If you follow security principles for these four areas, you’ll be in good shape and your Kubernetes will likely be very secure. 

The first C, Cloud, refers generally to server security strategies, whether your servers actually on the cloud, are on-premises or are a hybrid of the two. The second C, Cluster, refers to groups of nodes that distribute workloads and actually power your applications. As the layers of security get more granular, we get to the third C, which is container. Containers are the building blocks that scale to power applications. Finally, the last C is code. It’s a massive attack surface, so anything that isn’t essential to running containers should be deleted or encrypted.