Si tienes problemas con Workload Protection, utiliza las siguientes directrices para solucionar problemas. Si necesitas más asistencia, ponte en contacto con asistencia técnica de Datadog.
Flare de Security Agent
De forma similar al flare del Agent, puedes enviar la información necesaria de solucionar problemas al equipo de soporte de Datadog con un comando flare.
El flare pide confirmación antes de la carga, por lo que puedes revisar el contenido antes de que el Agent de seguridad lo envíe.
En los siguientes comandos, reemplaza <CASE_ID> con el identificador de tu caso de soporte de Datadog, si lo tienes, e introduce la dirección de correo electrónico asociada a él.
Si no tienes el identificador, simplemente introduce la dirección de correo electrónico que utilizas para iniciar sesión en Datadog para crear uno nuevo.
Para garantizar que la comunicación entre security-Agent y system-probe funcione según lo esperado y que Workload Protection sea capaz de detectar eventos del sistema, puedes activar manualmente los autotests ejecutando el siguiente comando:
El procedimiento de autotest crea algunos archivos temporales y reglas para monitorizarlos y, a continuación, activa dichas reglas para asegurar que los eventos se propaguen correctamente.
La siguiente respuesta aparece cuando se propagan las reglas.
Runtime self test: OK
Ahora puedes ver eventos procedente de runtime-security-agent en el Log Explorer.
Compatibilidad con complementos de red personalizados de Kubernetes
Las detecciones basadas en red de Workload Protection se basan en el subsistema de control de tráfico del kernel de Linux. Se sabe que este subsistema introduce condiciones de carrera si varios proveedores intentan insertar, sustituir o eliminar filtros en el qdisc de entrada “clsact”. Sigue la siguiente lista de comprobación para asegurarte de que Workload Protection esté configurado correctamente:
Comprueba si tu proveedor utiliza clasificadores de control de tráfico eBPF. Si no lo hace, puedes ignorar este párrafo.
Comprueba si tu proveedor devuelve TC_ACT_OK o TC_ACT_UNSPEC después de conceder acceso en un paquete de red. Si devuelve TC_ACT_UNSPEC, puedes ignorar este párrafo.
Comprueba a qué prioridad asigna tu proveedor sus clasificadores eBPF:
Si utilizan la prioridad 1, las detecciones de red de Workload Protection no funcionan en tus contenedores.
Si utilizan la prioridad 2 a 10, asegúrate de configurar runtime_security_config.network.classifier_priority a un número estrictamente inferior a la prioridad elegida por tu proveedor.
Si utilizan prioridad 11 o superior, puedes ignorar este párrafo.
Por ejemplo, existe un problema conocido con Cilium 1.9 e inferiores con Datadog Agent (versiones 7.36 a 7.39.1, excluida 7.39.2) que puede producirse cuando se inicia un nuevo pod. La acción race puede llevar a la pérdida de conectividad dentro del pod, según cómo esté configurado Ciliumred.
En última instancia, si no se puede configurar el Datadog Agent o tus proveedores externos para evitar que se produzca el problema, deberás desactivar las detecciones basadas en red de Workload Protection siguiendo los steps (UI) / pasos (generic) que se indican a continuación:
Añade el siguiente parámetro a tu archivo de configuración system-probe.yaml en instalaciones basadas en host:
runtime_security_config:network:enabled:false
Añade los siguientes valores si estás utilizando la Helm chart pública para desplegar el Datadog Agent:
Añade la siguiente variable de entorno si vas a desplegar manualmente el contenedor del Datadog Agent:
DD_RUNTIME_SECURITY_CONFIG_NETWORK_ENABLED=false
Desactivar Workload Protection
Para desactivar Workload Protection, sigue los steps (UI) / pasos (generic) correspondientes a tu plataforma del Agent.
Helm
En Helm values.yaml, configura securityAgent.runtime en enabled: false de la siguiente manera:
values.yaml
# values.yaml filedatadog:# Configurar en false para desactivar CWSsecurityAgent:runtime:enabled:false
Daemonset/Docker
Aplica el siguiente cambio de variable de entorno al despliegue de System Probe y de Segurity Agent para un Daemonset:
daemon.json
DD_RUNTIME_SECURITY_CONFIG_ENABLED=false
Host
Modifica system-probe.yaml y security-agent.yaml para desactivar la configuración del tiempo de ejecución:
Desactiva CSM en /etc/datadog-agent/system-probe.yaml. Asegúrate de que runtime_security_config esté configurado en enabled: false:
system-probe.yaml
############################################ Configuración del tiempo de ejecución de Security Agent #### #### Los parámetros para enviar logs a Datadog son #### obtenido de la sección `logs_config` #### en datadog-agent.yaml ############################################runtime_security_config:## @param enabled - boolean - optional - default: false## Configura en true para activar CSM completo.#enabled:false## @param fim_enabled - boolean - optional - default: false## Configura en true para activar solo la función de monitorización de integridad de archivos.# fim_enabled: false## @param socket - string - optional - default: /opt/datadog-agent/run/runtime-security.sock## La ruta completa del socket unix donde se accede al módulo del tiempo de ejecución de seguridad.## socket: /opt/datadog-agent/run/runtime-security.sock
Desactiva CSM en /etc/datadog-agent/security-agent.yaml. Asegúrate de que runtime_security_config esté configurado en enabled: false:
security-agent.yaml
############################################ Configuración del tiempo de ejecución de Security Agent #### #### Los parámetros para enviar logs a Datadog son #### obtenido de la sección `logs_config` #### en datadog-agent.yaml ############################################runtime_security_config:## @param enabled - boolean - optional - default: false## Configura en true para activar el módulo del tiempo de ejecución de seguridad.#enabled:false## @param socket - string - optional - default: /opt/datadog-agent/run/runtime-security.sock## La ruta completa del socket unix donde se accede al módulo del tiempo de ejecución de seguridad.## socket: /opt/datadog-agent/run/runtime-security.sock
