Replacing Users With Groups

The User-Specific Namespace

Defining a single user that can access the jdoe Namespace was probably the best approach. We expect that only John will want to access it. He is the owner of that Namespace. It’s his private playground. Even if he chooses to add more users to it, he’ll probably do it independently from our YAML definitions.

After all, what’s the point of giving him god-like privileges if not to let him do things without asking for our permission or involvement? From our perspective, that Namespace has, and will continue having only one User.

Exploring the Prospective Roles

We cannot apply the same logic to the permissions in default and dev Namespaces. We might choose to give everyone in our organization the view role in the default Namespace. Similarly, developers in our company should be able to deploy, update, and delete resources from the dev Namespace.

All in all, we can expect that the number of users in the view and dev bindings will increase with time. Continually adding new users is repetitive, boring, and error-prone process you probably don’t want to do. Instead of becoming a person who hates his tedious job, we can create a system that groups users based on their roles. We already did a step in that direction when we created John’s certificate.

Let’s take another look at the subject of the certificate we created earlier.