K8s RBAC Generator

Kubernetes RBAC Role & ClusterRoleBinding YAML Generator

Design Kubernetes RBAC Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources with API groups, resource verbs, and Subject service accounts.

Presets:
RBAC Role & Subject Configuration
RBAC Scope (Role vs ClusterRole)Namespace-Scoped
RoleBinding
Role Binding Subjects (Users, Groups, ServiceAccounts)
rbac.authorization.k8s.io
rbac.authorization.k8s.io
Policy Rules (apiGroups, resources, verbs)2
#1Rule #1: pods, pods/log, events
#2Rule #2: deployments, replicasets
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
  namespace: staging
  labels:
    app.kubernetes.io/part-of: developer-access
    env: staging
rules:
  - apiGroups:
      - ""
    resources:
      - "pods"
      - "pods/log"
      - "events"
    verbs:
      - "get"
      - "list"
      - "watch"
  - apiGroups:
      - "apps"
    resources:
      - "deployments"
      - "replicasets"
    verbs:
      - "get"
      - "list"
      - "watch"
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-log-reader-binding
  namespace: staging
  labels:
    app.kubernetes.io/part-of: developer-access
    env: staging
subjects:
  - kind: Group
    name: frontend-developers
    apiGroup: rbac.authorization.k8s.io
  - kind: User
    name: [email protected]
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-log-reader
  apiGroup: rbac.authorization.k8s.io
Policy Rules
Role (Namespace: staging)
Bound Subjects
2 Subjects (0 SA, 2 User/Group)
RBAC Scope
Grade A: Hardened & Scoped

rbac.authorization.k8s.io/v1 Standard

Strict compliance with rbac.authorization.k8s.io/v1 specifications for namespace-scoped Roles and cluster-wide ClusterRoles.

Sub-Millisecond AST Engine

All RBAC policies, service accounts, and cluster permissions are evaluated and generated entirely inside your browser sandbox.

Least Privilege & Production Ready

Generates production-grade manifests with least-privilege security auditing to prevent dangerous wildcard and privilege escalation risks.

Technical Reference & Architecture Guide

Kubernetes RBAC Role & ClusterRoleBinding YAML Generator — Reference Guide

Design Kubernetes RBAC Role, ClusterRole, RoleBinding, and ClusterRoleBinding resources with API groups, resource verbs, and Subject service accounts.

Key Parameters & Controls

kindstring

Defines the RBAC resource type: 'Role', 'ClusterRole', 'RoleBinding', or 'ClusterRoleBinding'.

Default: Role
rules[].apiGroupsarray[string]

Kubernetes API groups containing the target resources (use '""' for core resources like pods/services, 'apps' for deployments).

Default: [""]
rules[].resourcesarray[string]

Plural names of Kubernetes resources to grant access to (e.g. 'pods', 'configmaps', 'deployments', 'secrets').

Default: ["pods"]
rules[].verbsarray[string]

HTTP/API action verbs permitted on the resources ('get', 'list', 'watch', 'create', 'update', 'patch', 'delete').

Default: ["get", "list"]
subjectsarray[object]

List of entities (ServiceAccount, User, or Group) to which permissions are granted in a RoleBinding.

Default: Required for Bindings
roleRefobject

Reference pointing to the target Role or ClusterRole being assigned by a RoleBinding or ClusterRoleBinding.

Default: Required for Bindings

Pro Tips & Best Practices

Avoid Wildcard Permissions

Avoid wildcard asterisks ('*') in verbs and resources; explicitly grant only read-only verbs ('get', 'list', 'watch') unless mutation is strictly required.

Reuse ClusterRoles in Namespaces

Define generic permissions once in a ClusterRole, then reference it within a namespaced RoleBinding to restrict those permissions strictly to that single namespace.

Validate Policies with auth can-i

Test your newly applied RBAC policies immediately by running 'kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<name>' before deploying workloads.

Common Gotchas & Troubleshooting

Error 'is forbidden: User cannot list resource in API group'

Verify that 'rules[].apiGroups' contains the exact API group (e.g., 'apps' for deployments, '' for pods) and that the resource name is pluralized (e.g., 'services', not 'service').

RoleBinding fails to grant access across multiple namespaces

A RoleBinding cannot grant permissions outside its own namespace. Use a ClusterRoleBinding if cluster-wide access is required, or deploy identical RoleBindings across each individual target namespace.

Frequently Asked Questions

What is the difference between a Role and a ClusterRole?▼

A Role defines permissions within a single specific namespace, while a ClusterRole defines permissions across the entire cluster, including cluster-scoped resources like Nodes, Namespaces, and PersistentVolumes.

Can a RoleBinding reference a ClusterRole?▼

Yes. Binding a ClusterRole with a RoleBinding is a best practice. It applies the permissions defined in the ClusterRole only within the specific namespace of the RoleBinding.

Why do core resources like Pods and Services use an empty string for apiGroups?▼

In Kubernetes API architecture, legacy core resources belong to the core API group, which is canonically represented by an empty string ("") in YAML manifests.

How do I grant access to specific resource instances by name?▼

You can define the 'resourceNames' field in your rule (e.g., resourceNames: ['my-configmap']), restricting actions to only that specific named resource instance.

Related Tools & Utilities

All Tools →