Kubernetes is the most widely used container orchestration tool. To make our applications scalable & flexible, it employs numerous components, layers & services. And with so many interfaces, we have a large attack area and thus security becomes a concern.
Makers and maintainers of Kubernetes realized that and focused on providing some sort of security mechanism to secure Kubernetes clusters. Today, Kubernetes provides essential security features like Role-Based Access Control (RBAC) out of the box. In fact it took almost 3 years for the RBAC feature to be available after Kubernetes’ release.
However, securing clusters, nodes and applications is out of scope of Kubernetes. Moreover, for most enterprise-grade setups, RBAC only is not enough and is often coupled with other tools & techniques for enhanced security.
In this blog post we’ll share some tips to secure your kubernetes clusters. While there are many, these are a few that you must enable to ensure you have the right set of checks in place.
Secure Your Kubernetes Clusters
Configure Role-based Access Control
Most of the organizations have multiple applications running on a single Kubernetes cluster. With multiple teams accessing the same cluster, it is difficult to control who has access to what. That’s where Role-based Access Control (RBAC) fits in. RBAC is designed to grant access to Kubernetes resources based on the roles of individual users within an organization.
RBAC comes with a set of default roles that you can configure. You can bind(assign) these roles to users, groups or service accounts. It also allows you to configure custom roles that you can assign to users and have fine grained access control over your resources.
If you’re setting up a Kubernetes cluster, the first thing you must do is enable RBAC. To do that, you need to set –authorization-mode=RBAC while starting the API server. Post that you need to create a kind:Role and apply it to the cluster. For example, the file below creates a role pod-reader in the default namespace to grant read-only access to pods.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] #indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
You can create such roles based on the permissions you need. However, as the number of clusters you manage increases, it becomes difficult to manage roles and access to all the clusters. That’s where you can leverage tools like Paralus that allows you to create and manage custom roles from a dashboard whilst managing access to multiple clusters.
Create Namespaces
When you have multiple teams working on different applications in your organizations. One way to limit their access is by creating different clusters for each application/team. But since organizations have multiple applications and teams, this isn’t the right way to isolate access.
Namespaces were made just for such use cases. These in a way allow you to isolate group of resources within a single cluster. That way you’re able to isolate workloads as well as limit access of users to a particular namespace without creating multiple clusters.
You can create a namespace for every team, deploy their workload within the namespace & configure access. Administrators can create any number of namespaces and configure access to each one of them. By using namespace you also enhance RBAC as you have finer access control. Since you have multiple namespaces on a single cluster, you can share resources using resource quotas.
kubectl get ns
NAME STATUS AGE
staging-dev Active 2d9h
staging-test Active 2d9h
prod-public Active 2d9h
It’s a good practice to enable namespaces when you want to secure your Kubernetes clusters. Refer to official Kubernetes namespace documentation to understand how you can use namespaces.
Enabling Least Privilege Access
Things don’t just stop after enabling RBAC and namespaces. These are just a bare minimum. With large footprints and multiple interfacing points of enterprise applications today, ensuring that each of them is safeguarded is tough. Both these mechanisms allow you to prevent attacks from outside the cluster.
But what if someone portraying a legitimate user manages to enter the cluster? What if there’s an internal threat?
To prevent such attacks, you need to implement least privilege access. The best part is that this is not limited only to users but also applies to applications & accounts. You enable just enough access to users/accounts/systems that they need.
By enabling least privilege access, you reduce the attack surface as it limits privileged access exploits. Malware attacks that require elevated access to move within the system, are also prevented by implementing least privilege access.
One of the crucial things for implementing least privileged access is to correctly configure user, privileged and service accounts. It is also advisable to create groups for managing privileges along with configuring just-in-time access to further strengthen the security of your cluster.
Using 3rd Party Identity Providers
Organizations today use external identity providers to enable access to their enterprise applications for their employees. Identity providers create, maintain and manage identity and provide user authentication as a service. Organisations can configure access to their Kubernetes clusters by using their identity providers like Google, Microsoft, GitHub etc.
Administrators can also create groups with their identity providers and map them to roles and permissions within their Kubernetes clusters. This will enable more robust and end-to-end implementation of RBAC. Further, considering the employee churn, admins only need to modify users at the IdP end as employees move in/out of the organization without modifying roles on their Kubernetes infrastructure.
To understand how this would work, you can implement a custom access management solution integrating identity providers with Kubernetes, using open source tools like Dex and Kubelogin. This is something you can do to understand how things work. However, this isn’t recommended for an enterprise setup as it isn't scale friendly and there's room for error when dealing with multiple clusters.
Enable Audit Logs
Last but not the least, you want to keep an eye on all the activities that take place within your cluster. Even after implementing the best of security tools and practices, you need to ensure that they are working how you want them to work.
You want to keep a track of user activities like who is accessing what, when and how. Enabling audit logs helps keep a track of all activities across your organization. It helps provide an audit trail with a sequential record of activities. This is helpful for admin teams to track user activity and security teams to analyze and investigate breaches.
Not only from a security point of view, audit logs also come in handy to troubleshoot system issues. With a historical log, teams will be able to recreate the set of events that led to an issue.
Hence, irrespective of the system or application that you’re using, enabling audit logs is a basic necessity to keep your system safe, compliant and identify possible threats well in advance.
Summary
As an organization your focus should not only be on making your applications faster, flexible and scalable, but also making it secure. And the first step to do that is to secure your infrastructure. In the world of cloud native applications, securing Kubernetes clusters is vital.
From implementing RBAC and namespaces to limiting access by using least privilege and just in time principles are key to secure your Kubernetes clusters. While this post isn’t a comprehensive list of security tips, these are a few things that you must take into account while securing your Kubernetes clusters.
Open source tools like Paralus help you secure your Kubernetes clusters by implementing best practices along with Zero Trust principles. It helps you create and manage custom roles along with just in time service account creations. It also comes bundled with an audit logging feature that helps you keep track of what’s going on in your cluster. To give Paralus a try, check out our GitHub Repo and refer to our documentation to know more.
