0Pricing
Cyber Security Academy · Lección

RBAC y cuentas de servicio

Restrinja el acceso al clúster.

RBAC y cuentas de servicio es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.

RBAC lo controla todo

El control de acceso basado en roles (RBAC) determina qué identidades pueden realizar qué acciones sobre qué recursos en un clúster. Cada llamada a la API se autoriza según RBAC. La configuración incorrecta de RBAC es la principal causa de escalada de privilegios dentro del clúster.

  • Sujetos: usuarios, grupos y cuentas de servicio.
  • Los roles vinculan verbos a recursos.
  • Las vinculaciones conectan los sujetos con los roles.

Roles frente a ClusterRoles

Existen dos ámbitos.

  • Role + RoleBinding: permisos limitados al espacio de nombres.
  • ClusterRole + ClusterRoleBinding: permisos para todo el clúster.

Una ClusterRoleBinding a cluster-admin proporciona control total. Concedérsela a una cuenta de servicio es un error frecuente y peligroso.

Tokens de cuentas de servicio

Cada pod se ejecuta como una cuenta de servicio y, de forma predeterminada, monta su token. Ese token es una credencial portadora que otorga los permisos RBAC de la cuenta. Si el pod se ve comprometido, el token también.

Los clústeres modernos emiten tokens proyectados de corta duración vinculados a una audiencia, pero todavía persisten tokens de secretos heredados de larga duración.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Enumeración de sus permisos

Después de capturar un token, el primer paso es averiguar qué puede hacer. Kubernetes ofrece una API de autocomprobación.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Combinaciones peligrosas de permisos

Ciertos verbos son mecanismos de escalada incluso sin cluster-admin.

  • create pods: programe un pod privilegiado o con hostPath para escapar.
  • create pods/exec: ejecute comandos en pods existentes.
  • get/list secrets: lea credenciales en todo el clúster.
  • create rolebindings/clusterrolebindings: vincúlese a sí mismo con permisos de administrador.
  • escalate / bind: conceda permisos que no posee.
  • impersonate: actúe como otro sujeto con más privilegios.

Escalada mediante la creación de pods

Si una cuenta de servicio puede crear pods, a menudo puede tomar el control del nodo. El atacante programa un pod que monta el sistema de archivos del host o se ejecuta con privilegios; después lee las credenciales del nodo o escapa.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Escalada mediante bindings

Si puede crear rolebindings o clusterrolebindings, puede vincular directamente su cuenta de servicio a cluster-admin. Kubernetes protege esto con los verbos bind/escalate, pero las configuraciones incorrectas a veces lo permiten.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Abuso de la suplantación

El verbo impersonate permite que un sujeto actúe como cualquier usuario, grupo o cuenta de servicio. Una entidad principal con permisos amplios de suplantación tiene, en la práctica, todos los permisos del clúster.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

Auditoría de RBAC

Los defensores deben revisar continuamente RBAC para detectar concesiones de riesgo.

  • Busque sujetos vinculados a cluster-admin.
  • Marque los verbos o recursos comodín (*).
  • Detecte concesiones de lectura de secretos y creación de pods en cuentas que no sean de administrador.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Refuerzo de las cuentas de servicio

Aplique el principio de mínimo privilegio a las identidades.

  • Establezca automountServiceAccountToken: false cuando el pod no necesite acceso a la API.
  • Asigne a cada carga de trabajo una cuenta de servicio específica con el alcance mínimo necesario.
  • Evite la cuenta de servicio default para las cargas de trabajo reales.
  • Use tokens proyectados de corta duración con audiencias; rótelos y vincúlelos.
  • Nunca vincule cargas de trabajo a cluster-admin.

Pruebas éticas de RBAC

Al evaluar RBAC, prefiera comprobaciones no destructivas (auth can-i, dry-run) en lugar de crear realmente vinculaciones a cluster-admin en producción. Si debe demostrar una escalada, limítela a un espacio de nombres de prueba y elimine cualquier vinculación o pod que haya creado.

Informe de los roles y las vinculaciones exactos que permitieron la escalada para poder restringirlos.

Comprobación rápida

Confirme sus conocimientos sobre RBAC.

Resumen

Ha aprendido cómo RBAC y las cuentas de servicio gobiernan y ponen en riesgo el acceso al clúster.

  • RBAC vincula sujetos a verbos sobre recursos; cluster-admin proporciona control total.
  • Los pods montan tokens de cuentas de servicio; auth can-i revela su alcance.
  • create-pods, binding, secret-read e impersonate son mecanismos de escalada.
  • Las cuentas con mínimo privilegio y el automontaje deshabilitado refuerzan el clúster.

Siguiente tema: seguridad de los pods y políticas de red.

Preguntas frecuentes

¿La lección «RBAC y cuentas de servicio» es gratis?

Sí — el texto completo de «RBAC y cuentas de servicio» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.

¿Qué aprenderé en «RBAC y cuentas de servicio»?

Restrinja el acceso al clúster. Practicas Cyber Security Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Cyber Security Academy?

No se requiere experiencia previa. Cyber Security Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «RBAC y cuentas de servicio»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Cyber Security Academy?

Sí. Cada lección de Cyber Security Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. Modelo de amenazas de Kubernetes
  2. RBAC y cuentas de servicio
  3. Seguridad de pods y políticas de red
  4. Protección de la cadena de suministro y secretos
← Volver a Cyber Security Academy