Prisma Cloud Le déploiement de Defender dans OpenShift provoque le blocage des modules HAProxy en raison de l’absence d’espace tampon disponible sur le socket Netlink

9029

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

Symptom

Prisma Cloud Le déploiement de Defender dans l’environnement OpenShift provoque le blocage des modules HAProxy en raison de l’absence d’espace tampon disponible sur Netlink Socket.
Les journaux Kubelet suggèrent que les capsules HAProxy ont redémarré en raison d’une incapacité à répondre aux sondes d’activité avec le message d’erreur suivant :
```
Container failed liveness probe
```
D’autre part, les journaux Defender contiennent les messages d’erreur suivants :

DEBU Failed to read from .. :HostTCPEgress runtimeData: : netlink receive: recvmsg: no buffer space available

Ce comportement peut être reproduit dans OpenShift par :

Recompilation du Defender avec un tampon de socket netlink minimal
Activer le réseau Firewall cloud natif (CNNF).
Suspendez le processus Defender pendant un certain temps pour provoquer le débordement de la mémoire tampon.

Environment

Prisma Cloud
OpenShift

Cause

Bien que les journaux de Defender montrent que la perturbation du réseau (le tampon netlink de l’espace utilisateur est plein, ce qui entraîne la chute des paquets) se produit exclusivement à partir de la surveillance de CNNF l’hôte, la fonctionnalité a un modèle d’ouverture intégrée impliquant que les paquets qui ne peuvent pas être traités pour fournir un verdict seront réinjectés dans la CNNF pile et acceptés.
Cependant, les versions < 4.6 du noyau ne respectent pas le modèle d’ouverture en cas de défaillance lorsque la mémoire tampon de l’espace utilisateur est pleine, mais uniquement lorsque la file d’attente du noyau est pleine.
Pour les versions du noyau > = 4.6, ce comportement a été corrigé et les paquets seront réinjectés et acceptés dans de tels cas : Honorez NFQA_CFG_F_FAIL_OPEN lorsque netlink unicast échoue.
Ces résultats ont été confirmés via '/proc/net/netfilter/nfnetlink_queue : NfnetLinkQueue - file

Remarque :

RHEL 7.9 avec la version 3.10 du noyau supprime ces paquets.
Ubuntu avec la version 5.8 du noyau accepte de tels paquets.

Resolution

Les méthodes réalisables disponibles pour résoudre ce problème sont les suivantes :

Désactivez la surveillance de l'hôte sous Paramètres de > radars > désactivez la surveillance du réseau hôte. Pour plus d’informations, reportez-vous à : Cloud Native Network Firewall (CNNF)

Capture d’écran 2022-06-05 à 2.02.57 PM.png

2. Mettez à niveau l’hôte vers une version du noyau prise en charge de 4.18 ou supérieure (par exemple. RHEL8 Host est basé sur le noyau 4.18 qui contient le correctif).

3. Envisagez d’augmenter la taille du tampon netlink de l’espace utilisateur via '/proc/sys/net/core/rmem_default' et '/proc/sys/net/core/rmem_max'. Si cette valeur est égale à la taille de file d’attente nfqueue définie par le Defender, les paquets ne doivent jamais être abandonnés puisque le noyau les réinjectera et les acceptera sur le compte que la file d’attente est pleine : https://elixir.bootlin.com/linux/v3.10/source/net/netfilter/nfnetlink_queue_core.c#L516.

Additional Information

Si vous souhaitez continuer à utiliser CNNF (outil de surveillance réseau), mettez à niveau l’hôte vers une version du noyau prise en charge de 4.18 ou supérieure afin que le noyau puisse réinjecter des paquets de manière organisée pour éviter que de tels problèmes ne se produisent.
L’exécution de la commande suivante sur les hôtes vous donnera la version exacte du noyau.

uname -r