Logs de auditoría de Kubernetes

Documentos > Integraciones > Logs de auditoría de Kubernetes

Supported OS Linux Mac OS Windows

Información general

Recopila logs de auditoría de Kubernetes para realizar un seguimiento de todo lo que ocurre dentro de tus clústeres Kubernetes, incluyendo cada llamada realizada a la API Kubernetes por cualquier servicio. Esto incluye el plano de control (los controladores incorporados, el planificador), los daemons de nodo (kubelet, kube-proxy y otros), los servicios de clúster (como el autoescalador de clúster), los usuarios que realizan solicitudes kubectl e incluso la propia API Kubernetes.

Con la integración de los logs de auditoría de Kubernetes pueded diagnosticar problemas de permisos, identificar políticas RBAC que necesitan actualizarse y rastrear las solicitudes de API lentas que afectan a todo tu clúster. Profundiza en estos temas con la charla de Datadog en KubeCon 2019.

Configuración

Esta integración está disponible para el Agent v6.0 o posterior

Configuración

Para obtener más información sobre la configuración de los logs de auditoría de Kubernetes, consulta las auditorías de Kubernetes.

Para habilitar los logs de auditoría logs en Kubernetes:

Los logs de auditoría están deshabilitados por defecto en Kubernetes. Para habilitarlos en la configuración de tu servidor de API, especifica una ruta para el archivo de la política de auditoría:
```
kube-apiserver
  [...]
  --audit-log-path=/var/log/kubernetes/apiserver/audit.log
  --audit-policy-file=/etc/kubernetes/audit-policies/policy.yaml
```
Cree el archivo de la política en /etc/kubernetes/audit-policies/policy.yaml para especificar los tipos de solicitudes de API que quieres capturar en tus logs de auditoría. Las reglas de la política de auditoría se evalúan en orden. El servidor de API sigue la primera regla coincidente que encuentra para cada tipo de operación o recurso. Ejemplo de política de auditoría:

# /etc/kubernetes/audit-policies/policy.yaml

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
    # no registres solicitudes en los siguientes elementos
    - level: None
      nonResourceURLs:
          - '/healthz*'
          - '/logs'
          - '/metrics'
          - '/swagger*'
          - '/version'

    # limita el nivel a los Metadatos para que el token no se incluya en las especificaciones/el estado
    - level: Metadata
      omitStages:
          - RequestReceived
      resources:
          - group: authentication.k8s.io
            resources:
                - tokenreviews

    # auditoría extendida de la delegación de autenticación
    - level: RequestResponse
      omitStages:
          - RequestReceived
      resources:
          - group: authorization.k8s.io
            resources:
                - subjectaccessreviews

    # registra los cambios en los pods a nivel de RequestResponse
    - level: RequestResponse
      omitStages:
          - RequestReceived
      resources:
          # grupo de API central, añade servicios de API de terceros y tus servicios de API, si es necesario
          - group: ''
            resources: ['pods']
            verbs: ['create', 'patch', 'update', 'delete']

    # registra el resto de los elementos a nivel de los Metadatos
    - level: Metadata
      omitStages:
          - RequestReceived

En este ejemplo de archivo de política se configura el servidor de API para registrar con un máximo nivel de detalle determinados tipos de operaciones que generan cambios en un clúster (actualización, parche, creación, eliminación). También realiza un seguimiento de las solicitudes al recurso subjectaccessreviews al más alto nivel, para ayudar a solucionar los problemas de delegación de autenticación.

Es posible que quieras reducir el nivel de verbosidad a Metadata para los endpoints que contienen datos confidenciales, como el recurso tokenreviews. Datadog también omite la etapa RequestReceived de los logs.

En la última sección, para todo lo que no fue explícitamente configurado por las reglas anteriores, la política está configurada para registrar a nivel de Metadata. Como los logs de auditoría pueden ser verbosos, puedes elegir excluir acciones/verbos menos críticos, como por ejemplo las operaciones list, watch y get que no cambian el estado del clúster.

Recopilación de logs

Instala el Agent en tu entorno Kubernetes.
La recopilación de logs está deshabilitada por defecto. Habilítala en la sección env de tu DaemonSet:
```
env:
    # (...)
    - name: DD_LOGS_ENABLED
      value: 'true'
```

Monta el directorio del log de auditoría y también un directorio que el Agent utilice para almacenar un indicador para saber qué log se envió por última vez desde ese archivo. Para ello, añade lo siguiente en la sección volumeMounts del daemonset:

 # (...)
    volumeMounts:
      # (...)
      - name: pointdir
        mountPath: /opt/datadog-agent/run
      - name: auditdir
        mountPath: /var/log/kubernetes/apiserver
      - name: dd-agent-config
        mountPath: /conf.d/kubernetes_audit.d
  # (...)
  volumes:
    # (...)
    - hostPath:
        path: /opt/datadog-agent/run
      name: pointdir
    - hostPath:
        path: /var/log/kubernetes/apiserver
      name: auditdir
    - name: dd-agent-config
        configMap:
          name: dd-agent-config
          items:
            - key: kubernetes-audit-log
              path: conf.yaml
  # (...)

Esta acción también monta la carpeta conf.d que se utiliza para configurar el Agent para que recopile logs del archivo del log de auditoría.

Configura el Agent para recopilar logs de ese archivo con un ConfigMap:

kind: ConfigMap
apiVersion: v1
metadata:
    name: dd-agent-config
    namespace: default
data:
    kubernetes-audit-log: |-
        logs:
          - type: file
            path: /var/log/kubernetes/apiserver/audit.log
            source: kubernetes.audit
            service: audit