When do I need a ClusterRole instead of a Role?

A Role's permissions are scoped to a single namespace; a ClusterRole's permissions apply cluster-wide (or, when bound with a RoleBinding instead of a ClusterRoleBinding, can be reused namespace-by-namespace). Use ClusterRole for cluster-scoped resources like Nodes or PersistentVolumes, or when you want one set of rules reusable across many namespaces.

What goes in apiGroups for core resources like Pods and Services?

Core API resources (Pods, Services, ConfigMaps, Secrets, Namespaces, and others in the legacy 'v1' group) use an empty string `""` for apiGroups, not 'core' or 'v1'. Named API groups like apps (Deployments, StatefulSets) or batch (Jobs, CronJobs) use their actual group name.

Why does a ServiceAccount subject need a namespace but a User or Group doesn't?

ServiceAccounts are namespaced Kubernetes objects, so identifying one requires both name and namespace. Users and Groups in RBAC aren't Kubernetes API objects at all, they're identities asserted by whatever authentication method you use (a client cert's CN, an OIDC token's claims, etc.), so there's no namespace to specify.

Can a RoleBinding reference a ClusterRole?

Yes, this is a common pattern: define reusable permission sets as ClusterRoles, then grant them within a single namespace by pointing a namespace-scoped RoleBinding's roleRef at that ClusterRole. This tool keeps the roleRef's kind matching the scope you chose (Role with RoleBinding, ClusterRole with ClusterRoleBinding) for simplicity; swap the binding's roleRef.kind by hand if you need this mixed pattern.

RBAC Role/ClusterRole + Binding YAML Generator

Overview

Introduction

RBAC in Kubernetes is always two objects working together, a Role or ClusterRole that defines what actions are allowed, and a RoleBinding or ClusterRoleBinding that grants those actions to a specific subject, and keeping the two in sync by hand (matching names, matching scope) is a common source of 'why can't this ServiceAccount do the thing I gave it permission for' bugs.

This tool generates both objects together as a single two-document YAML output, so the Role/ClusterRole and its binding always reference each other correctly.

What Is Kubernetes RBAC Generator?

A form-based generator for the paired RBAC objects: `rbac.authorization.k8s.io/v1` Role or ClusterRole (your choice via a scope toggle), plus a matching RoleBinding or ClusterRoleBinding.

It supports repeatable rule rows (apiGroups, resources, verbs, each as comma-separated lists) and a single subject of type ServiceAccount, User, or Group.

How Kubernetes RBAC Generator Works

The scope toggle (Role vs ClusterRole) determines both which resource kind is generated and, automatically, which binding kind pairs with it (RoleBinding for Role, ClusterRoleBinding for ClusterRole), keeping the two consistent without a separate choice to get wrong.

Each rule row's comma-separated apiGroups/resources/verbs are parsed into YAML flow-sequence lists; an empty apiGroups entry is rendered as `[""]`, matching how the core API group is represented in real Kubernetes manifests.

When To Use Kubernetes RBAC Generator

Use it whenever a workload's ServiceAccount, or a specific human user or group, needs a scoped, auditable set of API permissions rather than broad cluster-admin access.

It's especially useful for granting a controller or operator's ServiceAccount exactly the verbs and resources it needs (e.g. get/list/watch on Pods) without hand-tracking two separate, easy-to-desync YAML documents.

Often used alongside Kubernetes NetworkPolicy Generator.

Features

Advantages

Generates the Role/ClusterRole and its binding as one coherent pair, eliminating name or scope mismatches between the two.
Parses comma-separated rule fields into proper YAML lists, including the core-API-group empty-string edge case.
Supports all three subject kinds with the correct required fields for each (namespace only for ServiceAccount, apiGroup for User/Group).

Limitations

Generates one subject per binding; grant the same Role/ClusterRole to multiple subjects by adding entries to the binding's `subjects` list by hand.
Doesn't support `resourceNames` (restricting a rule to specific named objects) or non-resource URLs, both less common, more advanced rule fields.

Examples

A namespaced Role granting read-only Pod access to a ServiceAccount

Input

scope: Role, name: pod-reader, namespace: monitoring, rules: [{apiGroups: '', resources: pods, verbs: 'get, list, watch'}], subjectKind: ServiceAccount, subjectName: monitoring-agent, subjectNamespace: monitoring

Output

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: monitoring
rules:
  - apiGroups: [""]
    resources: [pods]
    verbs: [get, list, watch]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader
  namespace: monitoring
subjects:
  - kind: ServiceAccount
    name: monitoring-agent
    namespace: monitoring
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

The ServiceAccount monitoring-agent can get, list, and watch Pods within the monitoring namespace only, and nothing else.

Best Practices & Notes

Best Practices

Grant the narrowest set of verbs and resources the workload actually needs; avoid wildcard ('*') verbs or resources unless you genuinely mean 'all current and future resources'.
Prefer Role/RoleBinding over ClusterRole/ClusterRoleBinding whenever the permission only needs to apply in one namespace, limiting blast radius if the subject is ever compromised.
Name the Role/ClusterRole descriptively after what it grants (e.g. pod-reader, deployment-editor) rather than after the subject that happens to use it first, since roles often end up reused.

Developer Notes

Comma-separated rule fields are split on commas and trimmed, with empty entries filtered out; an apiGroups value of an empty string is preserved as a single-element array containing the empty string (`[""]`), which is how the Kubernetes API represents the core API group, rather than being treated as 'no apiGroups specified'. The binding's `roleRef.apiGroup` is always `rbac.authorization.k8s.io`, the only valid value for that field regardless of Role/ClusterRole scope.

Kubernetes RBAC Generator Use Cases

Granting a controller or operator's ServiceAccount exactly the API permissions it needs to function
Giving a CI/CD pipeline's ServiceAccount deploy permissions scoped to a single namespace
Granting a human user or group read-only or edit access to a specific namespace's resources

Common Mistakes

Using the string 'core' or 'v1' for apiGroups instead of an empty string, which the API server rejects for core resources like Pods and Services.
Binding a ClusterRole with a RoleBinding when cluster-wide access was actually intended, silently limiting the grant to one namespace.
Forgetting the ServiceAccount subject's namespace field, which is required and easy to omit since User/Group subjects don't need it.

Tips

Pair this with a NetworkPolicy generated for the same workload: RBAC controls what the workload's identity can do to the Kubernetes API, NetworkPolicy controls what network traffic it can send and receive.

Kubernetes RBAC Generator