Kubernetes RBAC Generator

A dashboard that watches Pods needs different Kubernetes permissions from a deployment service that changes them. Giving both broad access can let an observing application change live resources. Kubernetes role-based access control (RBAC) expresses the API operations an identity may perform, so access can follow the work an application actually does.

Authentication establishes the identity making a request. Authorization decides whether that identity may perform the requested action. An application commonly authenticates as a ServiceAccount, while its RBAC rules determine which Kubernetes resources it can read or change. Possessing credentials and having permission are separate requirements.

Namespace

A named scope that separates resources such as Pods and ConfigMaps. A Pod named web in one namespace is separate from a Pod with the same name in another.

ServiceAccount

A named identity for workloads or automation. Its namespace is part of its identity.

Role

A set of permission rules within one namespace. Each rule identifies resources and the operations allowed on them.

RoleBinding

The object that grants a Role's permissions to a subject, such as a ServiceAccount. Creating a Role alone does not assign its permissions to an application.

For an application that observes Pods, the usual object-reading verbs are get, list, and watch. They cover reading an individual Pod, listing Pods, and following changes. Access to Pod logs or command execution is expressed separately through subresources such as pods/log and pods/exec. Permission to read a Pod does not automatically include those capabilities.

The resource, operation, namespace, and sometimes the object name all affect the grant. Reading one ConfigMap may require a narrower rule than watching every Pod in a namespace. Resources from different API groups also need the correct group identity, such as the core group for Pods and apps for Deployments. A Role cannot grant access to cluster-scoped objects such as Nodes. ClusterRole-based arrangements serve broader or reusable permission requirements.

Permissions from applicable RBAC rules and bindings accumulate. Adding a narrow Role does not cancel a broader grant elsewhere, and leaving an operation out of one rule does not create a deny rule. Least privilege therefore requires reviewing the account's existing access as well as the new permissions, then checking which operations the application actually needs.

Small grants can still have substantial consequences. Reading Secrets may reveal credentials, and permission to create workloads can allow access to mounted Secrets and other ServiceAccount identities. Restricting the namespace helps define the API scope, but the effect of a permission also depends on the resources and workloads reachable within it.

How to Use This Tool:

Prepare one Role and a matching RoleBinding for an existing ServiceAccount in one namespace. Results update as you edit. The starting demo example is synthetic, and the generator does not create the namespace or account.

1. Enter the Namespace, Role name, and ServiceAccount name for the intended workload. The same namespace is used throughout. Under Advanced, leave Binding name override blank to use the Role name followed by -binding, or enter a separate binding name.
2. Choose an API group and enter the supported plural tokens in Resources, separated by spaces or commas. Use Core (empty group) for resources such as pods and configmaps. The supported resource list changes with the group.
3. Select the required Verbs and, when appropriate, enter exact names in Resource names (optional). Every selected verb applies to every resource in that rule. Use Add rule when another group, verb set, or name restriction needs a separate grant. Rules can also be duplicated or removed.
4. Review the Grant ledger and its capability-specific cues when the summary reads Namespaced draft ready for review.
   If the summary reads Permission inputs need attention, correct the identified field or rule. Successful outputs disappear while the input is invalid, and your entries remain editable. Changing an API group keeps the existing resource text, so it may need correction too.
5. Copy or download the reviewed RBAC YAML and the Authorization checks text for your own review process. YAML and TXT downloads preserve those respective outputs. The commands remain text until you choose to run them in your own environment.

Interpreting Results:

The ready summary confirms that the inputs satisfy the generator's supported syntax and rule restrictions. It does not prove least privilege or live authorization. The ServiceAccount's existence and the operations supported by the cluster still need verification.

The Grant ledger records each rule's exact API group, resources, verbs, and name restrictions. All names means that the rule has no object-name restriction. Review cues identify specific capabilities that deserve attention. They are not a security score or certification, and a general reminder does not establish that a grant is low risk. The ledger can accompany a review as CSV or DOCX, and individual rows can be copied.

In the Verb matrix, Included means a verb appears in that draft rule. A dash, or Not in this rule in the backing data, means it is absent from that rule. Neither is a measurement of live access, and an absent cell is not a global deny. PNG, WebP, and JPEG exports preserve the visual comparison; the backing CSV preserves the exact membership labels with the rule's group, resources, and names. If the matrix cannot display, the ledger still contains every grant.

Authorization checks contains kubectl auth can-i commands for the specified ServiceAccount. Running them requires access to the intended cluster, the correct kubeconfig context, and permission to impersonate that account with --as. They query current authorization, including other applicable bindings. An unapplied YAML draft does not change their answers, and the generator promises no particular yes or no result.

Because an authorization check asks about permission without performing the requested operation, a positive answer does not establish that the object exists, the endpoint supports that operation, or admission controls will accept a real request. Verify the application's actual requests in the intended environment as well as reviewing its existing bindings.

Technical Details:

RBAC authorization matches a request against permission rules available to its identity. A matching rule must cover the request's API group, resource or subresource, verb, and any required object name within the applicable namespace. Any applicable rule matching all these conditions supplies an RBAC grant.

Rule Core

A RoleBinding makes its referenced Role available to the listed subject. Within that Role, the following fields describe which requests each rule permits.

Combining pods and configmaps with get and patch permits both verbs on both resources. To allow Pod reads and ConfigMap changes separately, use separate rules. Rule order does not create priorities or exceptions, and an overlapping unrestricted grant can make a narrower name restriction ineffective for the account's overall RBAC access.

