I came across a great LinkedIn Post by Hijmen Fokker on the complexities of securing a Kubernetes cluster, and how, due to complexity and a lack of understanding, most people run with an insecure setup.
This is one of the reasons we endeavor to make things simple in Portainer.
Our goal is to put complex activities within the reach of the everyday sysadmin, and when talking about Kubernetes that means critical actions like policies, security, governance, and compliance.
Let me quickly show you how Portainer helps address these issues raised.
Use Private Networking
By default, Kubernetes API’s and applications are all accessible publicly, over the internet. This increases the attack surface of your cluster.
Implement a private network and only expose the required endpoints.
100% agree here, unless there is a compelling reason why you need to expose your Kubernetes API to the world, don't. Ideally, you don't even expose the API outside of a dedicated "out of band" management network, and you use a secure mechanism to get into that isolated network. We kept our VMware clusters on OOB networks, we keep our network switches on OOB networks, and we keep our firewalls on OOB networks, so why oh why would it all of a sudden be a good idea to put your Kubernetes API (which equates to a management network) on the public internet? Clue: It's not.
Portainer deploys an Agent inside each managed Kubernetes cluster, and that Agent communicates with the Kubernetes API via its internal IP. When using Portainer, you can block all access to your Kubernetes API from outside the cluster, ensuring security of your management interface. Of course, if you need to access the management control of the cluster remotely, you can do this securely through Portainer's Kubernetes API Proxy.
Set up the right RBAC
Not all engineers need administrator access to the cluster. Especially when you implement GitOps, for most engineers “Read-only” access is sufficient. This can be implemented using Kubernetes roles.
Always use the principle of least privilege.
Also, 100% agree. The amount of times I see "everyone's an admin" because configuring users, user auth, and RBAC in Kubernetes was seen as "too hard" is simply crazy. It's very common to see the default Kubernetes Admin token passed around and used by everyone in a Dev/Ops team. You cannot configure RBAC if you do not have user accounts defined, and you cannot define user accounts without some sort of user integration (eg OIDC) for Kubernetes.
Portainer acts as the centralized user authentication and authorization engine for Kubernetes. When a user is created in Portainer, and granted access to a Kubernetes cluster, we automatically create a shadow user in the cluster, and then assign an RBAC role to that user. Which RBAC role? It depends which of the pre-defined Portainer RBAC roles have been assigned to the user. Portainer makes user authentication and RBAC assignment a very simple task, and does not require any advanced Kubernetes knowledge to achieve this.
Minimize Vulnerabilities
Especially when using open source software, patching vulnerabilities is critical for a secure environment.
Yes, this is good practice, and should form a core component of your CI process. Images from companies like Chainguard are always a good place to start.
Portainer lets you define the registries that users can leverage for their deployments, so you can define only your trusted internal registries, and disallow access to all others.
Don't use passwords
Using a central Identity and Access Management (IAM) solution is important. Passwords should not be used anywhere.
For sure, you should never use passwords stored inside an authenticator deployed in the cluster, you should always rely on an external authentication source for your user repository.
Portainer is a centralized user authentication engine, but obtains the user authentication from upstream repositories such as LDAP/MS AD, or any OAuth source, even if this is configured with MFA and conditional access policies.
So, the original author of the post is spot on - take the security of your cluster seriously. And if you want an easy way to get it done, take a look at Portainer.
COMMENTS