Prisma Cloud Implementación de Defender en OpenShift causando que los pods HAProxy se bloqueen debido a que no hay espacio de búfer disponible en Netlink Socket

Prisma Cloud Implementación de Defender en OpenShift causando que los pods HAProxy se bloqueen debido a que no hay espacio de búfer disponible en Netlink Socket

9029
Created On 06/05/22 06:42 AM - Last Modified 05/09/23 08:18 AM


Symptom


  • Prisma Cloud La implementación de Defender en el entorno OpenShift está causando que los HAProxy Pods se bloqueen debido a que no hay espacio de búfer disponible en Netlink Socket.
  • Los registros de Kubelet sugieren que los pods HAProxy se reiniciaron debido a una falla en la respuesta a las sondas de vida con el siguiente mensaje de error:
    Container failed liveness probe
  • Por otro lado, los registros de Defender contienen los siguientes mensajes de error:
DEBU Failed to read from .. :HostTCPEgress runtimeData: : netlink receive: recvmsg: no buffer space available
Este comportamiento puede ser reproducido en OpenShift por:
  1. Recompilar el Defender con un búfer de socket de netlink mínimo
  2. Habilite la red Firewall nativa en la nube (CNNF).
  3. Pause el proceso de Defender durante algún tiempo para que el búfer se desborde.


Environment


  • Prisma Cloud
  • OpenShift


Cause


  • Aunque los registros de Defender muestran que la interrupción de la red (el búfer de enlace de red del espacio de usuario está lleno, lo que hace que los paquetes se caigan) ocurre exclusivamente por el monitoreo del host, la característica tiene un modelo de CNNF falla abierta que implica que los paquetes que no se pueden manejar para proporcionar un veredicto se volverán a inyectar en la CNNF pila y se aceptarán.
  • Sin embargo, las versiones del kernel < 4.6 no respetan el modelo de error de apertura cuando el búfer del espacio de usuario está lleno, sino sólo cuando la cola del kernel está llena.
  • Para las versiones del Kernel > = 4.6, este comportamiento ha sido parcheado y los paquetes serán reinyectados y aceptados en tales casos: Honor NFQA_CFG_F_FAIL_OPEN cuando falla la unidifusión netlink .
  • Estos hallazgos han sido confirmados a través de '/proc/net/netfilter/nfnetlink_queue : NfnetLinkQueue - file
Nota:
  1. RHEL 7.9 con la versión 3.10 del kernel elimina dichos paquetes.
  2. Ubuntu con Kernel versión 5.8 acepta tales paquetes.


Resolution


Los métodos factibles disponibles para resolver esto son:
  1. Desactive la supervisión del host en Radares > Configuración > desactive la "Supervisión de la red host". Para obtener más información, consulte: Cloud Native Network Firewall (CNNF)
Captura de pantalla 2022-06-05 en 2.02.57 PM.png

2. Actualice el host a una versión de kernel compatible de 4.18 o superior (por ejemplo. RHEL8 Host se basa en el Kernel 4.18 que contiene el parche).

3. Considere la posibilidad de aumentar el tamaño del búfer netlink del espacio de usuario a través de '/proc/sys/net/core/rmem_default' y '/proc/sys/net/core/rmem_max'. Si este valor será igual al tamaño de la cola nfqueue definido por el Defender, los paquetes nunca deben descartarse ya que el Kernel los volverá a inyectar y aceptará en la cuenta de que la cola está llena: https://elixir.bootlin.com/linux/v3.10/source/net/netfilter/nfnetlink_queue_core.c#L516.


Additional Information


  • Si desea continuar usando CNNF (Herramienta de monitoreo de red), actualice el Host a una versión compatible del Kernel de 4.18 o superior para que el Kernel pueda volver a inyectar paquetes de manera organizada para evitar que ocurran tales problemas.
  • Ejecutar el siguiente comando en los hosts le dará la versión exacta del kernel.
uname -r


Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000Cps9CAC&lang=es&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language