Por qué y cómo utilizar los registros de auditoría para proteger Kubernetes
En general, Kubernetes no ofrece funciones de monitorización de la seguridad ni de detección de amenazas. Espera que sea usted, el administrador del clúster, quien controle y actúe ante los problemas de seguridad.
Sin embargo, Kubernetes proporciona una herramienta muy importante para ayudarle a detectar posibles eventos de seguridad en forma de registros de auditoría. Al registrar sistemáticamente los datos de las solicitudes de acceso que se emiten a la API de Kubernetes, los registros de auditoría le ofrecen un recurso centralizado que puede utilizar para detectar actividades sospechosas en todo su clúster.
En este artículo definimos los registros de auditoría de Kubernetes, explicamos cómo trabajar con ellos y ofrecemos un ejemplo de cómo utilizarlo para rastrear eventos de seguridad.
¿Qué es un registro de auditoría de Kubernetes?
Explicado de un modo simple, un registro de auditoría de Kubernetes es un registro que registra información del servicio de auditoría de Kubernetes.
El propósito de los registros de auditoría es ayudar a los administradores del clúster a rastrear qué solicitudes se han iniciado, quién las inició, qué recursos se han utilizado y el resultado de cada solicitud.
De este modo, mediante el registro y el análisis de los datos de auditoría, puede obtener visibilidad temprana de los posibles problemas de seguridad dentro de su clúster, como las solicitudes de acceso no autorizado a los recursos o las solicitudes iniciadas por usuarios o servicios desconocidos. Los registros de auditoría también pueden ser de gran utilidad cuando se investiga una brecha de seguridad ya existente (aunque esperamos que consiga identificar los problemas antes de que lleguen a este punto).
Los registros de auditoría solo existen si se crean antes en Kubernetes
Aunque es habitual oír hablar de los “registros de auditoría de Kubernetes”, esta denominación es un poco engañosa, ya que Kubernetes no crea un registro de auditoría específico por sí mismo. Es decir, no es que Kubernetes registre automáticamente todos los eventos de auditoría en un archivo concreto que usted pueda luego simplemente abrir o seguir para rastrear eventos de seguridad.
Lo que Kubernetes hace es proporcionar los recursos para que los administradores puedan registrar los eventos de seguridad y transmitirlos a un backend de su elección. Por lo tanto, se pueden crear varios tipos de registros de auditoría en Kubernetes, pero su naturaleza exacta dependerá de la configuración definida. Además, no hay registros de auditoría predefinidos, sino que tendrá que configurarlos primero.
Eventos y etapas de auditoría de Kubernetes
Kubernetes registra datos de auditoría basados en dos conceptos clave: etapas y eventos de auditoría.
Un evento de auditoría es cualquier solicitud al servidor de la API, y las etapas se corresponden con los pasos que sigue el servidor cuando gestiona cada solicitud.
Hay cuatro posibles “etapas” para cada evento:
- RequestReceived: En esta etapa, el servidor de la API ha recibido la solicitud pero aún no ha comenzado a procesarla.
- ResponseStarted: El servidor ha comenzado a procesar la solicitud pero aún no ha enviado una respuesta.
- ResponseComplete: El servidor ha terminado de procesar la solicitud y ha enviado una respuesta.
- Panic: Esta etapa ocurre cuando el servidor de la API “entra en pánico” como respuesta a una solicitud.
Puede indicarle a Kubernetes que registre información en un registro de auditoría para cada etapa de todos los eventos de auditoría que tengan lugar en su clúster. De esta manera, podrá rastrear cuándo se producen las solicitudes relevantes para la seguridad y también cómo se gestionan.
Esta granularidad resulta útil, porque le ayuda a evaluar la gravedad de los incidentes de seguridad. Por ejemplo, una solicitud potencialmente maliciosa bloqueada en la etapa ResponseStarted es menos preocupante que una en la que el servidor de la API devuelve una respuesta que concede la solicitud. Lo más probable es que quiera conocer ambos tipos de eventos, pero dé prioridad a los segundos. La auditoría de Kubernetes hace que sea fácil diferenciarlos.
Formato del registro de auditoría
Por defecto, Kubernetes genera datos sobre cada evento de auditoría en formato JSON. A continuación le mostramos un ejemplo de evento que puede almacenar en un archivo de registro:
{
“kind”: “Event”,
“apiVersion”: “audit.k8s.io/v1beta1”,
“metadata”: {
“creationTimestamp”: “2018-10-08T08:26:55Z”
},
“level”: “Request”,
“timestamp”: “2018-10-08T08:26:55Z”,
“auditID”: “288ace59-97ba-4121-b06e-f648f72c3122”,
“stage”: “ResponseComplete”,
“requestURI”: “/api/v1/pods?limit=500”,
“verb”: “list”,
“user”: {
“username”: “admin”,
“groups”: [“system:authenticated”]
},
“sourceIPs”: [“10.0.138.91”],
“objectRef”: {
“resource”: “pods”,
“apiVersion”: “v1”
},
“responseStatus”: {
“metadata”: {},
“code”: 200
},
“requestReceivedTimestamp”: “2018-10-08T08:26:55.466934Z”,
“stageTimestamp”: “2018-10-08T08:26:55.471137Z”,
“annotations”: {
“authorization.k8s.io/decision”: “allow”,
“authorization.k8s.io/reason”: “RBAC: allowed by
ClusterRoleBinding “admin-cluster-binding” of ClusterRole “cluster-
admin” to User “admin””
}Habilitación de la auditoría en el servidor de la API de Kubernetes
Recuerde que, aunque Kubernetes proporciona los medios para registrar eventos de auditoría, no los registra de forma automática. Para generar los registros, es necesario habilitar y configurar esta función.
Para ello, debe especificar la ubicación de dos archivos en la configuración de su servidor de API:
--audit-policy-file=/etc/kubernetes/audit-policy.yaml \
--audit-log-path=/var/log/audit.logEn este caso, audit-policy.yaml es el archivo que define qué eventos de auditoría deben registrarse y cómo registrarlos, mientras que audit.log es la ubicación (en su nodo maestro) en la que se almacenan los datos de registro.
Definición del archivo de política de auditoría
Lo normal es que no quiera registrar todas y cada una de las solicitudes de la API que se produzcan en su clúster. De hacerlo así, tendrá tantos datos que será difícil filtrar el ruido.
Esa es precisamente la finalidad de crear un archivo de política de auditoría. Se trata de un archivo con formato YAML que especifica qué eventos deben registrarse y cuántos datos deben registrarse sobre cada evento.
Por ejemplo:
apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Only check access to resource "pods"
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"]
# Don't log watch requests by the "system:kube-proxy" on endpoints or services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core API group
resources: ["endpoints", "services"]
# Don't log authenticated requests to certain non-resource URL paths.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Wildcard matching.
- "/version"
# Log the request body of configmap changes in kube-system.
- level: Request
resources:
- group: "" # core API group
resources: ["configmaps"]
# This rule only applies to resources in the "kube-system" namespace.
# The empty string "" can be used to select non-namespaced resources.
namespaces: ["kube-system"]
# Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
resources:
- group: "" # core API group
resources: ["secrets", "configmaps"]
# A catch-all rule to log all other requests at the Metadata level.
- level: Metadata
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
omitStages:
- "RequestReceived"Como puede ver en los comentarios anteriores, este archivo de política restringe los tipos de eventos de auditoría que se registran. Por ejemplo, ignora los eventos en la etapa RequestReceived y solo rastrea el acceso a los pods.
Detección de eventos de seguridad con registros de auditoría
A modo de ejemplo sencillo de cómo funciona la auditoría de Kubernetes, imagine que hemos creado un archivo de política de auditoría parecido a este:
apiVersion: audit.k8s.io/v1beta1
kind: Policy
omitStages:
- “RequestReceived”
Rules:
- level: Request
users: [“admin”]
Resources:
- group: “”
resources: [“*”]
- level: Request
user: [“system:anonymous”]
resources:
- group: “”
resources: [“*”]Con esta configuración de auditoría podemos detectar cuándo un nuevo usuario que no está asociado a un Role o ClusterRole existente emite una solicitud.
Por ejemplo, imagine que el usuario intenta listar pods con:
kubectl get podsComo el usuario no tiene permiso para listar pods, el servidor de la API denegará la petición (kubectl responderá con “Error from server (Forbidden): pods is forbidden: User”).
Al mismo tiempo, el servidor de la API registrará un evento de auditoría similar a este:
{
“kind”: “Event”,
“apiVersion”: “audit.k8s.io/v1beta1”,
“metadata”: {
“creationTimestamp”: “2018-10-08T10:00:20Z”
},
“level”: “Request”,
“timestamp”: “2018-10-08T10:00:20Z”,
“auditID”: “5fc5eab3-82f5-480f-93d2-79bfb47789f1”,
“stage”: “ResponseComplete”,
“requestURI”: “/api/v1/namespaces/default/pods?limit=500”,
“verb”: “list”,
“user”: {
“username”: “system:anonymous”,
“groups”: [“system:unauthenticated”]
},
“sourceIPs”: [“10.0.141.137”],
“objectRef”: {
“resource”: “pods”,
“namespace”: “default”,
“apiVersion”: “v1”
},
“responseStatus”: {
“metadata”: {},
“status”: “Failure”,
“reason”: “Forbidden”,
“code”: 403
},
“requestReceivedTimestamp”: “2018-10-08T10:00:20.605009Z”,
“stageTimestamp”: “2018-10-08T10:00:20.605191Z”,
“annotations”: {
“authorization.k8s.io/decision”: “forbid”,
“authorization.k8s.io/reason”: “”
}
}Mediante el rastreo del registro de auditoría, los administradores pueden detectar la solicitud, lo que les alertará de la existencia de una cuenta de usuario que probablemente no debería existir.
Cómo aprovechar al máximo los registros de auditoría de Kubernetes
En un clúster a gran escala en el que el servidor de la API gestiona cientos o miles de solicitudes cada hora, no resulta muy práctico seguir el registro de auditoría de forma manual para detectar posibles riesgos.
En vez de ello, seguramente querrá transmitir los datos del registro de eventos a una herramienta de detección que sea capaz de monitorizar automáticamente los eventos de auditoría y generar alertas cuando haya algo raro.
Hay dos maneras de hacerlo:
- Monitorizar el archivo de registro de auditoría directamente: Puede configurar su herramienta de detección de intrusos para monitorizar el archivo de registro de auditoría directamente en su nodo maestro. Sin embargo, para que esto funcione, normalmente es necesario que la herramienta se ejecute en el nodo maestro, lo cual puede no ser conveniente, ya que aumenta la carga del maestro. (Por supuesto, puede intentar recopilar el archivo de registro del nodo maestro y enviarlo a una herramienta externa utilizando un agente de registro que se ejecute localmente, pero eso no resuelve realmente el problema, porque tendrá tiene que ejecutar un software adicional –el agente de registro– en el maestro).
- Enviar eventos a través de HTTP: Puede utilizar webhooks para enviar datos de eventos a una herramienta de seguridad externa a través de HTTP. De esta manera, su herramienta de seguridad se ejecutará de forma totalmente independiente de su clúster.
Por ejemplo, para enviar datos de eventos de auditoría a Falco, la herramienta de seguridad en tiempo de ejecución de código abierto, deberá configurar Falco como un webhook backend en su archivo kube-apiserver:
apiVersion: v1
kind: Config
clusters:
- name: falco
cluster:
server: http://$FALCO_SERVICE_CLUSTERIP:8765/k8s_audit
contexts:
- context:
cluster: falco
user: ""
name: default-context
current-context: default-context
preferences: {}
users: []
Con esta configuración, puede utilizar Falco (alojado en un servidor de su elección) para alertarle de los eventos de seguridad en el momento en que se producen. No tendrá que preocuparse de monitorizar directamente el archivo de auditoría de Kubernetes ni de ejecutar software de seguridad directamente en su clúster.
La auditoría es una parte esencial de cualquier estrategia de seguridad de Kubernetes. Aunque los registros de auditoría, como muchas cosas en Kubernetes, son un poco complejos de configurar y gestionar, también son altamente configurables. Kubernetes le permite controlar exactamente qué tipos de datos de auditoría registra, dónde se almacenan y cómo trabaja con ellos.
Siendo estratégico a la hora de determinar qué tipos de eventos de auditoría registrar (¡evite el ruido!) e integrando los datos de auditoría con herramientas de detección de intrusos (como Falco) que le alerten de posibles riesgos en tiempo real, maximizará su capacidad para encontrar y solucionar las amenazas a la seguridad de Kubernetes antes de que se conviertan en problemas más graves.