Creating Cluster Role Bindings

View access across the cluster#

We’ll change John’s view permissions so that they are applied across the whole cluster.

Instead of executing yet another ad-hoc kubectl commands, we’ll define ClusterRoleBinding resource in YAML format so that the change is documented.

Looking into the definition#

Let’s take a look at the definition in the crb-view.yml file.

Functionally, the difference is that, this time, we’re creating ClusterRoleBinding instead of RoleBinding. Also, we specified the apiGroup explicitly thus making it clear that the ClusterRole is RBAC.

Creation of ClusterRoleBinding#

We created the role defined in the YAML file, and the output confirmed that clusterrolebinding "view" was created.

We can further validate that everything looks correct by describing the newly created role.

The output is as follows.

Finally, we’ll impersonate John and validate that he can indeed retrieve the Pods from any Namespace.

The output is yes, thus confirming that jdoe can view the Pods.

We’re so excited that we cannot wait to let John know that he was granted permissions. However, a minute into the phone call, he raises a concern. While being able to view Pods across the cluster is a good start, he will need a place where he and other developers will have more freedom.

They will need to be able to deploy, update, delete, and access their applications. They will probably need to do more, but they can’t give you more information. They are not yet very experienced with Kubernetes, so they don’t know what to expect.

John is asking you to find a solution that will allow them to perform actions that will help them develop and test their software without affecting other users of the cluster.

Try it yourself#

A list of all the commands used in the lesson is given below.