Since its official release almost a decade ago, Kubernetes has undeniably reshaped the landscape of container orchestration. Creating a Kubernetes cluster has been streamlined to a mere matter of minutes, courtesy of cloud providers' managed services. However, the real challenge arises once your cluster is up and running.
Indeed, the first thing you will need to set up to interact with your cluster is a secure and controlled user access of the cluster itself. For that, three things come into play: API Authentication, API Authorization (RBAC), and Access control. This article will focus on the first two elements. However, keep in mind that the last one is not to be left out and is an important part of securing Kubernetes.
If you're using a managed service, you can leverage the cloud provider's IAM system for user authentication and authorization, which can even be coupled with a Single Sign-On (SSO) solution. But for on-premises clusters, this task can become considerably more intricate. You could set up a DIY solution.
However, if you run multiple clusters (and seriously, who doesn't?), managing a DIY solution on a cluster-by-cluster will increase security risks. Not finding a scalable approach leads to misconfigurations, vulnerabilities, and failed compliance audits.
During security incidents such as intrusions or data leaks, the ability to retrieve and scrutinize logs becomes paramount. Moreover, if you are subject to audits to maintain compliance with standards like PCI DSS, GDPR, HDS, ISO27001, etc… then it becomes mandatory.
For example, you must be able to pinpoint that John accessed the pods in the default namespace of your staging cluster 18 days ago at 2:13 p.m. To achieve this, you'd typically have to struggle with each cloud provider's disparate and potentially expensive logging solutions (and often not really user-friendly). Alternatively, you could implement a custom logging system, but that requires some time and expertise.
Now that we know the challenges we must address let’s find some solutions. What we need is a tool that is capable of providing both secured user access and Kubernetes action logs.
| Authentication and Authorization | Audit log on Kubernetes actions | Opensource | Free | Support | |
|---|---|---|---|---|---|
| Portainer | ✅ | ❌ | ✅ | ❌ | ✅ |
| Keycloak | ✅ | ❌ | ✅ | ✅ | ❌* |
| DEX | ✅ | ❌ | ✅ | ✅ | ❌ |
| ElasticSearch | ❌ | ✅ | ✅ | ✅ | ✅ |
| Paralus | ✅ | ✅ | ✅ | ✅ | ✅ |
These examples are just some of the few existing tools (we could also mention OpenUnison, Pinniped, etc). But they all lack the feature of logging user action. This is not really a surprise since they all only handle the authentication and authorization part and then let the user talk directly to the control plane. In order to monitor user actions, we would need a tool that acts as a proxy in front of the cluster.
If you have not guessed it yet, Paralus can address the previously stated challenges! The official Paralus website summarizes available features with the following sentences:
“Paralus is a free, open-source tool that enables controlled, audited access to Kubernetes infrastructure. It comes with just-in-time service account creation and user-level credential management that integrates with your RBAC and SSO. Ships as a GUI, API, and CLI.”
After successful authentication (via either SSO or built-in authentication), users gain the ability to interact with a Kubernetes cluster. Either through the web GUI or by using kubectl after downloading a Kubernetes configuration file from it. In both cases, users won't have direct interactions with the Kubernetes control plane API. A closer examination of a generated kubeconfig file reveals that requests are sent directly to Paralus:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: XXXXX
server: https://433313c9-c051-4652-814c-4e1bed0a34f3.user.paralus.local:443
name: localkind
contexts:
- context:
cluster: localkind
namespace: default
user: alexisbo-64padok-46fr
name: localkind
current-context: localkind
kind: Config
preferences: {}
users:
- name: alexisbo-64padok-46fr
user:
client-certificate-data: XXXXX
client-key-data: XXXXXXTherefore, Paralus acts as a secure (bastion-like) gateway between users and clusters. This approach lets you keep your clusters endpoints private, exposing only Paralus with the necessary firewall protection. Moreover, as all actions are routed through Paralus, it simplifies the process of recording every operation performed on each cluster in a centralized manner. That’s right, Paralus offers readily accessible, easily understandable, and immutable logs!
Another key strength of Paralus is its capacity to abstract the underlying cloud infrastructure while offering authentication and authorization services. This means that whether your clusters are located in public or private clouds, Paralus delivers a unified solution that eliminates the complexity often associated with diverse hosting environments. Consequently, Paralus also eliminates the headache of implementing SSO for on-premises Kubernetes clusters by providing a hassle-free out-of-the-box solution.
Lastly, it is also worth mentioning that thanks to its complete API, a Terraform provider has been made and enables you to manage Paralus configuration via Infrastructure as Code.
First and foremost, it's essential to highlight Paralus for its straightforward deployment and configuration, thanks to its user-friendly Helm chart. Here are the key steps to set up Paralus:
All these steps are well-documented and relatively straightforward, typically taking just a few hours to complete.
When considering your Kubernetes management options, Paralus stands out in several key scenarios. Firstly, if you require SSO functionality for your on-premises clusters, Paralus offers a robust solution.
Additionally, if centralized user permission management is a priority, Paralus provides the necessary tools. Moreover, if you're seeking a quick and straightforward approach to granting user access to all your clusters, especially when time and expertise constraints come into play, Paralus proves to be a valuable choice.
It eliminates the need for more complex tools like Vault and Boundary for authentication or the ELK stack for logging, making it a convenient option for streamlining your DevSecOps workflow.
Paralus has made its road map publicly accessible, showcasing upcoming enhancements, including the resource-specific access feature. This functionality will empower administrators with fine-grained control over individual Kubernetes resources, such as pods and services. Therefore enabling precise permission allocation for each user. Additionally, Paralus is backed by Rafay, which provides a paid version with the support of Paralus.
Considering Paralus' rights over all of your cluster, we advise deploying a dedicated node pool within a robust cluster. It's important to acknowledge that, like any tool, Paralus is not immune to security challenges, as indicated by reported issues such as the one mentioned here. Therefore, while Paralus offers many advantages, it's important to recognize that its maturity for specific use cases may still be a work in progress.
In the ever-evolving landscape of Kubernetes security and access management, Paralus emerges as a promising tool. Paralus simplifies the intricate task of configuring secure user access across diverse hosting platforms, fostering a Zero-Trust approach to cluster protection. By abstracting underlying cloud infrastructure and seamlessly integrating SSO, Paralus ensures that user authentication is streamlined and secure.
However, it's essential to weigh the maturity of Paralus against your specific use case. While backed by Rafay and continuously evolving, certain security considerations warrant careful evaluation. Organizations with complex security requirements may still find room for improvement.