Cómo analizar audit logs de Kubernetes en el navegador

TL;DR. Exporta los audit logs de tu API server en JSON, arrástralos (archivos, carpetas, ZIP o .gz) al analizador de audit logs de Kubernetes y lee la página de arriba abajo: archivos leídos, veredicto, hallazgos, línea de tiempo, entidades, checklist de remediación y tabla de eventos. Todo se ejecuta en local en un Web Worker compilado de Rust a WebAssembly; no se sube nada. Trata cada hallazgo como una pista que confirmar con los dueños de la identidad, no como una conclusión.

Esta guía recorre una sesión real de triaje con la herramienta, panel a panel, y explica las decisiones de diseño que conviene conocer para interpretar el resultado.

Antes de empezar: consigue la exportación correcta

El analizador solo lee JSON. Entradas admitidas:

Gzip y ZIP (incluidos los anidados) se leen como streams, así que las exportaciones de varios gigabytes funcionan; el límite es el tiempo, no la memoria. Las exportaciones CSV de Log Analytics o Logs Insights aún no se admiten: exporta en JSON. La guía de exportación para EKS, GKE y AKS tiene los comandos.

Si quieres practicar primero, haz clic en Probar un ejemplo. Carga un incidente ficticio claramente etiquetado, que se recorre en detalle en el recorrido del incidente ficticio.

Paso 1: carga los archivos

Arrastra archivos o una carpeta entera a la zona de carga, o usa Elegir archivos / Elegir una carpeta. Una línea de progreso muestra el archivo que se está leyendo, los bytes procesados y el número de eventos. Puedes cancelar en cualquier momento.

Por debajo, un divisor de JSON en streaming lee los registros uno a uno, ya sea el archivo líneas JSON, un gran array o un envoltorio cloud, y cada registro se normaliza en un único modelo de evento. Los stages de una misma solicitud se agrupan en un evento, así que un kubectl exec se cuenta una vez aunque la política registre tanto ResponseStarted como ResponseComplete.

Paso 2: comprueba qué se leyó de verdad

Antes de fiarte de un veredicto, baja a Archivos leídos y Archivos omitidos:

• Cada archivo omitido viene con un motivo: vacío, solo ceros (copia incompleta), exportación CSV, no es JSON, gzip o ZIP dañado.
• Cada archivo muestra sus registros, sus eventos y notas sobre registros malformados, truncados o no reconocidos.
• Las estadísticas de arriba dan las marcas Desde y Hasta y las fuentes detectadas (audit log, EKS, GKE, AKS, Falco).

Si el rango temporal no cubre el periodo que te interesa, detente y exporta más. Si un archivo solo muestra «otros tipos de log», probablemente exportaste el stream de CloudWatch o la tabla de Log Analytics equivocados.

Paso 3: lee el veredicto

El veredicto es uno de estos:

• Probable compromiso: al menos una detección crítica, o tres detecciones altas distintas.
• Actividad sospechosa: al menos una detección alta, o dos detecciones medias distintas.
• Sin señales de compromiso: nada por encima de ese umbral.
• No se encontraron eventos de auditoría: los archivos no contenían eventos de auditoría de Kubernetes.

La línea Por qué lista las detecciones que determinaron el veredicto. Los umbrales son deliberadamente simples para que puedas explicarlos en un informe. «Sin señales de compromiso» solo significa que ninguna regla coincidió en los datos que aportaste: el artículo sobre limitaciones explica qué puede esconderse en los huecos.

Paso 4: revisa cada hallazgo

Cada hallazgo es una regla de detección que coincidió, agrupada por la identidad o el objeto implicado (por ejemplo, un hallazgo por cuenta de servicio para exec, uno por imagen para mineros). Un hallazgo muestra:

• el título de la regla, la severidad, la táctica ATT&CK y los IDs de técnica;
• la primera y la última coincidencia y el número de eventos;
• los objetos y las IPs de origen implicados;
• en las reglas con umbral (ráfagas de lecturas de secrets, auth can-i, 403), el umbral que saltó, por ejemplo «10 o más en 10 min».

