About the RBAC Generator
Kubernetes RBAC is four object types and one rule: permissions are purely additive, and there is no deny. A subject can do something if any binding grants it, which means the only way to take a permission away is to stop granting it somewhere. This generator builds the Role or ClusterRole and the binding that goes with it, so the apiGroups and resource names are correct the first time.
The distinction people get wrong is scope. A Role is namespaced and can only grant access to objects in its own namespace. A ClusterRole is cluster-scoped, but what it grants depends on how it is bound: bound with a ClusterRoleBinding it applies across every namespace, while bound with a RoleBinding it applies only within that one namespace. That last combination is the correct way to reuse a shared role definition without handing out cluster-wide access.
The other frequent mistake is the empty apiGroup. Core resources such as pods, services, secrets, and configmaps live in the group named by the empty string, not in a group called core, and a rule that names the wrong group silently grants nothing at all.
Frequently asked questions
When should I use a Role instead of a ClusterRole?
Use a Role whenever the permission should be confined to one namespace, which is most of the time. Use a ClusterRole for cluster-scoped resources such as nodes, persistent volumes, namespaces, and custom resource definitions, or when you want a single reusable definition that you then bind per-namespace with a RoleBinding.
Why does my ServiceAccount still get permission denied?
Work through four things in order. Is the binding in the same namespace as the ServiceAccount, and does its subject block name that namespace explicitly? Does the rule name the right apiGroup — the empty string for core resources? Does it list the right verb, remembering that list and watch are separate from get? And for subresources such as pod logs or exec, the resource is written with a slash, so pods/log is a distinct resource from pods.
What is the difference between get, list, and watch?
get retrieves one named object, list retrieves the whole collection, and watch opens a stream of changes. They are independent, and granting get does not grant list. Note that anything able to list a resource can read every object of that type in scope, which is why list on secrets is effectively read-everything.
How do I grant read-only access to a namespace?
Bind the built-in view ClusterRole with a RoleBinding scoped to that namespace. That reuses a maintained definition rather than hand-rolling a rule list, and it deliberately excludes secrets. If you hand-write a wildcard read rule instead, you are granting read access to secrets as well, which is rarely what was intended.
Can I deny a specific permission?
No. RBAC has no deny rules — permissions are strictly additive and the union of every binding that applies. To remove access you must remove or narrow the grants. If you need to reject requests that RBAC would otherwise allow, that belongs in an admission controller such as a ValidatingAdmissionPolicy or an OPA or Kyverno policy.