Granting Access as a Release Manager

Defining the role

John loves the idea of having their own namespace. They’ll use it as a playground. However, there’s one more thing that they’re missing.

They happen to be a release manager. Unlike their other fellow developers, they’re in charge of deploying new releases to production. They’re planning to automate that process with Jenkins. However, that will require a bit of time, and until then, they should be allowed to perform deployments manually. We have already decided that production releases should be deployed to the default namespace, so they’ll need additional permissions.

After a short discussion, we decide that the minimum permissions required for the release manager are 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 RoleBinding

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 ClusterRole admin

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