Auditoría de la API de Kubernetes

Cada petición a la API de Kubernetes puede dejar un evento de auditoría. Los campos que más se leen son auditID (identifica la petición), verb (get, list, create, patch, delete...), user (la identidad: una persona, una cuenta de servicio o un componente del propio clúster), sourceIPs, userAgent, objectRef (el recurso, el namespace, el nombre y, si lo hay, el subrecurso) y responseStatus (el código de respuesta). En esta tabla, codigo es ese resultado.

El nivel de la política de auditoría decide cuánto se guarda: None no registra, Metadata guarda quién, qué y cuándo pero no el cuerpo de la petición ni de la respuesta, Request añade el cuerpo de la petición, y RequestResponse añade también el de la respuesta. Para los secretos suele convenir Metadata, justamente para que el contenido del secreto no se copie al registro.

Abre la consola. Ejecuta SELECT * FROM auditoria WHERE recurso = 'secrets' y mira los eventos a-4104 y a-4105.

Una misma petición puede aparecer más de una vez en la auditoría, con el mismo auditID y una etapa distinta. RequestReceived se genera al recibirla; ResponseStarted solo en peticiones largas (como una sesión abierta o un watch) cuando salen las cabeceras de respuesta; ResponseComplete cuando termina; y Panic si algo falla. Quien cuenta eventos sin mirar la etapa cuenta de más.

Abrir un shell en un pod con kubectl exec aparece en la API como una petición sobre el subrecurso exec de un pod. Lo estable para buscarlo es el subrecurso, no una suposición sobre el verbo.

Ejecuta SELECT * FROM auditoria WHERE subrecurso = 'exec'.

Un código 403 quiere decir que la API entendió la petición y la denegó. Dos 403 con un segundo de diferencia, hechos con la identidad de una cuenta de servicio, son un patrón: un programa (o alguien con su token) que primero lista y enseguida pide un objeto concreto. El origen que aparece es una dirección de la red de pods, no una estación de trabajo.

Ejecuta SELECT * FROM auditoria WHERE codigo = '403'.

Que la API haya denegado algo es buena noticia sobre el control de acceso, pero no cierra la pregunta. Alguien o algo con la identidad de esa cuenta intentó algo que no le corresponde, y falta saber qué lo provocó: una aplicación con un error, una configuración mal copiada, o una persona dentro del pod. Tampoco se declara «ataque» por un solo rechazo: lo que se hace es abrir la pregunta y buscar, en las otras capas, qué más hizo ese pod.