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