Best Practices for Kubernetes Security

Kubernetes (K8s) and its expansive ecosystem of cloud-native technologies have revolutionized the way applications are built and run. While the adoption of Kubernetes has opened the door to big gains in business agility, scalability and efficiency, it also introduces complex new security challenges that affect platform engineers and developers alike.

Security is a massive concern for enterprises using Kubernetes, with 55% of developers saying that they had to slow down or delay deployment due to security concerns.

This article will help you gain a baseline understanding of how you can harden Kubernetes and keep it running securely.

In general, securing Kubernetes involves protecting containers/pods and preventing unauthorized users from accessing sensitive code. K8s container security consists of essential best practices and precautions, some of which are listed below. 

Kubernetes systems have many moving parts, like nodes, clusters, pods and networks, each of which have unique security vulnerabilities. This complexity makes employing comprehensive K8s security a difficult task. 

To help get you started, here are six fundamental Kubernetes security best practices:

Access control is an excellent way to maximize security and accountability since it will let you decide exactly who gets access to what part of the system. If you have strict access control, it will be easier to see where abnormal activity is coming from, since you will know which users have access to that part of the cluster.

Enabling Kubernetes Role-Based Access Control (RBAC) is a great way to set up who has access to the Kubernetes API and the kinds of permissions those users have. 

Firewalls are essential for the proper functioning of Kubernetes, especially for applications that require a connection to the internet. These firewalls can adhere to the stock rules that Kubernetes provides, or you can customize them based on your needs. Firewall options for Kubernetes include iptables and firewalld included with Kubernetes, Container Network Interface (CNI) plugins which leverage cloud provider network policies, cloud provider network and application firewall services (e.g., AWS WAF), and numerous third-party firewall products.

Secrets (objects that contain sensitive information like passwords) are by default stored in cleartext in the API server’s underlying etcd data store. These objects can represent a severe vulnerability if you don’t configure encryption at rest for secrets. Once encrypted, the secrets  can only be accessed by someone who has the key (which is held locally in the API server).

One essential principle to follow when setting up your system is the rule of least privilege. Every single user and container should only have the privileges they need. Anything above that is an unnecessary risk.

It’s always good to ensure your workloads are kept on separate isolated node clusters. This way, if a node is ever compromised, the malicious user will not be able to use the node’s access to escalate privileges in a cluster. A good practice is to isolate your clusters whenever possible so that one compromised cluster does not endanger the entire system.

Ensure you closely monitor application activity and how traffic moves between clusters. Monitoring activity will help you identify abnormal behavior and remove extra network policies. Removing these policies will help you isolate your system further since you can remove any connections that were not being used.

Depending on your configuration, Kubernetes may update itself during point updates (e.g., v1.21 to v1.22), but it will need to be updated manually when it comes to more significant updates. These updates ensure your system has the latest security patches. Not updating your cloud-native environment could potentially leave your applications vulnerable.

Equally important is to follow the zero-trust network security model. Zero trust can be the first line of defense by keeping complete control over the API server and ensuring every request is both authenticated and authorized.

The zero-trust network model assumes that every user or system that operates on a network cannot be trusted. So every action taken in the Kubernetes environment will first be checked, authorized, encrypted and logged. Zero trust will ensure tight security if appropriately implemented.

Once you have followed the above steps, the next step is to secure your individual Kubernetes clusters. Here’s how: 

Open Policy Agent (OPA) is an open-source policy engine that allows users to write their security policies as code and then uses those policies to make crucial decisions. OPA makes it much easier to implement custom logic and security, especially since it standardizes all portions of the stack to use just one policy coding language, Rego.

Dev teams worry about misconfigurations three times more than all other security concerns. OPA will allow you to test your policies before deployment to make sure everything is working as it should, allowing your team to track and fix every misconfiguration before it is too late.

Make sure to only use images from an official verified registry and enable image scanning to avoid unwanted vulnerabilities. Only run your images as a non-root user. Running them as root will give the image access to all your files, which a hacker could exploit if they gain access to the image.

Observe your application in its everyday operations and look at what processes it uses. Then use those processes as a whitelist and flag any new or abnormal processes. Whitelisting is made much easier with a third-party solution, such as Prometheus Operator, as this kind of monitoring can be very difficult to do manually.

Before sending your cluster into production, you should always enable audit logs. Enabling these logs may end up increasing memory usage, but you will be able to track any type of activity in your cluster. Ideally, you’ll want to follow every request made to the API server. 

Audit logs will not only improve security but also help your team debug and find issues faster. These logs will show you exactly when an issue occurred and what actions triggered it, streamlining the debugging process.

Make sure all your pods only have access to the amount of memory and CPU resources they need for standard functions. This way you can guard against DOS attacks that flood your system with traffic to try and overwhelm it. Pod and container resource allocation is essential when it comes to the efficient management of the entire system.

Security context refers to the access controls you can set up for a pod or container. These context settings determine what kind of privileges the pod will have. These permissions can be internally enforced by Kubernetes or by third-party security context tools.

To set up these contexts, add a Security Context block in the deployment file for a pod and Kubernetes will enforce that rule for every pod in the container. This feature only works for Kubernetes container security, though. Nodes and service accounts still require that you use RBAC to control privileges. 

Styra DAS lets you quickly operationalize Open Policy Agent across your cloud computing network. You can quickly implement security policies across your entire tech stack using a policy-as-code system. This system allows you to declare your policy once and then enforce it whenever and wherever you need to, reducing the chances for human error.

Below are some tools to try out and resources to learn more:

Styra DAS – Styra Declarative Authorization Service lets you manage your entire OPA through one unified control plane.

Styra Academy – With over 30 free courses available, you can learn more about how to enforce security measures in your cloud-native stack.

Open Policy Agent – The official OPA website contains all the OPA documentation you could need.

The principle of least privilege dictates that we should allow components of the Kubernetes system to have access to just the resources and data they need. No cluster or user should have permission to control or view a part of the system that they do not need for regular function.

Rego is a declarative coding language used to create Kubernetes policies, along with policies for other types of systems and other portions of your tech stack. Rego was inspired by Datalog, an old data processing language. You can learn Rego by going through the documentation on the OPA website or via the Styra Academy Rego course.

The CIS Kubernetes benchmarks are a set of over 140 best practices that are designed to keep your Kubernetes environments secure. The Center for Internet Security (CIS) consults security experts from around the world to agree on these essential guidelines. Use the Styra DAS CIS Benchmarks for K8s Compliance Pack to jumpstart compliance with CIS benchmarks.

Role-Based Access Control (RBAC) refers to an admission control system that allows specific users to access information, networks and computer resources in Kubernetes. This system grants permissions based on the user’s role in the organization/system. This way, only people who have the clearance to access specific resources are allowed to do so.

Automate Kubernetes Compliance

Authorization in Microservices

How to Secure Kubernetes Cluster

What is Fine Grained Authorization

Kubernetes Security Checklist