Zero trust security model with Kubernetes

It has been observed that about 83% of the company’s work is now shifted on cloud infrastructure, and according to research, about 97% of the organizations are using the public cloud today. With an increasing number of an organization adopting a newer approach for storing their data over multiple cloud services single level security becomes the main concern.

It is essential that everyone evaluates their cloud computing and container security and develops a strategy to protect their data.

Why use zero trust security model

Earlier, when data was mostly managed within premises, where only a handful of employees can access it, data breach was not a big issue as security was preventing and monitoring whatever going into and out of the premises. But these days there is continuous data transfer between SaaS (Software as a Service), IaaS (Infrastructure as a Service), IoT devices, data centers, and remote devices which creates a lot of entry points for hackers and cyber criminals to get access to your private data and cause proprietary information breach at the larger lever that can cost company’s millions of dollars.

You cannot just use user credential for security now. As billions of compromised credential has made the life of criminals much easier as 80% of the attacks involves credential use or misuse in the network. We have to proactively start protecting data at source as prevention is better than cure.

The most well-known model that can solve this problem was coined by Forrester Research analyst and thought-leader John Kindervag in 2010 which follows the motto never trust, always verify. It means trusting no one, not even the people from inside.

The zero trust model provides security at a very high level even when other security controls have been compromised. In this article, we will talk about Kubernetes Zero Trust Security and how it has impacted the cyber security world. Before that let's see what zero trust security means.

What is the zero trust security model

Zero Trust is a security model which says to trust no one both inside and outside of the network it requires all the users, devices, workloads, or system to be authenticated, authorized, and continuously validated for data permission before granting access to them irrespective of their location. As the problem stated above creates a lot of trust issues in an organization that who and what is identified as safe, zero trust framework is being increasingly adopted by organizations than traditional cyber security models.

Zero trust also limits the user’s access once they verify their identity to continuously monitor and prevent their lateral freedom throughout the network zone. It follows certain principles of architecture established by NIST (The National Institute of Standard & Technology) of them are:

• All data sources and computing services are considered as resources.
• All communication is secure regardless of network location, it implies that network location does not mean trusting.
• Users should always be verified before giving access and this should be done continuously by monitoring every asset movement.
• It's the enterprise that ensures all owned associated systems are in the most secure state and monitors systems to ensure that they always remain in the same state of security.
• Limitation of blast radius by using identity based segmentation and least privilege principles.

Zero trust security in Kubernetes environment

Kubernetes is an open source container management software that helps in the orchestration of pods to automate the deployment, scaling, and management of containerized applications in a pod. Since the launch of Kubernetes in 2015, companies started shifting their workflow in containers using Kubernetes power to service discovery, automatic load balancing, high availability, integration, self healing and much more.

Container-cased cloud deployments are growing in production environment usage as they are easier to use and implement. Accordingly, about 50% of companies are already using Kubernetes in 2021. Hence Security is something that becomes a point to notice in these widespread clusters with different sets of teams, management interfaces, operators, etc. Applying a security paradigm like zero trust can provide great security to the containers.

As we all know whatever is done in Kubernetes is first initiated by API servers. If a client wants to connect with the cluster the request is sent to API servers hence API is considered as the core of the Kubernetes control plane. From manipulation to configuration of namespaces API calls enable all of these. So If we can protect these incoming and outgoing requests we can protect our cluster hence controlling who can access API we can implement zero trust security model.

Once this first interaction of the client with the API is secured, internally Kubernetes offer some techniques to safeguard the lateral movement of the user.

How to implement zero trust paradigm in Kubernetes

There is no single way we can achieve the zero trust security model, it’s like a principle or approach which can be implemented in many ways using various technologies. Kubernetes provides certain hooks to do the same which covers all the major ways in which security can be compromised in a cluster. Some of the main are explained below.

Authentication

