Rbac

Alright, let’s talk about the three roles you’ll actually use. You can read all the RFCs and design docs you want, but in the real world, 90% of your RBAC needs boil down to these three patterns. They’re the workhorses. Get these right, and you’ve basically won. The Read-Only Viewer This is your go-to for anyone who needs to see what’s going on but shouldn’t be able to change a single byte. Think auditors, support teams, or your manager who keeps asking “what’s running in the staging cluster?” You want to give them get, list, and watch on (almost) everything. The key here is to be explicit. Don’t just grant them view access cluster-wide; that default role is a sledgehammer that often includes seeing Secrets, which is a spectacularly bad idea.

Right, so you’ve got your RBAC all set up. Roles, bindings, the whole nine yards. It looks good on paper. But how do you know it’s doing what you think it’s doing? You don’t just deploy this stuff and hope for the best. You poke it with a stick. And the best stick for poking RBAC is kubectl auth can-i. This command is your RBAC truth-teller. It cuts through the YAML and tells you, for a specific user or service account, whether a specific action is permitted. It’s the difference between assuming your new intern can’t delete a production namespace and knowing it.

Right, let’s talk about designing RBAC with the principle of least privilege. This is where the rubber meets the road. It’s also where most people screw it up royally, creating either a security nightmare or a usability brick wall. The goal is simple: give an identity—a user, a service account, a pod—only the permissions it absolutely needs to do its job and not a single one more. It sounds obvious, but you’d be amazed how often this is handled with the subtlety of a sledgehammer.

Right, let’s talk about the unsung heroes and potential villains of your cluster: Service Accounts. You’ve been using them this whole time, probably without even knowing it. Every time you create a Pod, if you don’t explicitly tell it otherwise, the Kubernetes API server automatically mounts a magical token for the default service account in that Pod. It’s like the hotel key card you get at check-in without asking. This is both incredibly convenient and a security nightmare waiting to happen, which is a classic Kubernetes trope.

Right, so you’ve got the hang of regular ClusterRoles and Roles. You can build a neat little permission set, bind it to a user or a ServiceAccount, and call it a day. It’s straightforward, until your infrastructure starts to look less like a tidy garden and more like a jungle. You might have a dozen different controllers, each needing a slightly different set of permissions, and the thought of managing fifty near-identical ClusterRoles is enough to make you consider a career change.

Alright, let’s get down to the brass tacks of actually granting those permissions we so carefully defined in our Roles and ClusterRoles. Think of those objects as the menu of possible powers—detailed, but utterly useless just sitting there. A Role by itself does precisely nothing. It’s a recipe with no chef, a concert ticket with no venue. To make the magic happen, you need to bind that menu of powers to a user, a group, or (most commonly) a ServiceAccount. That’s the job of the RoleBinding and ClusterRoleBinding resources. They are the bouncers that look at your ID and say, “Alright, you’re on the list, come on in.”

Right, let’s talk about the two ways you tell Kubernetes who can do what. We have Role and ClusterRole. The difference is in the scope, and it’s the single most important concept to grasp here. If you mess this up, you’ll either be locked out of your own cluster or you’ll accidentally give the testing namespace the keys to the kingdom. Let’s avoid both outcomes. Think of it like this: a Role is a set of permissions for a specific neighborhood (a namespace), like being able to lock and unlock every door on Main Street. A ClusterRole is the same set of permissions, but for the entire city (the whole cluster), like being a master keyholder for every street. You wouldn’t give the master city key to someone who just needs to water the plants in one building. Kubernetes feels the same way.

Alright, let’s demystify the three core building blocks of RBAC. Forget the jargon for a second. At its heart, every single access control question boils down to answering this: “Who can do what to which thing?” RBAC is just a formal, manageable way to answer that. The “who” is the Subject, the “what” is the Verb, and the “which thing” is the Resource. Get these three concepts locked down, and the rest is just elegant (or sometimes infuriatingly inelegant) implementation.