Generador K8s RBAC

Generador de YAML para Kubernetes RBAC Role y ClusterRoleBinding

Diseñe manifiestos de Kubernetes RBAC para Role, ClusterRole, RoleBinding y ClusterRoleBinding con grupos de API, verbos de recursos y cuentas de servicio.

Plantillas:
Configuración de Roles y Sujetos RBAC
Ámbito RBAC (Role frente a ClusterRole)Ámbito de Namespace
RoleBinding
Sujetos de RoleBinding (Usuarios, Grupos, ServiceAccounts)
rbac.authorization.k8s.io
rbac.authorization.k8s.io
Reglas de Política RBAC (apiGroups, resources, verbs)2
#1Regla #1: pods, pods/log, events
#2Regla #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
Reglas de Política
Role (Namespace: staging)
Sujetos Vinculados
2 Sujetos (0 SA, 2 User/Group)
Ámbito RBAC
Grado A: Reforzado y delimitado

Estándar rbac.authorization.k8s.io/v1

Cumplimiento estricto de las especificaciones rbac.authorization.k8s.io/v1 para Roles con ámbito de namespace y ClusterRoles globales.

Privacidad 100% en el Navegador

Todas las políticas RBAC, cuentas de servicio y permisos de clúster se generan íntegramente dentro de su navegador sin envíos a servidores.

Privilegio Mínimo y Listo para Producción

Genera manifiestos listos para producción con auditoría de seguridad de privilegios mínimos contra riesgos de comodines y escalada de privilegios.

Referencia técnica y guía de arquitectura

Guía para Desarrolladores del Generador YAML de Kubernetes RBAC Role y ClusterRoleBinding — Guía de referencia

Diseñe manifiestos de Kubernetes RBAC para Role, ClusterRole, RoleBinding y ClusterRoleBinding con grupos de API, verbos de recursos y cuentas de servicio.

Parámetros clave y controles

kindstring

Define el tipo de recurso RBAC ('Role', 'ClusterRole', 'RoleBinding' o 'ClusterRoleBinding').

Por defecto: Role
rules[].apiGroupsarray[string]

Grupos de API de Kubernetes que contienen los recursos (utilice '""' para recursos principales como pods/services, 'apps' para deployments).

Por defecto: [""]
rules[].resourcesarray[string]

Nombres en plural de los recursos de Kubernetes a los que se otorgará acceso (ej. 'pods', 'configmaps', 'deployments', 'secrets').

Por defecto: ["pods"]
rules[].verbsarray[string]

Verbos de acción permitidos sobre los recursos ('get', 'list', 'watch', 'create', 'update', 'patch', 'delete').

Por defecto: ["get", "list"]
subjectsarray[object]

Lista de entidades (ServiceAccount, User o Group) a las que se otorgan permisos en un RoleBinding.

Por defecto: Required for Bindings
roleRefobject

Referencia que apunta al Role o ClusterRole que se está asignando mediante RoleBinding o ClusterRoleBinding.

Por defecto: Required for Bindings

Consejos profesionales y mejores prácticas

Evitar comodines en permisos

Evite los comodines ('*') en verbos y recursos; otorgue explícitamente solo verbos de lectura ('get', 'list', 'watch') a menos que las operaciones de escritura sean estrictamente necesarias.

Vincular ClusterRole a namespace

Defina permisos genéricos en un ClusterRole y referéncielo en un RoleBinding con espacio de nombres para limitar dichos permisos exclusivamente a ese espacio de nombres.

Validar permisos con auth can-i

Valide sus políticas RBAC ejecutando 'kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<name>' antes de desplegar cargas de trabajo.

Errores comunes y solución de problemas

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

Verifique que 'rules[].apiGroups' coincida exactamente ('' para recursos básicos, 'apps' para deployments) y que el nombre del recurso esté en plural ('services', no 'service').

RoleBinding no otorga acceso a recursos de otros espacios de nombres

Un RoleBinding solo puede otorgar permisos dentro de su propio espacio de nombres. Si requiere acceso en todo el clúster, utilice ClusterRoleBinding o cree RoleBindings individuales por cada espacio de nombres.

Preguntas frecuentes (FAQ)

¿Cuál es la diferencia entre un Role y un ClusterRole en Kubernetes?▼

Un Role restringe sus permisos a un único espacio de nombres (namespace), mientras que un ClusterRole tiene alcance en todo el clúster, permitiendo gestionar recursos globales como Nodes y PersistentVolumes.

¿Puede un RoleBinding hacer referencia a un ClusterRole?▼

Sí, es una práctica recomendada estándar. Permite definir reglas de acceso comunes una sola vez en un ClusterRole y aplicarlas únicamente dentro del namespace del RoleBinding.

¿Por qué los recursos principales como Pods y Services usan una cadena vacía en apiGroups?▼

En la arquitectura de la API de Kubernetes, los recursos fundacionales pertenecen al grupo de API principal (core), el cual se representa canónicamente con una cadena vacía ("") en los archivos YAML.

¿Cómo restringir permisos a una instancia de recurso específica por su nombre?▼

Puede definir el campo 'resourceNames' en la regla (por ejemplo: resourceNames: ['mi-configmap']), lo que limita las acciones únicamente a esa instancia nombrada.

Herramientas y utilidades relacionadas

Todas las herramientas →