Habilita los registros de auditoría de Linux en nodos de GKE

En esta página, se explica cómo habilitar los registros de auditoría del sistema operativo detallados en los nodos de Google Kubernetes Engine que ejecutan Container-Optimized OS. En esta página, también se explica cómo configurar un agente de Logging de fluent-bit para enviar registros a Cloud Logging. Habilitar los registros detallados puede proporcionar información valiosa sobre el estado de tu clúster y las cargas de trabajo, como mensajes de error, intentos de acceso y ejecuciones binarias. Puedes usar esta información para depurar problemas o investigar incidentes de seguridad.

Los clústeres de GKE Autopilot no admiten la habilitación del registro auditd de Linux, ya que Google administra los nodos y las máquinas virtuales (VMs) subyacentes.

Esta página está dirigida a los especialistas en seguridad que revisan y analizan los registros de seguridad. Usa esta información para comprender los requisitos y las limitaciones de los registros detallados del SO, y guiar tu implementación cuando los habilites en tus nodos de GKE. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que hacemos referencia en el contenido de Google Cloud , consulta Roles y tareas comunes de los usuarios de GKE.

Antes de leer esta página, asegúrate de estar familiarizado con los registros de auditoría del sistema operativo Linux.

El registro de auditoría del sistema operativo es distinto de los Registros de auditoría de Cloud y los registros de auditoría de Kubernetes.

Descripción general

Para recopilar registros de cada nodo en un clúster, usa un DaemonSet que ejecute exactamente un pod en cada uno de los nodos del clúster en los que el DaemonSet es elegible para ser programado. Este Pod configura el daemon de registro auditd en el host y configura el agente de Logging para enviar los registros a Logging o a cualquier otro servicio de transferencia de registros.

Por definición, la auditoría ocurre después de un evento y es una medida de seguridad retrospectiva. Es probable que los registros auditd, por sí solos, no sean suficientes para detectar intrusiones en tu clúster. Considera cómo usar mejor el registro auditd como parte de tu estrategia general de seguridad.

Limitaciones

Los mecanismos de registro que se describen en esta página solo funcionan en nodos que ejecutan Container-Optimized OS en clústeres de GKE Standard.

Funcionamiento del DaemonSet de registro

En esta sección, se describe cómo funciona el registro de ejemplo de DaemonSet a fin de que puedas configurarlo según tus necesidades. En la siguiente sección, se explica cómo implementar DaemonSet.

En el manifiesto de ejemplo, se define un DaemonSet, un ConfigMap y un Namespace para contenerlos.

El DaemonSet implementa un pod en cada nodo del clúster. El pod contiene dos contenedores. El primero es un contenedor init que inicia el servicio cloud-audit-setup de systemd en los nodos de Container-Optimized OS. El segundo contenedor, cos-auditd-fluent-bit, contiene una instancia de fluent-bit que está configurada para recopilar los registros de auditoría de Linux del diario de nodos y exportarlos a Cloud Logging.

El DaemonSet del registro de ejemplo registra los siguientes eventos:

  • Modificaciones de configuración del sistema de auditd
  • Comprobaciones de permisos de AppArmor
  • Ejecuciones execve(), socket(), setsockopt() y mmap()
  • Conexiones de red
  • Accesos de usuario
  • Sesión SSH y todos los demás TTY (incluidas las sesiones kubectl exec -t)

Configura el DaemonSet de registro

Configura el DaemonSet de registro con un ConfigMap, cos-auditd-fluent-bit-config. En el ejemplo proporcionado, se envían registros de auditoría a Logging, pero puedes configurarlo para que se envíen registros a otros destinos.

El volumen de los registros generados por auditd puede ser muy grande y puede generar costos adicionales debido a que consume recursos del sistema y envía más registros que la configuración de registro predeterminada. Puedes configurar filtros para administrar el volumen de registro:

