Kubernetes Role-Based Access Control(RBAC)
Control de Acceso Basado en Roles (RBAC)
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:
Plantillas
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.
Verbos de Reglas
(Esta información fue tomada de los docs)
Kubernetes a veces verifica la autorización para permisos adicionales utilizando verbos especializados. Por ejemplo:
verbo
use
en recursospodsecuritypolicies
en el grupo de APIpolicy
.verbos
bind
yescalate
en recursosroles
yclusterroles
en el grupo de APIrbac.authorization.k8s.io
.verbo
impersonate
enusers
,groups
yserviceaccounts
en el grupo de API principal, y eluserextras
en el grupo de APIauthentication.k8s.io
.
Puedes encontrar todos los verbos que cada recurso soporta ejecutando kubectl api-resources --sort-by name -o wide
Ejemplos
Por ejemplo, puedes usar un ClusterRole para permitir que un usuario en particular ejecute:
RoleBinding y ClusterRoleBinding
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 “listar” y “eliminar” secretos, puedes agregarlo con un Role con “obtener”. Así que ten cuidado y siempre prueba tus roles y permisos y especifica lo que está PERMITIDO, porque todo está DENEGADO por defecto.
Enumerando RBAC
Abuso de Roles/ClusterRoles para Escalación de Privilegios
Last updated