Habilitar registros de auditd de Linux en nodos de GKE

En esta página se explica cómo habilitar los registros de auditoría detallados del sistema operativo 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 registro 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 tus cargas de trabajo, como mensajes de error, intentos de inicio de sesión y ejecuciones binarias. Puede usar esta información para depurar problemas o investigar incidentes de seguridad.

No se admite la habilitación del registro de auditoría de Linux en los clústeres Autopilot de GKE, ya que Google gestiona los nodos y las máquinas virtuales subyacentes.

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

Antes de leer esta página, asegúrate de que conoces 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.

Información general

Para recoger los registros de cada nodo de un clúster, usa un DaemonSet, que ejecuta exactamente un pod en cada nodo del clúster en el que se puede programar el DaemonSet. Este pod configura el daemon de registro auditd en el host y el agente de registro para enviar los registros a Logging o a cualquier otro servicio de ingesta de registros.

Por definición, la auditoría se produce después de un evento y es una medida de seguridad retrospectiva. Los registros de auditd por sí solos probablemente no sean suficientes para llevar a cabo análisis forenses en tu clúster. Piensa cómo puedes usar mejor el registro de auditoría como parte de tu estrategia de seguridad general.

Limitaciones

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

Cómo funciona el DaemonSet de registro

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

El archivo de manifiesto de ejemplo define un DaemonSet, un ConfigMap y un espacio de nombres para contenerlos.

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 systemd cloud-audit-setup disponible en los nodos del SO optimizado para contenedores. El segundo contenedor, cos-auditd-fluent-bit, contiene una instancia de fluent-bit configurada para recoger los registros de auditoría de Linux del journal del nodo y exportarlos a Cloud Logging.

El DaemonSet de registro de ejemplo registra los siguientes eventos:

  • Modificaciones de la configuración del sistema auditd
  • Comprobaciones de permisos de AppArmor
  • Ejecuciones de execve(), socket(), setsockopt() y mmap()
  • conexiones de red
  • Inicios de sesión de usuarios
  • Sesión SSH y todos los demás TTYs (incluidas las sesiones kubectl exec -t)

Configurar el DaemonSet de registro

Puedes configurar el DaemonSet de registro mediante 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 envíe registros a otros destinos.

El volumen de registros que genera auditd puede ser muy grande y puede conllevar costes adicionales, ya que consume recursos del sistema y envía más registros que la configuración de registro predeterminada. Puedes configurar filtros para gestionar el volumen de registro:

Desplegar el DaemonSet de registro

  1. Puedes usar un clúster que ya tengas o crear uno.

  2. Descarga los manifiestos de ejemplo:

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

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

  4. Inicializa las variables comunes:

    export CLUSTER_NAME=CLUSTER_NAME
export CLUSTER_LOCATION=COMPUTE_REGION

    Haz los cambios siguientes:

    • CLUSTER_NAME: el nombre de tu clúster.
    • COMPUTE_REGION: la región de Compute Engine de tu clúster. En el caso de los clústeres zonales, usa la zona.

  5. Despliega el espacio de nombres, el DaemonSet y el ConfigMap 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 has definido otro espacio de nombres en tus manifiestos, sustituye cos-auditd por el nombre del espacio de nombres que estés usando.

    kubectl get pods --namespace=cos-auditd

    Si los pods están en ejecución, el resultado será similar al 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 puede 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"

    También 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}""

Exportar registros

Para saber cómo enrutar los registros a los destinos admitidos, consulta Configurar y gestionar sinks.

Inhabilitar registros

Para inhabilitar el registro de auditd, elimina el DaemonSet de registro y reinicia los nodos. La configuración de auditoría se bloquea una vez habilitada y solo se puede cambiar recreando el nodo.

  1. Elimina el DaemonSet, el ConfigMap y su espacio de nombres del clúster:

    kubectl delete -f cos-auditd-logging.yaml

  2. Reinicia los nodos del clúster. Primero, obtén el grupo de instancias al que pertenece:

    instance_group=$(gcloud compute instance-groups managed list \
                    --format="value(name)" \
                    --filter=${CLUSTER_NAME})

    A continuación, obtén las propias instancias:

    instances=$(gcloud compute instance-groups managed list-instances ${instance_group} \
               --format="csv(name)[no-heading][terminator=',']")

    Por último, vuelve a crear las instancias:

    gcloud compute instance-groups managed recreate-instances ${instance_group} \
   --instances=${instances}

Siguientes pasos