Implementa el DaemonSet de registro

  1. Puedes usar un clúster existente o crear uno nuevo.

  2. Descarga los manifiestos de ejemplo:

    curl https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging.yaml > cos-auditd-logging.yaml

  3. Edita los manifiestos de ejemplo para adaptarlos a tus necesidades. Consulta la sección anterior para obtener detalles sobre cómo funciona DaemonSet. Ten en cuenta que la imagen fluent-bit que se usa en este manifiesto de muestra es solo para fines de demostración. Como práctica recomendada, reemplaza la imagen por una de una fuente controlada con un resumen SHA-256.

  4. Inicializa variables comunes:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Reemplaza lo siguiente:

    • CLUSTER_NAME: El nombre de tu clúster.
    • COMPUTE_REGION: La región de Compute Engine del clúster. Para los clústeres zonales, usa la zona.

  5. Implementa el DaemonSet, el ConfigMap y el Espacio de nombres de registro:

    envsubst '$CLUSTER_NAME,$CLUSTER_LOCATION' < cos-auditd-logging.yaml \
| kubectl apply -f -

  6. Verifica que los pods de registro se hayan iniciado. Si definiste un espacio de nombres diferente en tus manifiestos, reemplaza cos-auditd por el nombre del espacio de nombres que usas.

    kubectl get pods --namespace=cos-auditd

    Si los Pods están en ejecución, el resultado será el siguiente:

    NAME                                             READY   STATUS    RESTARTS   AGE
cos-auditd-logging-g5sbq                         1/1     Running   0          27s
cos-auditd-logging-l5p8m                         1/1     Running   0          27s
cos-auditd-logging-tgwz6                         1/1     Running   0          27s

    Se implementa un pod en cada nodo del clúster; en este caso, el clúster tiene tres nodos.

  7. Ahora, puedes acceder a los registros de auditoría en Logging. En el Explorador de registros, filtra los resultados con la siguiente consulta:

    LOG_ID("linux-auditd")
resource.labels.cluster_name = "CLUSTER_NAME"
resource.labels.location = "COMPUTE_REGION"

    Como alternativa, puedes usar la CLI de gcloud (usa --limit porque el conjunto de resultados puede ser muy grande):

    gcloud logging read --limit=100 "LOG_ID("linux-auditd") AND resource.labels.cluster_name = "${CLUSTER_NAME}" AND resource.labels.location = "${CLUSTER_LOCATION}""

Exporta registros

Para obtener información sobre cómo enrutar tus registros a destinos compatibles, consulta Configura y administra receptores.

Inhabilitar registros

Para inhabilitar el registro auditd en tus nodos, borra el DaemonSet de registro y, luego, implementa el DaemonSet cos-auditd-logging-disable para revertir los cambios del servicio systemd en cada nodo. Después de implementar este DaemonSet, no podrás habilitar el registro de auditd, a menos que se vuelvan a crear los nodos.

  1. Borra el DaemonSet de registro original y sus recursos relacionados:

    kubectl delete daemonset cos-auditd-logging -n cos-auditd
kubectl delete configmap fluent-bit-config -n cos-auditd
# The namespace will be deleted by the cleanup daemonset's namespace definition

  2. Aplica el DaemonSet de limpieza cos-auditd-logging-disable:

    kubectl apply -f 'https://raw.githubusercontent.com/GoogleCloudPlatform/k8s-node-tools/master/troubleshooting/os-audit/cos-auditd-logging-disable.yaml'

  3. Verifica que los Pods cleanup-auditd se estén ejecutando en todos tus nodos:

    kubectl get pods -n cos-auditd -l name=cleanup-auditd -w

    Espera hasta que todos los Pods muestren Running.

  4. Después de que se ejecuten los Pods de limpieza, confirma que no se generen registros nuevos de linux-auditd ejecutando las consultas de la sección Implementa el DaemonSet de registro. Por ejemplo, puedes usar el siguiente comando de gcloud CLI:

    gcloud logging read --limit=10 --freshness="5m" \
  "LOG_ID(\"linux-auditd\") AND \
  resource.labels.cluster_name = \"${CLUSTER_NAME}\" AND \
  resource.labels.location = \"${CLUSTER_LOCATION}\""

    Este comando busca registros de los últimos cinco minutos. Si la limpieza se realizó correctamente, el resultado estará vacío.

    Del mismo modo, cuando uses el Explorador de Cloud con el mismo filtro, no deberías ver ninguna entrada de registro nueva después de la hora de limpieza.

  5. Borra el DaemonSet y el espacio de nombres de limpieza:

    kubectl delete -f cleanup-auditd-daemonset.yaml

    Este comando borrará el DaemonSet y el espacio de nombres cos-auditd.

¿Qué sigue?