Kubernetes Users and Groups Inside vs Outside of Portainer

We’re all users, right? Whether it’s an internal application at a company, or a third-party application, or even an app that has nothing to do with your company. For example, you may not work at Google, but you’re perhaps a Gmail user.

In any case, managing users and overall authentication are incredibly crucial to any environment's success. When it comes to Kubernetes, it’s just as important.
In this blog post, you’ll learn a little bit about user and team (group) authentication in Kubernetes and how it all works.

Kubernetes User Management

In one of the previous blog posts in this series, Standalone RBAC vs Portainer RBAC (FIGHT!), you saw the “Linux” way of creating users. Essentially, you create a Linux user, give the user certain permissions/certs, and give the user the ability to authenticate to a Kubernetes cluster.

The reason why you saw that is because Kubernetes doesn’t have an out-of-the-box way to manage users.

Why?

Because it’s not the job of Kubernetes to manage users or groups. The only reason Kubernetes gives you a way to manage Service Accounts is because Service Accounts are needed to run Pods. Outside of that, how you decide to authenticate to Kubernetes is up to you.

That is where engineers started to see an uptick in Kubernetes user management with OpenID Connect (OIDC) standards. Okta, Azure Active Directory, AWS IAM, and a few other ways are extremely popular when creating users and groups for Kubernetes.

Keep in mind that it’s still not a “native” approach, however.

Before jumping into the more popular solutions, let’s look at the “Linux native” way of user management for Kubernetes. 

First, create a new user and create a home directory for the user.

Once the _csr and _key are generated for the user, you can create a certificate and ensure that the certificate has an expiration time (which is a hassle to manage in itself).

Finally, you can specify the Kubernetes context you want to use for the user. Essentially, this is the step that you’re creating authentication rights inside of the Kubeconfig for your Kubernetes cluster.

In short, this, for standard production-level reasons, isn’t an appropriate or effective way to manage users. If you have 500 users using Kubernetes, no engineer wants to spend their time managing all of the certs, keys, and groups. It simply doesn’t scale and it’s a ton of overhead when other tools/platforms do the same thing, but way easier and in a far more efficient fashion. Imagine managing 500 expiring certs for users? This exact reason is why Active Directory has been the leader in authentication for many years.

Instead, it makes much more sense from a production perspective to manage users and groups via an OIDC solution.

A More Production Ready Solution

Now that you saw the cumbersome, yet effective way to manage users in Linux for Kubernetes, let’s take a look at a more production-focused solution for Kubernetes using Azure Active Directory.

If you don’t have Azure, that’s fine. You don’t need to follow along from a hands-on perspective. This section is more to showcase how engineers are doing it in the real world and how it matches up against Portainer.

In any AKS cluster, you’ll see an option for Access control (IAM).

When you click on IAM, you have two options - one to view your access and one to check other people’s access.

Checking another engineer's access is great as you have the ability to see what they can and cannot do from an authentication and authorization perspective inside of the AKS cluster. This is a great resource for ensuring that whoever has access should have access, and whoever doesn’t, doesn’t.

If you need to add someone, you can easily add them by going to + Add —> Add role assignment.

You can then choose a specify role assignment (think RBAC) for the user.

Then, you can choose which user you want to give the Role to.

As you can see, it’s a pretty straightforward solution, easy to use, and quite good. After all, Active Directory has been around for a long time, so it’s a great authentication platform overall.

The Problem

Although great, there are a few concerns with a solution like Azure Active Directory or another OIDC solution.

The first is that you have to be part of a particular platform already. For example, chances are organizations aren’t going to spend the money to get Azure up and running just to use Azure Active Directory. Although it would be beneficial, leadership teams may not see it that way.

Second, you may have to pay for the solution. For example, if you’re thinking about an authentication platform like Okta, an organization has to pay just for authentication. 

Therefore, it may not be in the budget for certain organizations.

Third, it leaves something to be desired from a centralized management perspective. If you’re using all of these different tools and platforms to connect to Kubernetes, and you’re only using a certain part of the platform for a specific purpose (like just using Azure for Azure Active Directory), there’s going to end up being a ton of management overhead and engineers will be assigned to focus on particular platforms that only serve one purpose.

Although almost all OIDC solutions like Azure Active Directory and Okta are phenomenal choices, and even a recommendation in many cases from all engineers, if you’re using Portainer or want to use Portainer for other types of orchestration management, user and team (group) management is already built into the platform.

Portainer Users and Teams (Groups)

Now that you’ve seen user management in a popular OIDC solution like Azure Active Directory, let’s take a look at managing users and teams in Portainer.

In Portainer, under settings, click on Users.

Next, type in a username, password, and specify if you want the user to be an admin or not. After you type in your options, click the blue + Create user button.

As you can see, the user is now created.

To create a new team - under Settings, click on Teams.

Give the team a name and choose the team leader (the group admin). Once complete, click the blue + Create team button.

As you can see, the team now exists.

And just like that, with far fewer steps than any option we’ve seen in this blog post, and quite frankly, almost any other option out there, a new user and team has been created.

Portainer is all about making Kubernetes easy to manage. Kubernetes in itself is already complex, so performing actions like user and group/team management shouldn’t be. Because of that, Portainer puts an extreme emphasis on making Kubernetes (and every other orchestration platform) easy to manage.

Conclusion

In today’s world, it wouldn’t make sense to simply use Portainer specifically for user and group management. Although it works great, there are plenty of other methods that are built into a lot of cloud systems that can help you and you don’t have to go to an outside service.

However, if you want a true way to manage orchestration, so you decide to go with Portainer, you might as well take advantage of the user and group management because it’s easy to use, it’s built-in, and you don’t have to worry about having your orchestration management methodologies spread across multiple platforms.

Try Portainer

If you'd like to give Portainer a try, you can get 3 nodes free here.