Audit logs de EKS, GKE y AKS: activarlos y exportarlos

TL;DR. En Kubernetes gestionado no puedes editar la política de auditoría, pero decides si el audit log se conserva. EKS: activa el tipo de log audit del plano de control; los eventos llegan a CloudWatch Logs, grupo /aws/eks/<cluster>/cluster, streams kube-apiserver-audit-*. GKE: Admin Activity (escrituras) está siempre activo; las lecturas, incluidas las de secrets, van a los logs de Data Access, que hay que activar para la API de Kubernetes Engine. AKS: crea una configuración de diagnóstico con la categoría kube-audit (o kube-audit-admin, que excluye get y list). Exporta en JSON y arrastra los archivos al analizador de audit logs.

Ninguna de las tres viene configurada por defecto de forma que cubra una investigación. El peor momento para descubrirlo es la mañana siguiente a una alerta. Esta guía cubre qué activar ya y cómo sacar los datos cuando los necesites.

Amazon EKS

Activar

Por defecto, EKS no envía logs del plano de control a CloudWatch; cada tipo de log se activa por separado, como indica la documentación de registro del plano de control de EKS. En la consola: clúster, Observability, Control plane logging, Manage logging, activa Audit (y Authenticator, que relaciona principales de IAM con usuarios de Kubernetes). Con la CLI:

aws eks update-cluster-config --region eu-west-1 --name my-cluster \
  --logging '{"clusterLogging":[{"types":["audit","authenticator"],"enabled":true}]}'

Se aplican los cargos estándar de ingesta y almacenamiento de CloudWatch Logs. La entrega es «best effort» y suele tardar unos minutos. Fija en el grupo de logs una retención acorde con tus necesidades de investigación.

Qué registra la política de EKS

AWS publica la política de auditoría de EKS en la guía de buenas prácticas de EKS. Lo que importa en forense:

• Secrets, configmaps y token reviews: solo Metadata.
• serviceaccounts/token: Request.
• Lecturas (get, list, watch) sobre el grupo core y los grupos de API conocidos: Request; escrituras: RequestResponse. Por tanto, los specs de workloads y los cuerpos RBAC están disponibles.
• Los events no se registran en absoluto. Un borrado de Events no aparecerá.
• Las entradas de CloudWatch Logs tienen un límite de 1 MB, mientras que una solicitud a la API puede llegar a 1,5 MiB, así que los objetos muy grandes pueden quedar truncados o reducidos a metadatos.

Exportar

Para un intervalo corto basta con filter-log-events:

aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster \
  --log-stream-name-prefix kube-apiserver-audit \
  --start-time 1789344000000 --end-time 1789430400000 > eks-audit.json

Los tiempos van en milisegundos epoch. Para días o semanas de logs, usa una tarea de exportación a S3 (aws logs create-export-task) y descarga los objetos .gz: cada línea es una marca de tiempo seguida del evento JSON. Los resultados de CloudWatch Logs Insights exportados como JSON también sirven. El analizador lee las tres formas, incluidos archivos gzip y carpetas completas.

Las identidades de IAM aparecen en el audit log con el nombre de usuario que definen las access entries o el ConfigMap aws-auth. Para seguir al mismo principal en el lado de AWS (CloudTrail, la API de EKS, llamadas AssumeRole), consulta AWS Forensics.

Google GKE

Dos logs, uno desactivado por defecto

GKE escribe las entradas de auditoría de Kubernetes en Cloud Audit Logs con el tipo de recurso k8s_cluster. La política de auditoría de GKE las reparte así:

• las solicitudes create, update y delete van al log Admin Activity, siempre activo y que no se puede desactivar;
• get, list y updateStatus van al log Data Access que, como recuerda la página de registro de auditoría de GKE, está desactivado por defecto y se factura al activarlo.

La consecuencia es tajante: en un proyecto de GKE por defecto, un atacante que lee todos los secrets con get no deja ninguna entrada de auditoría de esas lecturas. Activa los logs de Data Access de la API de Kubernetes Engine en IAM y administración, Registros de auditoría antes de necesitarlos, sopesando volumen y coste.

Qué registra la política de GKE

La misma página indica que las solicitudes sobre secrets, configmaps y token reviews se registran en Metadata, las lecturas en general en Metadata y las escrituras en general en RequestResponse. Por tanto, los specs de workloads y los bindings RBAC son visibles en las escrituras.

