Kubernetes is a popular container orchestration platform used by many professionals around the world. It’s an open-source platform that enables you to manage containerization, providing you with feature-rich controls. However, Kubernetes is not easy to learn and maintain. To properly secure Kubernetes operations, you need to adopt certain best practices. 

Kubernetes Security Challenges

While some aspects of Kubernetes, such as isolation of services increase security, others make securing the platform a significant challenge. Some particular areas to be aware of include:

  • Attack surfaceevery container deployed increases your attack surface. The dynamic nature of deployments requires effective service discovery tools to ensure that you are monitoring and protecting all surfaces at all times. 
  • Lack of visibilitythe distributed nature of components makes it difficult to maintain visibility or perform end-to-end tracking of events. This slows the detection of security incidents and impedes your ability to locate issues.
  • Untrustworthy imagesthere are a host of container images available to help speed deployments but not all are trustworthy. Images must be thoroughly inspected before use to ensure that no malicious code or configurations are inside. If not, deploying the image can grant access to the rest of your deployment. 

Recommended Read: The (in)complete Guide To DOCKER FOR LINUX

Also Read: Kubernetes: Tips And Tricks For Making The Most Of Kubernetes

Securing Kubernetes on Linux

The first step you can take to begin securing Kubernetes is to leverage security features native to Linux. Below are a few methods to consider.

Control container privileges

Limiting the privileges that your containers are running with is one of the primary ways to secure your Kubernetes deployment. To start, this means not running containers with root access whenever possible. If you need some root permissions, you should restrict what privileges are available with Linux capabilities and capability sets. You can do this by including the capabilities field when you define your container’s security context.

After privileges are set, you should make sure to define privilege escalation permissions as well. It does little good to limit privileges if you provide attackers with ways to amend them. To do this, you should set your AllowPrivilegeEscalation field to false. Doing so will flag your container processes with no_new_privileges. However, keep in mind that this doesn’t work if your container is running as Privileged.

Use built-in Linux security extensions

For example, you can implement seccomp, which enables you to restrict processes from freely performing system calls. Depending on your applications, the original seccomp mode might provide enough access. It enables processes to use exit(), read(), write(), and sigreturn() calls. If not, seccomp-BPF (Berkeley Packet Filter) enables you to filter which calls are allowed. 

AppArmor is another good option. This utility enables you to apply security policies to pathnames. These policies can be manually set or generated by a built-in learning mode. 

To make using AppArmor and seccomp functional at the scale you might consider using bane or docker-slim. These tools enable you to automatically generate policies. You should also take care to implement PodSecurityPolicies, which enable you to require that containers use specific security extensions. 

Prevent automatic loading of kernel modules

Unless told otherwise, the Linux kernel automatically loads kernel modules when some events occur. For example, when a filesystem is mounted or when certain types of sockets are created. 

While it makes sense that this be true for privileged processes, it is also true for some unprivileged ones. If exploited this could enable attackers to add vulnerable modules and use contained weaknesses to gain access. 

To keep this from happening you can either block specific modules or block modules in general. To block modules in general you can implement a security module like SELinux. This enables you to deny any module requests sent by containers, restricting contained pods to only those modules that are loaded separately.

To block specific modules you can either add them to blacklists or uninstall modules from your nodes. To blacklist on most Linux distributions, you simply need to add a file with what you want to be blocked. For example, /etc/modules/k8s-blacklist.conf, containing blacklist followed by your module name.

Kubernetes Security Best Practices

In addition to Linux-specific practices, there are also a few general practices that you should be aware of. 

Audit your configurations

Ideally, you could implement all available security measures and rest easy but this isn’t realistic. Instead, after implementing your chosen tools you need to carefully monitor your deployment and periodically audit your configurations. 

There are several Kubernetes security projects you can use for this. For example, kube-bench is an open-source project that you can use to compare your configurations to the benchmarks created for Kubernetes by the Center for Internet Security (CIS). 

Keep your deployment updated

Kubernetes rolls out new features roughly every three months. Patches may come out sooner depending on the issue. Unfortunately, this means you need to spend a significant amount of time updating your deployment. You may be tempted to put this and other updates off but you’re leaving yourself at risk if you do. 

Kubernetes enables you to roll out updates and automatically rollback if something goes wrong. Take advantage of this and try to patch systems as soon as possible. If you are not able to keep up with this pace, you might consider whether moving to a managed host is a better option. These hosts, like Google Kubernetes Engine, automatically update k8s for you, leaving only your own internal components to worry about.

Secure your connections

Encrypting your connections should be a given. It limits the availability of your data to attackers and protects its integrity. This is especially important for etcd which can provide an attacker with unfettered access to your cluster. Start by making sure that your encryption at-rest is enabled. This feature has been included in Kubernetes since v1.7.

For in-transit encryption, make sure you are securing both client-to-server and server-to-server connections. You can use TLS for both of these with either self-signed or Certificate Authority (CA) issued certificates.

You also need to enable both authentication and authorization methods for your traffic. For authorization, Kubernetes ships with a role-based access control (RBAC) component. For authentication, you can set up a simple token system for single-user clusters or integrate into a Lightweight Directory Access Protocol (LDAP) for larger, multi-user clusters. 


Kubernetes is a very useful tool, but it has inherent security risks and limitations. On the one hand, every container you deploy increases your attack surface. On the other hand, the distributed nature of containers creates blind spots that reduce your visibility. If you add public images to the mix, you get a potentially highly exploitable ecosystem. 

You can reduce these risks by implementing security practices, like restricting container privileges, using built-in Linux security extensions, and preventing automatic loading of kernel modules. You should also continuously audit your configurations, keep your deployment updated, and secure your connections. There will always be threats, but you can do your best to reduce risks by continually monitoring and updating your security.


Author Bio: Farhan Munir

With over 12 years of experience in the technical domain, I have witnessed the evolution of many web technologies, as well as the rise of the digital economy. I consider myself a life-long learner, and I love experimenting with new technologies. I embrace challenges with enthusiasm and outside-of-the-box mindset. I feel it is important to share your experiences with the rest of the world - in order to pass on the knowledge or let other folks learn from your mistakes or successes. In my spare time, I like to travel and photograph the world.

If you think we have helped you or just want to support us, please consider these:-

Connect to us: Facebook | Twitter

Linux TechLab is thankful for your continued support.