In Kubernetes normal user accounts cannot be added to a cluster using the API calls, hence any user with a valid certificate signed by the certificate authority (CA) is considered as authenticated. Hence every process inside or outside the cluster using the kubectl commands or direct clients have to be first authenticated before even requesting to use resources i.e. they are considered anonymous as long as they are verified.

There are multiple levels of authentication done in Kubernetes by using the combination of client certificates, bearer tokens, HTTP basic authentication, authentication proxies, and webhook token authentication, client-go credential plugins, etc.

Authorization

It follows the give least privilege model i.e. every account should not be given the full power to move laterally in the cluster; only some selected users with proper permissions can only use resources to do CRUD (Create, Read, Update, Delete) operations. Kubernetes authorization API evaluates the coming request based on certain policies and allows or denies the connection. Every request includes the requester's username and other relevant attributes.

Kubernetes uses various authorization methodologies:

1. Node Authorization - granting of permission is only given to kubelets based on the pods they are scheduled to run.
2. ABAC (Attribute-based Access Control) - provides dynamic permission to the policies which combine the various attributes, policy can use attributes like user attributes, objects, environment, etc.
3. RBAC (Role Back Access Control) - it is a method where admin creates certain roles (jobs they can perform) and the namespace they can have access, context, etc. and then binds these roles with the users called role binding. Example roles are like developer, guest, admin. You can start implementation by reading our introduction to RBAC configuration.

Admission control

We can use Admission Controller to increase our Zero Trust strategy in Kubernetes as They are a piece of code that intercepts the request to Kubernetes API server before persistence of the objects, But all the requests are authenticated and Authorized.

This is how we can activate the Admission Controllers:

kube-apiserver --enable-admission-plugin=NamespaceLifecycle,LimitRanger ...

We can Enforce various policies using in-built admission Controllers such as

• AlwaysDeny
• AlwaysPullImages
• CertificateApproval
• CertificateSigning
• CreateSubjectRestrictions
• DefaultIngressClass
• DenyExecOnPrivileged, and much more.

These all help to modify requests in real-time to meet your Access Control Rules.

Logging and auditing

Audit logs record requests to the Kubernetes API because the API server processes all the changes in the Kubernetes state. You can use Kubernetes log to monitor and track all the actions performed in the cluster, API server Acts as a Gateway collects lots of logs:

• the control plane (collects logs from schedulers and controllers),
• from cluster services such as autoscaler, kube-state-metrics, load balancers,
• other from node daemons (kubelet, proxy, kubectl requests, API).

Audit logs are not activated by default but we can use this feature to debug issues in your cluster. Kubernetes events can be used to understand the key behaviors of cluster, which in future stages can be used to find the loopholes in the security and deployment life cycle. We can even use some third-party systems to monitor these logs files.

To implement all these principles for zero trust we should follow these steps:

1. Identify the resources you have in the deployments.
2. Authentication and authorization of all the requests.
3. Apply for the least privilege policy and grant permission only if required.
4. Make sure to create separate namespaces for each user or remove the privileges after the work is done.
5. Continuously monitoring the log file and audits to know what's going wrong.

Using SPIFFE for workload identity

To leverage Kubernetes in a zero trust environment you can use SPIFFE (Secure Production Identity Framework for Everyone) which is a production identity framework to provide secure identity, in the form of a specially crafted X.509 certificate, to every workload in a modern production environment. It is used to build, bridge, and extend service mesh across the organization without sharing the keys.

SPIFFE is an open standard that provides the identity to the container, nodes, and other major kinds of stuff in Workloads it helps to build an encrypted TLS connection. So when the Pods communicate with each other the connection will be encrypted and trusted hence we are having zero trust security across pods and much more.

Conclusion

In this article we had talked about various ways you can leverage your Kubernetes environment by using the zero trust mindset and architecture, be it using the inbuilt hooks in Kubernetes or SPIFFE. This domain is still evolving and ways like SPIFFE and others will gain more popularity and security assurance to ease the deployment lifecycle.