E-KUB
kubectl-who-can
Plugin de kubectl que lista cada usuario, grupo o service account con permiso RBAC para ejecutar un verbo sobre un recurso.
Sitio oficialVolver al catálogo
RESUMEN
kubectl-who-can (aquasecurity/kubectl-who-can) responde una pregunta que las herramientas nativas de RBAC no responden directamente: dado un verbo y un recurso — "quién puede crear pods" o "quién puede leer secrets en el namespace prod" — recorre cada ClusterRoleBinding y RoleBinding del clúster y reporta qué usuarios, grupos y service accounts tienen ese permiso, directamente o a través de un rol.
Esa búsqueda en reversa convierte una cacería de escalada de privilegios — que sería leer cada RoleBinding a mano — en un solo comando, por eso suele ejecutarse justo después de conseguir cualquier acceso autenticado en un clúster: saca a la luz service accounts y roles con permisos mucho más amplios de lo que necesita el workload al que están asociados.
CASOS DE USO
Casos de uso en un engagement
- 01
Responder directamente "quién puede hacer X sobre Y" en vez de cruzar Roles y RoleBindings a mano.
- 02
Encontrar service accounts con verbos equivalentes a cluster-admin (crear pods, bind, escalate) muy por encima de lo que necesita su workload.
- 03
Delimitar una ruta de escalada de privilegios: una vez comprometido un token de service account, revisar qué más — o qué otras identidades con los mismos bindings — puede alcanzar.
- 04
Auditar el RBAC de un namespace antes de un release para confirmar que los bindings realmente reflejan el diseño de mínimo privilegio previsto.
PRIMEROS PASOS
Justo después de lograr cualquier acceso autenticado, para buscar en reversa qué identidades tienen un permiso RBAC concreto y peligroso.
- Confirma que kubectl está configurado contra el clúster en alcance con una credencial que pueda leer objetos RBAC.
- Instala el plugin vía krew (`kubectl krew install who-can`) o descarga un binario de las releases.
- Ejecútalo contra un par verbo/recurso específico, opcionalmente acotado a un namespace con `-n`.
- Cruza cualquier sujeto sorprendente contra su workload real para juzgar si el permiso está justificado.
kubectl who-can create pods --namespace defaultANTES DE USARLA
Qué revisar antes de lanzarla
Reporta lo que el RBAC otorga, no lo que es realmente explotable — un permiso amplio en un service account legado sin uso es un hallazgo de menor prioridad que el mismo permiso en un token montado en un pod expuesto a internet.
Ejecutarlo requiere suficiente acceso RBAC para listar ClusterRoles, Roles y sus bindings; una credencial de bajo privilegio puede no poder completar una auditoría completa, lo cual vale la pena anotar.
Solo cubre el RBAC nativo de Kubernetes — capas de autorización específicas del clúster (IAM del proveedor cloud asociado a nodos, políticas de OPA/Gatekeeper) no se reflejan en su salida.