Effective user authentication and authorization is a critical element of any container-based implementation (Kube or Docker) but as with anything Kube related, if you’re playing with native tools, it’s complicated. Really complicated...
For the uninitiated, setting up a user repository in Kubernetes, either internally, or through a connection to an external authentication store, is tricky. You need to install plugins, configure the connection, and then repeat for each and every cluster you manage. In addition, connecting Kubernetes to the authentication source is only half of the job, the other half is mapping (binding) authenticated users to roles. Kubernetes RBAC ensures that end users can only perform certain specific actions on specific namespaces /clusters. It’s critical to effective IT governance and stops all manner of bad things happening when everyone has Admin rights.
Natively, Kubernetes supports a number of different role types, which you can assign to a subject–eg Cluster Admin, Admin, Edit and View. These roles are perfectly practical, but hard to manage because Kubernetes doesn’t offer any automated tools to facilitate automatic granting of roles or updating of role bindings. That means admins must do everything manually namespace by namespace, cluster by cluster. In addition, Kubernetes offers no built-in tools for easily identifying which level of access a user has within a cluster which is an instant recipe for trouble when the team scales beyond a few users.
The challenge of managing RBAC gets exponentially harder when multiple clusters are involved, because RBAC–if you’re doing things manually–needs to be set up on a cluster by cluster basis. This is hugely labor intensive and error prone. To avoid the problem, some organizations are going as far as aligning individual users with individual clusters, which is wildly impractical and almost defeats the whole ‘cluster’ objective.
So, there’s got to be a better way, right?
Andy Magnussen outlines an alternative approach in his blog, which includes a simplified manual approach involving Service Accounts; but there’s also a third way.
At Portainer we have a long history with RBAC from our Docker/ Swarm history. We’ve been helping organizations manage, govern, and secure their containerized environment for years and we know what works and what doesn’t. Over the last year, we’ve been gradually porting our Docker know-how to Kubernetes and, in Portainer Business, we’ve got a fully-featured, fully supported RBAC solution for multi-cluster, large scale Kubernetes implementations that’s proving hugely popular with customers.
Portainer’s RBAC for Kubernetes functionality implements a standardized set of roles (Endpoint Admin, Helpdesk, Operator, Standard User, Read-Only User), which are maintained within Portainer, but created in the clusters automatically as they are onboarded into Portainer. To grant a user access to a cluster or namespace(s), a Portainer admin simply grants them access via Portainer, and Portainer takes care of the rest. Behind the scenes, we create a “shadow” user record within Kubernetes, create the role bindings, and ensure that their access is secured. Users simply log in to the Portainer UI, and either obtain their kubeconfig file to access the clusters directly, or they can immediately start deploying apps via our UI. No manual work is needed by an admin directly in Kubernetes.
With Portainer you can
- Connect to your external authentication stores (LDAP/AD, OAuth)
- Syncronize your external groups with Portainer Teams
- Allow users to login to Portainer that are members of specific groups
- Automatically place users into Portainer teams based on their group membership
- Assign access to Clusters either by team or person
- Assign RBAC roles to access, either by team or person
- Perform RBAC access overrides should there be a specific need to restrict access fora certain user within a team
What’s important about Portainer is that not only can you apply RBAC to our own GUI-based tool, you can also connect any third party dashboard, CI/CD tool to our RBAC and give developers/end-users the flexibility to ‘bring your own tool’ safe in the knowledge that usage is safe and secure.
As you would expect, RBAC is only one element of the Portainer Business solution set and there’s a raft of other security and governance-based features in it that are exposed to admins and users via a simple GUI (including the ability to restrict access to generic namespaces which is the subject of this related blog)
If you are interested in learning more this episode of our Portainerd series should be right up your street.
COMMENTS