Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Kubernetes tiene un módulo de autorización llamado Control de Acceso Basado en Roles (RBAC) que ayuda a establecer permisos de utilización para el servidor API.
El modelo de permisos de RBAC se construye a partir de tres partes individuales:
Sujeto (Usuario, Grupo o ServiceAccount) – El objeto que recibirá los permisos.
RoleBinding\ClusterRoleBinding – La conexión entre Role\ClusterRole y el sujeto.
La diferencia entre “Roles” y “ClusterRoles” es solo dónde se aplicará el rol – un “Role” otorgará acceso a un namespace específico, mientras que un “ClusterRole” puede ser utilizado en todos los namespaces en el clúster. Además, los ClusterRoles también pueden otorgar acceso a:
recursos a nivel de clúster (como nodos).
puntos finales no relacionados con recursos (como /healthz).
recursos con namespace (como Pods), a través de todos los namespaces.
Desde Kubernetes 1.6 en adelante, las políticas de RBAC están habilitadas por defecto. Pero para habilitar RBAC puedes usar algo como:
En la plantilla de un Role o un ClusterRole necesitarás indicar el nombre del rol, el namespace (en roles) y luego los apiGroups, resources y verbs del rol:
Los apiGroups son un array que contiene los diferentes namespaces de API a los que se aplica esta regla. Por ejemplo, una definición de Pod utiliza apiVersion: v1. Puede tener valores como rbac.authorization.k8s.io o [*].
Los resources son un array que define a qué recursos se aplica esta regla. Puedes encontrar todos los recursos con: kubectl api-resources --namespaced=true
Los verbs son un array que contiene los verbos permitidos. El verbo en Kubernetes define el tipo de acción que necesitas aplicar al recurso. Por ejemplo, el verbo list se usa contra colecciones mientras que "get" se usa contra un solo recurso.
(Esta información fue tomada de los docs)
| Verbo HTTP | verbo de solicitud |
|---|---|
POST | crear |
GET, HEAD | obtener (para recursos individuales), listar (para colecciones, incluyendo el contenido completo del objeto), observar (para observar un recurso individual o colección de recursos) |
PUT | actualizar |
PATCH | parchear |
DELETE | eliminar (para recursos individuales), eliminarcolección (para colecciones) |
Kubernetes a veces verifica la autorización para permisos adicionales utilizando verbos especializados. Por ejemplo:
verbo use en recursos podsecuritypolicies en el grupo de API policy.
verbos bind y escalate en recursos roles y clusterroles en el grupo de API rbac.authorization.k8s.io.
verbo impersonate en users, groups y serviceaccounts en el grupo de API principal, y el userextras en el grupo de API authentication.k8s.io.
Puedes encontrar todos los verbos que cada recurso soporta ejecutando kubectl api-resources --sort-by name -o wide
Por ejemplo, puedes usar un ClusterRole para permitir que un usuario en particular ejecute:
De la documentación: Un role binding otorga los permisos definidos en un rol a un usuario o conjunto de usuarios. Contiene una lista de sujetos (usuarios, grupos o cuentas de servicio) y una referencia al rol que se está otorgando. Un RoleBinding otorga permisos dentro de un namespace específico, mientras que un ClusterRoleBinding otorga ese acceso a nivel de clúster.
Los permisos son aditivos así que si tienes un clusterRole con “list” y “delete” secretos, puedes agregarlo con un Role con “get”. Así que ten cuidado y prueba siempre tus roles y permisos y especifica lo que está PERMITIDO, porque todo está DENEGADO por defecto.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
