Granting Access as a Release Manager

Defining the Role

John loves the idea of having his own Namespace. He’ll use it as his playground. However, there’s one more thing he’s missing.

He happens to be a release manager. Unlike his other fellow developers, he’s in charge of deploying new releases to production. He’s planning to automate that process with Jenkins. However, that will require a bit of time, and until then he should be allowed to perform deployments manually. We already decided that production releases should be deployed to the default Namespace, so he’ll need additional permissions.

After a short discussion, we decided that the minimum permissions required for the release manager is to perform actions on Pods, Deployments, and ReplicaSets. People with that role should be able to do almost anything related to Pods, while the allowed actions for the Deployments and ReplicaSets should be restricted to create, get, list, update, and watch. We don’t think that they should be able to delete them.

We’re not entirely confident that those are all the permissions release managers will need, but it’s a good start. We can always update the role later on if the need arises.

John will be the only release manager for now. We’ll add more users once we’re confident that the role is working as expected.

Creating the Role Binding

Now that we have a plan, we can proceed to create a role and a binding that will define the permissions for release managers. The first thing we need to do is to figure out the resources, the Verbs, and the API Groups we’ll use.

Exploring the Cluster Role admin

We might want to take a look at the Cluster Role admin for inspiration.