Haz clic en Mostrar los eventos para ir a la tabla de eventos filtrada. Luego plantea la pregunta implícita en cada regla: ¿hay una explicación legítima? Un admin que lanza kubectl exec durante una caída conocida está bien; el mismo admin a las 3 de la mañana desde un país nuevo, no. Las reglas son datos, en un archivo JSON revisado del repositorio del proyecto, y los artículos de detección explican cada familia.

Paso 5: sigue la línea de tiempo

La Línea de tiempo del incidente lista los eventos marcados en orden cronológico. Las líneas en negrita indican dónde salta una detección por primera vez: en una intrusión real suelen leerse como los capítulos del ataque (acceso, reconocimiento, robo de credenciales, escalada, persistencia, impacto). Marca Incluir eventos de baja severidad para añadir contexto, como nuevos ClusterRoleBindings o imágenes de registries inusuales.

Cambia entre UTC y Local con el selector de zona horaria. Quédate en UTC para todo lo que anotes.

Paso 6: pivota por entidades

El panel Entidades responde a «quién hizo qué y desde dónde»:

• Usuarios y cuentas de servicio, con recuentos de eventos, marcados y denegados, primera y última aparición;
• IPs de origen, con una etiqueta pública para las direcciones de Internet;
• Namespaces, Pods (con el número de sesiones exec), Imágenes y User agents.

Haz clic en cualquier valor para filtrar la tabla de eventos. El pivote clásico: de la cuenta de servicio marcada a sus IPs de origen, y de esas IPs a todas las demás identidades que usaron. Una IP que se autenticó como dos cuentas de servicio distintas en el mismo minuto es una persona con dos tokens robados.

Paso 7: profundiza en los eventos

La tabla de eventos filtra por detección, severidad mínima, solo marcados y texto libre (usuario, IP, objeto, comando). Haz clic en una fila para ver la ficha de detalle: usuario y grupos, usuario suplantado, IPs de origen, user agent, verbo y objeto, URI de la solicitud, comando exec, imágenes, código de respuesta, decisión y motivo de autorización, stage y nivel, audit ID, archivo de origen y, si se registró, el cuerpo de la solicitud.

Con exportaciones de hasta 50 000 eventos, todo se puede consultar. Por encima, la tabla solo conserva los eventos marcados, mientras que los recuentos, las entidades y los hallazgos siguen cubriendo toda la entrada.

Paso 8: exporta y remedia

• CSV exporta los eventos filtrados (las celdas que podrían interpretarse como fórmulas de hoja de cálculo se neutralizan).
• Informe JSON exporta el veredicto, los hallazgos, las entidades y la lista de remediación para tu expediente.

La Checklist de remediación se construye a partir de los hallazgos y se ordena por urgencia: primero preservar la evidencia y delimitar, luego revocar tokens, eliminar bindings, borrar workloads maliciosos, reconstruir nodos, rotar secrets y endurecer. Marcar elementos no guarda nada, así que cópiala a tu sistema de tickets. El bloque Qué hacer a continuación solo enlaza a guías oficiales de kubernetes.io y de los proveedores cloud.

Errores habituales

• Logs de un solo nodo del plano de control. Cada instancia del API server registra lo que atendió. Recógelos todos.
• Política solo en Metadata. Los pods privilegiados y los bindings a cluster-admin necesitan los cuerpos de solicitud para reconocerse; consulta la guía de la política de auditoría.
• Componentes de plataforma marcados. Las reglas excluyen los controladores de Kubernetes y los agentes cloud comunes; tus propios operadores (GitOps, backup, service mesh) pueden seguir disparando hallazgos de exec o de DaemonSet. Verifícalos y anótalos como legítimos.
• Rango temporal demasiado corto. Si el primer evento marcado está justo al principio de la exportación, exporta datos anteriores.

Artículos relacionados

• Respuesta a incidentes en Kubernetes con los audit logs
• Incidente ficticio: del token del dashboard al criptominero
• Audit logs de EKS, GKE y AKS: activarlos y exportarlos