RBAC, Role-Based Access Control, determina qué identidades pueden realizar acciones sobre los recursos de la API de Kubernetes.

Una autorización se compone de tres elementos:

Subject → RoleBinding → Role → reglas permitidas

• El Subject puede ser un usuario, grupo o ServiceAccount.
• El Role define verbos, recursos y grupos de API.
• El RoleBinding asigna esas reglas al Subject dentro de un namespace.

RBAC es aditivo: Kubernetes suma todos los permisos obtenidos mediante Roles, ClusterRoles y Bindings. No existen reglas RBAC de denegación capaces de retirar un permiso concedido por otro Binding. Documentación oficial.

Escenario de ejemplo

Se creará el ServiceAccount lector-operaciones en donweb-lab. Podrá:

• Leer y observar pods.
• Consultar logs de pods.
• Leer Deployments y ReplicaSets.

No podrá:

• Leer Secrets.
• Crear, modificar o eliminar workloads.
• Ejecutar comandos dentro de pods.
• Acceder a recursos de otro namespace.
• Leer recursos globales como Nodes o PersistentVolumes.

Role, ClusterRole y sus Bindings

Un RoleBinding puede referenciar un ClusterRole, pero solo concede sus permisos sobre recursos namespaced del namespace del Binding.

Usa Role y RoleBinding cuando el acceso no necesite salir de un namespace. Kubernetes recomienda preferir permisos namespaced y evitar ClusterRoleBindings innecesarios. Buenas prácticas RBAC.

Requisitos previos

• Cluster Kubernetes con RBAC habilitado.
• kubectl configurado con el contexto correcto.
• Permisos para crear ServiceAccounts, Roles y RoleBindings.
• Namespace de ensayo.
• Acceso administrativo alternativo para corregir errores.
• Una matriz previa de acciones que deben permitirse y denegarse.

Paso 1: comprobar contexto y permisos administrativos

kubectl config current-context
kubectl version
kubectl get namespaces

Comprueba si tu identidad puede administrar RBAC en el namespace:

kubectl auth can-i create serviceaccounts \
  -n donweb-lab

kubectl auth can-i create roles.rbac.authorization.k8s.io \
  -n donweb-lab

kubectl auth can-i create rolebindings.rbac.authorization.k8s.io \
  -n donweb-lab

No utilices una cuenta cluster-admin para las operaciones diarias. Evita también agregar usuarios a system:masters, ya que ese grupo evita las comprobaciones RBAC y no puede limitarse mediante Bindings.

Paso 2: crear el namespace de ensayo

kubectl create namespace donweb-lab \
  --dry-run=client \
  -o yaml \
  | kubectl apply -f -

Comprueba:

kubectl get namespace donweb-lab

Paso 3: definir la matriz de permisos

Antes de escribir YAML, documenta el contrato de acceso:

No empieces con permisos amplios para reducirlos después. Define primero las operaciones exactas que requiere la identidad.

Paso 4: crear el manifiesto RBAC

Guarda lo siguiente como rbac-lector.yaml:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: lector-operaciones
  namespace: donweb-lab
automountServiceAccountToken: false
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: lector-operaciones
  namespace: donweb-lab
rules:
  - apiGroups:
      - ""
    resources:
      - pods
    verbs:
      - get
      - list
      - watch

  - apiGroups:
      - ""
    resources:
      - pods/log
    verbs:
      - get

  - apiGroups:
      - apps
    resources:
      - deployments
      - replicasets
    verbs:
      - get
      - list
      - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: lector-operaciones
  namespace: donweb-lab
subjects:
  - kind: ServiceAccount
    name: lector-operaciones
    namespace: donweb-lab
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: lector-operaciones

El grupo de API vacío "" representa los recursos core, como pods. Los Deployments y ReplicaSets pertenecen al grupo apps.

pods/log es un subrecurso distinto de pods. Permitir get pods no concede automáticamente acceso a sus logs.

El valor automountServiceAccountToken: false evita que las credenciales se monten automáticamente en cualquier Pod que use esta identidad. Si un workload necesita realmente consultar la API, habilita el token de forma explícita en ese Pod y conserva los permisos mínimos.

Paso 5: validar sin persistir

kubectl apply \
  --dry-run=server \
  -f rbac-lector.yaml

Revisa las diferencias:

kubectl diff -f rbac-lector.yaml

kubectl diff devuelve código 1 cuando existen diferencias y un código mayor ante un error. No ocultes indiscriminadamente el resultado con || true.

Comprueba también que el API server reconoce los recursos:

