Search⌘ K
Home
Courses
Learn Kubernetes: A Deep Dive

Cluster-Level Users and Permissions

Explore how Kubernetes handles cluster-level user permissions using ClusterRoles and ClusterRoleBindings. Understand the distinction between namespaced and cluster-wide roles, and how precreated roles like cluster-admin provide comprehensive access. Learn to interpret kubeconfig files and the role of certificate-based authentication in securing clusters.

We'll cover the following...

So far, we’ve seen Roles and RoleBindings. However, Kubernetes has four RBAC objects:

  • Roles

  • RoleBindings

  • ClusterRoles

  • ClusterRoleBindings

Roles and RoleBindings are namespaced objects. This means we apply them to specific Namespaces. On the other hand, ClusterRoles and ClusterRoleBindings are cluster-wide objects and apply to all Namespaces. All four are defined in the same API sub-group, and their YAML structures are almost identical.

A powerful pattern is to use ClusterRoles to define roles at the cluster level and then use RoleBindings to bind them to specific Namespaces. This lets us define common roles once and reuse them in specific Namespaces, as shown in the following figure.

Combining ClusterRoles and RoleBindings
Combining ClusterRoles and RoleBindings

The following YAML defines the read-deployments role from earlier, but this time at the cluster level. We can then use this in selected Namespaces via RoleBindings — one RoleBinding per Namespace.

YAML
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole                   <<==== Cluster-scoped role
metadata:
  name: read-deployments
rules:
- verbs: ["get", "watch", "list"]
  apiGroups: ["apps"] 
  resources: ["deployments"]

If we look closely at the YAML, the only difference ...