Role, binding, and subject consistency

The generated YAML contains exactly two documents separated by ---, a Role and a RoleBinding, both using rbac.authorization.k8s.io/v1. Names and rule values are quoted strings. The selected namespace appears in both objects' metadata and in the ServiceAccount subject.

The binding's roleRef uses apiGroup: rbac.authorization.k8s.io, kind: Role, and the emitted Role's exact name. The subject uses kind: ServiceAccount with its name and namespace, and omits apiGroup. Changing the binding-name override affects only the binding's metadata name, leaving its reference, subject, and grants unchanged.

A RoleBinding that references a Role must use a Role in its own namespace. Kubernetes also permits ServiceAccount subjects from other namespaces, but this generator deliberately keeps the Role, RoleBinding, and ServiceAccount subject in one namespace. Existing bindings have an immutable roleRef, so reusing a binding name does not permit an in-place switch to a different Role.

Verbs and object-name restrictions

The eight supported verbs describe API operations. For ordinary object requests, their meanings and name-restriction behavior are as follows. Connection subresources, such as command execution, need separate attention because the verb alone does not describe the capability's impact.

Top-level creation cannot be restricted through resourceNames, because the new object's name is not available as the required authorization attribute. A named subresource request already identifies its parent object. This allows a rule for create on pods/exec to restrict the parent Pod by name. A rule mixing pods and pods/exec with create and a name restriction is rejected because it also includes top-level creation.

For named list and watch, the client must request one allowed name through a field selector such as metadata.name=app-config. RBAC does not turn a broad collection request into a filtered response. A can-i check containing an object name does not exercise the application's field selector. Object-name restrictions also do not select labels or restrict individual fields or keys inside an object.

The resource catalog and verb list are checked independently. A permitted combination in the draft does not establish that a corresponding operation exists on the cluster. Subresource support and the requests made by a particular client still require verification.

Capabilities that need closer review

Review cues follow the selected resources and operations. Their purpose is to draw attention to concrete consequences, including the following.

• Access to secrets can expose credentials or change trusted data. Collection reads and watches can reveal Secret contents as well as individual reads.
• pods/exec, pods/attach, and pods/portforward provide sensitive access to running workloads. A name restriction narrows the targets without making that access harmless.
• Creation on serviceaccounts/token can request credentials for a ServiceAccount. The account being targeted matters as much as the verb.
• Creating, updating, or patching workloads can enable code to run with mounted Secrets or namespace ServiceAccount identities. Changes involving pods/ephemeralcontainers also deserve this review.
• Changes to serviceaccounts can affect workload identity configuration. Deletion permissions can remove live resources.
• The default ServiceAccount is used by Pods without an explicitly assigned account. A binding to that identity may affect several workloads.

Supported API groups and resources

Each rule accepts one of the following groups and only the tokens listed for it. Subresources must be written in full with their slash. This is the generator's explicit catalog, not a complete inventory of every Kubernetes API.

Wildcards, unknown or custom groups, unlisted resources and subresources, and cluster-scoped resources are excluded. The generator does not produce ClusterRoles, ClusterRoleBindings, aggregated roles, non-resource URL rules, or grants to administer RBAC policy. The verbs impersonate, bind, and escalate are also excluded. These exclusions do not remove the need to review the sensitive supported capabilities above.

Identifier and rule bounds

The accepted names use a deliberately restricted lowercase DNS-style form. These are the generator's input limits. Kubernetes naming requirements vary by object type and must also be checked before use.

Identifiers are not silently lowercased or repaired. Spaces around identity names, uppercase letters, underscores, and unsupported punctuation are rejected. Resource and name lists allow commas or whitespace as separators, but duplicate entries within a rule are rejected. Duplicating a whole rule keeps it as a separate rule rather than combining it with an existing one.

The Resources field allows up to 1,000 characters and the Resource names field up to 5,080 characters per rule. The complete rule configuration is limited to 30,000 characters, and generated YAML is limited to 65,536 UTF-8 bytes, or 64 KiB. Unsupported configuration produces no successful manifest.

How authorization targets are represented

In kubectl auth can-i, a non-core resource includes its group, such as deployments.apps. A restricted object name follows a slash, while a subresource uses the separate --subresource option. Each generated check includes the namespace and the ServiceAccount identity, such as system:serviceaccount:demo:app-reader, with quoted arguments. Checks cover every selected resource, verb, and supplied name, or an unnamed target when names are unrestricted.

Privacy Notes:

Generation and input validation run in your browser. No cluster credentials are requested, and there is no remote cluster validation. The tool provides no saved draft history and does not execute kubectl or apply the YAML.

A shared page URL can contain the namespace, Role and ServiceAccount names, permission rules, resource names, and binding-name override. The address updates as you edit, so a configured URL may remain in browser history. Sharing or reopening it discloses the configuration to its recipient or to the server handling that page request. Browser-local generation does not make URL-carried data confidential. The matrix may also need an additional network download when first opened.

Worked Examples:

References:

• Using RBAC Authorization, Kubernetes.
• Authorization, Kubernetes.
• kubectl auth can-i, Kubernetes.
• Role Based Access Control Good Practices, Kubernetes.
• Service Accounts, Kubernetes.
• Object Names and IDs, Kubernetes.
• How to grant Kubernetes namespace access with RBAC, Simplified Guide.
• How to assign a Kubernetes ServiceAccount to a pod, Simplified Guide.