kubectl api-resources \
  --api-group=rbac.authorization.k8s.io

Paso 6: aplicar y revisar los objetos

kubectl apply -f rbac-lector.yaml

Comprueba explícitamente los recursos RBAC. kubectl get all no los incluye:

kubectl get serviceaccount,role,rolebinding \
  -n donweb-lab

kubectl describe role lector-operaciones \
  -n donweb-lab

kubectl describe rolebinding lector-operaciones \
  -n donweb-lab

Revisa que el RoleBinding apunte al Role y ServiceAccount esperados.

Paso 7: probar los permisos permitidos

Define la identidad completa:

SA='system:serviceaccount:donweb-lab:lector-operaciones'

Comprueba pods:

kubectl auth can-i get pods \
  --as="$SA" \
  -n donweb-lab

kubectl auth can-i list pods \
  --as="$SA" \
  -n donweb-lab

kubectl auth can-i watch pods \
  --as="$SA" \
  -n donweb-lab

Comprueba el subrecurso de logs:

kubectl auth can-i get pods \
  --subresource=log \
  --as="$SA" \
  -n donweb-lab

Comprueba Deployments:

kubectl auth can-i list deployments.apps \
  --as="$SA" \
  -n donweb-lab

Todos deben responder:

yes

La opción --as requiere que quien realiza la prueba tenga permiso para impersonar esa identidad. Si recibes un error de impersonación, la prueba debe ejecutarla un administrador autorizado.

Paso 8: probar las denegaciones

Un diseño de mínimo privilegio no queda validado únicamente con pruebas positivas.

Secrets

kubectl auth can-i get secrets \
  --as="$SA" \
  -n donweb-lab

kubectl auth can-i list secrets \
  --as="$SA" \
  -n donweb-lab

Resultado esperado:

no

Los permisos list y watch sobre Secrets también pueden revelar su contenido, no solo sus nombres. Seguridad de Secrets.

Creación de workloads

kubectl auth can-i create pods \
  --as="$SA" \
  -n donweb-lab

kubectl auth can-i create deployments.apps \
  --as="$SA" \
  -n donweb-lab

Resultado esperado:

no

Crear Pods o Deployments puede permitir montar Secrets, seleccionar ServiceAccounts más privilegiados o acceder a volúmenes del namespace. Por eso, el permiso para crear workloads representa una capacidad de escalada indirecta.

Ejecución dentro de pods

kubectl auth can-i create pods \
  --subresource=exec \
  --as="$SA" \
  -n donweb-lab

Resultado esperado:

no

pods/exec utiliza normalmente el verbo create, no get.

Otro namespace

kubectl auth can-i list pods \
  --as="$SA" \
  -n default

Resultado esperado:

no

Recursos globales

kubectl auth can-i get nodes \
  --as="$SA"

kubectl auth can-i list persistentvolumes \
  --as="$SA"

Resultado esperado:

no

kubectl auth can-i evalúa los permisos efectivos de la identidad, incluida la suma de todos sus Bindings. Referencia de kubectl auth can-i.

Paso 9: revisar todos los permisos efectivos

kubectl auth can-i --list \
  --as="$SA" \
  --namespace=donweb-lab

Busca permisos inesperados procedentes de otros RoleBindings o ClusterRoleBindings.

Para inventariar los Bindings:

kubectl get rolebindings \
  --all-namespaces

kubectl get clusterrolebindings

Después inspecciona los que contengan el ServiceAccount, su namespace o grupos amplios como system:serviceaccounts.

Eliminar una regla de este Role no revoca un permiso si otra vinculación continúa concediéndolo.

Cómo utilizar el ServiceAccount desde un Pod

Un workload que necesite consultar la API puede declarar:

spec:
  serviceAccountName: lector-operaciones
  automountServiceAccountToken: true

En versiones modernas de Kubernetes, el kubelet monta mediante TokenRequest un token temporal y rotatorio. Evita crear Secrets con tokens permanentes salvo que exista una necesidad específica y documentada. ServiceAccounts.

Para una prueba manual temporal:

kubectl create token lector-operaciones \
  -n donweb-lab \
  --duration=10m

El resultado es una credencial sensible. No la pegues en tickets, logs, capturas ni repositorios.

Restringir acceso a un objeto concreto

resourceNames puede limitar algunos verbos a objetos específicos:

rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      - configuracion-publica
    verbs:
      - get

Esto permite leer únicamente el ConfigMap indicado.

resourceNames no puede restringir operaciones create o deletecollection. Para list y watch, el cliente debe enviar un field selector compatible con metadata.name.

Permisos que requieren una revisión especial