En Cloud Logging el evento se reescribe: protoPayload.methodName (por ejemplo io.k8s.core.v1.pods.exec.create), protoPayload.resourceName, protoPayload.authenticationInfo.principalEmail, protoPayload.requestMetadata.callerIp y callerSuppliedUserAgent, con un código de estado gRPC en lugar del HTTP. El analizador los devuelve a verbo, recurso, subrecurso, usuario, IP y código HTTP.

Exportar

gcloud logging read \
  'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"' \
  --project=my-project --freshness=30d --format=json > gke-audit.json

También puedes descargar los resultados del Explorador de registros como JSON o, para periodos largos, enrutar los logs con un sink a Cloud Storage o BigQuery. BigQuery guarda la carga útil en protopayload_auditlog, con los cuerpos de solicitud y respuesta como texto JSON; el analizador lee esas filas si exportas la tabla o los resultados de la consulta como JSON o JSON delimitado por saltos de línea (no CSV, Avro ni Parquet). La retención depende del bucket de logs: los logs de Admin Activity van al bucket _Required y los de Data Access a _Default, salvo que hayas cambiado el enrutamiento. Para la parte de Google Cloud de un incidente (IAM, claves de cuentas de servicio, Compute), GCP Forensics cubre esos logs.

Una limitación actual del analizador: los detalles de impersonation de GKE que van en serviceAccountDelegationInfo todavía no se interpretan.

Azure AKS

Activar

AKS envía los logs del plano de control mediante una configuración de diagnóstico en el recurso del clúster. La documentación de supervisión de AKS describe las categorías de auditoría:

kube-audit es la que necesitas para el robo de credenciales, porque las lecturas de secrets son get y list. Microsoft advierte de que puede salir cara; kube-audit-admin es el término medio más barato, a costa de perder las lecturas. Destinos:

• Log Analytics, en modo específico del recurso (tablas AKSAudit y AKSAuditAdmin) o en el modo heredado de Azure Diagnostics (tabla AzureDiagnostics, JSON del evento en log_s).
• Cuenta de almacenamiento: blobs horarios PT1H.json en el contenedor insights-logs-kube-audit.
• Event Hubs: lotes {"records": [...]}, normalmente consumidos por un SIEM.

Ejemplo con Azure CLI, enviando a Log Analytics en modo específico del recurso:

az monitor diagnostic-settings create --name aks-audit \
  --resource <aks-resource-id> --workspace <workspace-resource-id> \
  --export-to-resource-specific true \
  --logs '[{"category":"kube-audit","enabled":true}]'

Exportar

Desde una cuenta de almacenamiento, descarga los blobs PT1H.json del periodo (la estructura de carpetas codifica fecha y hora) y arrastra la carpeta completa. Desde Log Analytics, consulta la tabla y guarda el resultado como JSON en lugar de CSV:

az monitor log-analytics query --workspace <workspace-guid> \
  --analytics-query "AKSAudit | where TimeGenerated between (datetime(2026-09-13) .. datetime(2026-09-15))" \
  -o json > aks-audit.json

El tamaño de los resultados de las consultas está limitado, así que divide los intervalos largos en varias consultas. El analizador lee filas de AKSAudit (columnas en PascalCase), filas de AzureDiagnostics, blobs de cuentas de almacenamiento y lotes de Event Hubs. Para los inicios de sesión de Entra ID y la actividad de Azure alrededor del clúster, consulta Azure Forensics.

Clústeres autogestionados

En kubeadm, k3s, RKE2 o distribuciones on-premises, la política y los archivos son tuyos. Copia audit.log y sus archivos rotados de cada nodo del plano de control (cada API server solo registra las solicitudes que atendió), o expórtalos desde donde los envíe tu webhook o tu agente de envío. El artículo sobre la política de auditoría propone una política orientada a forense como punto de partida.

Antes de analizar

• Cubre todo el periodo, empezando días antes del primer evento sospechoso.
• Conserva los originales intactos y trabaja con copias; calcula hashes si el caso puede acabar en los tribunales.
• Anota la zona horaria. Las marcas de tiempo de auditoría están en UTC; las exportaciones de consola quizá no.
• Busca huecos. Un día sin ningún evento suele indicar un cambio en el registro, no un clúster tranquilo.

Después abre el analizador de audit logs de Kubernetes, arrastra los archivos o carpetas y sigue la guía de análisis paso a paso.

Artículos relacionados

• Política de auditoría de Kubernetes para forense
• Anatomía de un evento de auditoría de Kubernetes
• Respuesta a incidentes en Kubernetes con los audit logs