Kubernetes Role-Based Access Control(RBAC)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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:

1. Role\ClusterRole ­– El permiso real. Contiene reglas que representan un conjunto de permisos. Cada regla contiene recursos y verbos. El verbo es la acción que se aplicará al recurso.

2. Sujeto (Usuario, Grupo o ServiceAccount) – El objeto que recibirá los permisos.

3. 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:

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

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)

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), deletecollection (para colecciones)

Kubernetes a veces verifica la autorización para permisos adicionales utilizando verbos especializados. Por ejemplo:

• PodSecurityPolicy

• verbo use en recursos podsecuritypolicies en el grupo de API policy.

• RBAC

• verbos bind y escalate en recursos roles y clusterroles en el grupo de API rbac.authorization.k8s.io.

• Autenticación

• 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

Ejemplos

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: defaultGreen
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]

Por ejemplo, puedes usar un ClusterRole para permitir que un usuario en particular ejecute:

kubectl get pods --all-namespaces

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.

piVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io

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

# Get current privileges
kubectl auth can-i --list
# use `--as=system:serviceaccount:<namespace>:<sa_name>` to impersonate a service account

# List Cluster Roles
kubectl get clusterroles
kubectl describe clusterroles

# List Cluster Roles Bindings
kubectl get clusterrolebindings
kubectl describe clusterrolebindings

# List Roles
kubectl get roles
kubectl describe roles

# List Roles Bindings
kubectl get rolebindings
kubectl describe rolebindings

Abuso de Roles/ClusterRoles para Escalación de Privilegios

Abusing Roles/ClusterRoles in Kubernetes

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)

Apoya a HackTricks

• Revisa los planes de suscripción!

• Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.

• Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.