Evita conceder sin una justificación explícita:

• Recursos o verbos con "*".
• El ClusterRole cluster-admin.
• Membresía en system:masters.
• Lectura, listado o watch de Secrets.
• Creación o modificación de Pods y workloads.
• pods/exec, pods/attach y pods/portforward.
• nodes/proxy.
• serviceaccounts/token.
• Los verbos bind, escalate e impersonate.
• Gestión de certificados y su aprobación.
• Creación de PersistentVolumes.
• MutatingWebhookConfiguration y ValidatingWebhookConfiguration.

Los comodines incluyen recursos y subrecursos que puedan agregarse en el futuro, incluidos CRD nuevos. Una regla que parece aceptable hoy puede volverse excesiva tras una actualización.

Problemas frecuentes

El ServiceAccount no puede leer logs

Comprueba que el Role incluya:

resources:
  - pods/log
verbs:
  - get

También puede necesitar get sobre pods para que la herramienta resuelva el nombre y estado del Pod.

Los permisos parecen mayores que los declarados

RBAC es aditivo. Revisa:

kubectl auth can-i --list \
  --as="$SA" \
  -n donweb-lab

kubectl get rolebindings -A
kubectl get clusterrolebindings

Busca otras vinculaciones que incluyan el ServiceAccount o grupos amplios.

El Role contiene la regla, pero el acceso se deniega

Comprueba:

• Namespace del RoleBinding.
• Nombre y namespace del ServiceAccount.
• roleRef.
• Grupo de API del recurso.
• Verbo correcto.
• Subrecurso correcto.
• Errores de mayúsculas o pluralización.

No puedo modificar roleRef

El campo roleRef de un RoleBinding es inmutable. Si necesitas enlazar otro Role:

kubectl delete rolebinding lector-operaciones \
  -n donweb-lab

kubectl apply -f rbac-lector.yaml

El Pod no recibe un token

El ejemplo establece:

automountServiceAccountToken: false

Esto es intencional. Habilítalo explícitamente solo en workloads que necesiten acceder a la API.

Un usuario con permisos de Deployment puede leer Secrets indirectamente

Es posible crear un Deployment que monte Secrets o utilice otro ServiceAccount del namespace. La capacidad de crear workloads debe considerarse una frontera de confianza fuerte, incluso si no existe una regla directa sobre Secrets.

Monitoreo y revisión periódica

Registra y revisa:

• Cambios en Roles y ClusterRoles.
• Nuevos RoleBindings y ClusterRoleBindings.
• Uso de cluster-admin.
• Acceso a Secrets.
• Operaciones pods/exec.
• Creación de tokens.
• Impersonaciones.
• Errores de autorización repetidos.
• Cuentas y Bindings sin propietario vigente.

Combina RBAC con auditoría del API server, Pod Security Admission, NetworkPolicies y gestión segura de Secrets. RBAC controla la API, pero no reemplaza los demás controles.

Cómo revertir la configuración

kubectl rollout undo no revierte recursos RBAC.

Para cortar primero el acceso, elimina el RoleBinding:

kubectl delete rolebinding lector-operaciones \
  -n donweb-lab

Comprueba que el acceso haya sido revocado:

kubectl auth can-i list pods \
  --as="$SA" \
  -n donweb-lab

Después elimina el Role y el ServiceAccount:

kubectl delete role lector-operaciones \
  -n donweb-lab

kubectl delete serviceaccount lector-operaciones \
  -n donweb-lab

También puedes aplicar una versión anterior del manifiesto:

kubectl apply -f rbac-lector-anterior.yaml

Recuerda que otro Binding podría conservar permisos equivalentes. Vuelve a ejecutar todas las pruebas negativas después del rollback.

Buenas prácticas

• Define primero la matriz de acceso.
• Usa RoleBindings antes que ClusterRoleBindings.
• Evita comodines en recursos y verbos.
• Separa namespaces con niveles de confianza diferentes.
• Deshabilita el montaje automático de tokens cuando no sea necesario.
• Prefiere tokens temporales mediante TokenRequest.
• Prueba permisos permitidos y denegados.
• Revisa todos los Bindings efectivos.
• Documenta propietario, propósito y fecha de revisión.
• Elimina accesos obsoletos inmediatamente.
  

Cloud Serversby Donweb

Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.

• Performance que te sorprenderá
• Rápida escalabilidad y sin limitaciones
• Arquitectura de alta disponibilidad
• Soporte experto y ejecutivos de cuenta
• Pagos en tu moneda y facturación local

Descubre la mejor solución de Cloud Hosting