Escenario: un pod con una cuenta de servicio que no le corresponde

A través de una vulnerabilidad de inyección en una aplicación web, un atacante obtuvo ejecución de comandos en el pod web-frontend-77b9-xk2 dentro del namespace frontend. Debido a una mala configuración de RBAC, la cuenta de servicio del pod disponía de permisos para crear clusterrolebindings, vinculándose el rol de cluster-admin. De inmediato montó un volumen hostPath para escapar al nodo del host. La auditoría de kube-apiserver permitió detectar la llamada create clusterrolebindings y contener la brecha.

Indica el código de estado (status_code) con que respondió el kube-apiserver a la llamada en K8S-AUD-901.

Lección tras el caso {#leccion}

En entornos nativos de la nube y clústeres de Kubernetes, la seguridad perimetral tradicional pierde vigencia ante la dinamismo de los microservicios efímeros. Las amenazas modernas explotan contenedores expuestos y abusan de tokens de ServiceAccounts sobreprivilegiadas montadas por defecto para tomar el control del plano de control mediante llamadas anómalas a la API (kube-apiserver) o escapan hacia el nodo anfitrión aprovechando monturas indebidas de hostPath y modo privilegiado. El cazador de amenazas en la nube debe correlacionar la telemetría de auditoría de la API con los sensores de comportamiento en tiempo de ejecución (runtime eBPF/Falco), asegurando que ningún pod posea privilegios superiores a los estrictamente indispensables para su función.