A Kubernetes RBAC (Role-based access control) journey usually starts at small workloads, featuring a handful of Users and minimum viable clusters. At a small scale, everyone is granted admin rights to keep management simple. However, as an organization changes, so does the rights each user is assigned with varying degrees of privilege. An Admin user assigns that role to users and/or teams which can be a complex process leading to high error rates.
The obvious approach is to use the Kubernetes internal resources such as Roles and RoleBindings to assign and edit these resources, but this has some functionality challenges:
- Manual configuration of roles. There is no tool to assign, revoke, or change what each role can do. This process is manual using YAML manipulations, which is complex.
- Lack of visibility into User access: There is no “view” tool to decipher what each role does. The only way to figure out what each role does is to stare at YAML.
In this article, we introduce Portainer as an easy-to-use tool to fully control and operate our Kubernetes cluster. We will compare the easy and error-free functionality of Portainer compared to using Kubernetes-native to write YAML files and manipulate them.
The idea is to have a discussion around both approaches to compare the complexities and error results between Portainer vs Kubernetes.
As a prerequisite, Portainer must be running and K8s cluster must be running and connected as an environment in Portainer.
Example of a very basic RoleBinding in Kubernetes:
Step 1: This should be the starting point. Let’s go.
Step 2: Add a user named “neil” into the system.
Step 3: Once we hit the “Create user” button, the page updates with the corresponding view:
Step 4: Same as step 3. Let's create some more users, so we can put them into the team!
Step 5: Now that we have more users, it makes sense to split them into teams. We can do this by using the Users->Teams tab, following the UI.
Step 6: Once teams are created, we can add users into them. Click on each team to see the team overview.
Step 7: Adding people on the team is also done by following the UI. This goes for removing them from the team too. We can also promote a team-member to a leader role. (Incidentally, we may have as many people on our team). This allows for you to assign more permissions.
Same as above. Here, we add members into other team we have, “r8s.”
Step 8: As teams are formed, we should assign role-based access policies to each team. Let's assign to both teams and include a specific user into that role.
Step 9: The user roles are described in Users->Roles tab, and we are able to pick the exact level of permission that suits our group.
Step 10: It's recommended to only assign one or a few Endpoint Administrators since the basis for RBAC is to be able to manage multiple users and teams with precise oversight because "everyone is an admin" is a bad idea.
Once the roles are assigned, we can view the access given to a particular endpoint / environment, with changes made granularly.
Step 11: Great! Now we have assigned the required roles to our users and achieved RBAC in Kubernetes.
Please note that Portainer does also create k8s RBAC resources, storing local data on its volume to reuse the same set of users, teams when managing other environments. This includes giving access to the “nemo” team to manage other clusters so they can work with zero-delay instead of crafting YAML files and applying them onto another cluster.
As basic K8s RBAC does support distribution of rights across various resources such as namespaces, Portainer does so as well.
To let a specific user or team to work with namespace, UI suggests we go to Namespaces, and 'Manage access' of the particular namespace.
Step 12: Also, Portainer helps us here with the UI dropdown – stating that with this namespace, we can only assign those users / teams who already have access to the cluster. In our case, it's two teams and a user who we have not given access to.
Step 13: Finally, there is also an opportunity to see all the accesses a particular user has, and the origins for them. This could be viewed under Users->Roles tab.
Step 14: As we expected, user “adolfo” does not have access to any resources. Instead, if we look at “sven,” we can see he can manage “local” resources as he is part of the “nemo” team.
This was a quick look into simplifying RBAC for Kubernetes using Portainer which has more features to offer to make functionality error proof. Portainer is truly a great alternative to the classic approach to RBAC in Kubernetes that is limited to using hand-crafted copy-pasted YAML files. Despite the fact that "Kubernetes is complex" and remains the de-facto and industry standard way of building distributed systems, Portainer can take the headache out of the complexities. RBAC is one of the things Portainer tackles well while reducing errors.
COMMENTS