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 ...