Welcome to the NZRT Wiki Podcast. Today we’re looking at RBAC.

RBAC stands for Role-Based Access Control, and at its core it answers three questions: who are you, what are you allowed to do, and where in the system can you do it? Whether you’re a human user, a service account, or an automated process, RBAC is what decides your level of access inside a Kubernetes cluster.

Let’s start with the four main building blocks of RBAC, because understanding these will make everything else click into place.

The first is a Role. A Role is scoped to a single namespace, and it defines what permissions are allowed within that one namespace. Think of it as a job description that only applies to one department.

The second is a ClusterRole. This works the same way as a Role, but instead of being limited to one namespace, it applies across the entire cluster. So if you need someone to have permissions everywhere, ClusterRole is your tool.

The third object is a RoleBinding. This is the glue between a Role and a user, group, or service account. On its own, a Role doesn’t do anything — you need a RoleBinding to actually hand those permissions to someone. And like a regular Role, a RoleBinding is scoped to one namespace.

The fourth is a ClusterRoleBinding. Same idea as a RoleBinding, but it applies a ClusterRole across the whole cluster, not just one namespace.

So the pattern is: Roles and RoleBindings live in a namespace. ClusterRoles and ClusterRoleBindings operate cluster-wide.

Now let’s look at a real example — a Role definition for NZRT developers. This configuration creates a Role called nzrt-developer, sitting inside the nzrt-dev namespace. It defines two sets of rules. The first set covers pods, deployments, services, and config maps — and it grants the ability to get information about them, list them, watch for changes, create new ones, update existing ones, and patch them. The second set is specifically for pod logs and interactive pod sessions — and for those, only get and create are permitted. So developers get solid read and write access to the main workload resources, but nothing beyond what they need.

Next up is the RoleBinding that actually activates those permissions. This binding is called dev-binding, also in the nzrt-dev namespace. It points to a specific user — the developer at nzrtnetwork dot com email address — and it references the nzrt-developer Role we just described. The moment this binding exists, that developer account gains all the permissions defined in the Role, but only inside the nzrt-dev namespace. Outside that namespace, those permissions simply don’t apply.

There’s also a third type of object worth knowing about: a ServiceAccount. This is used when an application or automated process — rather than a human — needs to interact with the cluster. The example here creates a ServiceAccount called nzrt-app-sa inside the nzrt-prod namespace. You’d then bind a Role or ClusterRole to this service account just like you would with a user, so the application running in your cluster has exactly the access it needs and nothing more.

Now let’s talk about how you actually work with these objects day to day. There are a handful of commands you’ll use regularly. You can list all Roles inside a specific namespace — say, nzrt-prod. You can do the same for RoleBindings in that namespace. You can pull a full list of all ClusterRoles across the entire cluster. And there’s a particularly useful command that lets you ask a direct question: can this specific user create deployments in this namespace? You pass in the namespace and impersonate the user in question, and Kubernetes will tell you yes or no. That last one is invaluable for debugging access issues without having to log in as the affected user yourself.

So to pull it all together: RBAC gives you fine-grained control over who can do what and where. You define permissions in a Role or ClusterRole, you attach those permissions to people or processes using bindings, and you use service accounts when the entity needing access is an application rather than a person. The scope — namespace versus cluster-wide — determines how broadly those permissions reach.

If you want to go deeper, check out the Security Overview and Namespaces articles in the wiki — both are closely related to everything we’ve covered here today.

That’s it for this episode of the NZRT Wiki Podcast. Thanks for listening.