Prisma Cloud Defender-Bereitstellung in OpenShift führt zum Absturz von HAProxy-Pods, da im Netlink-Socket kein Pufferspeicher verfügbar ist

9051

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

Symptom

Prisma Cloud Die Defender-Bereitstellung in der OpenShift-Umgebung führt zum Absturz der HAProxy-Pods, da im Netlink-Socket kein Pufferspeicher verfügbar ist.
Kubelet-Protokolle schlagen vor, dass HAProxy-Pods aufgrund eines Fehlers bei der Beantwortung von Liveness-Tests mit der folgenden Fehlermeldung neu gestartet wurden:
```
Container failed liveness probe
```
Auf der anderen Seite enthalten Defender-Protokolle die folgenden Fehlermeldungen:

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

Dieses Verhalten kann in OpenShift reproduziert werden durch:

Neukompilieren des Defender mit minimalem Netlink-Socket-Puffer
Aktivieren Sie das Cloud Native Network Firewall (CNNF).
Halten Sie den Defender-Prozess für einige Zeit an, damit der Puffer überläuft.

Environment

Prisma Cloud
OpenShift

Cause

Obwohl Defender-Protokolle zeigen, dass Netzwerkunterbrechungen (der Netlink-Puffer im Benutzerbereich ist voll, was dazu führt, dass die Pakete verworfen werden) ausschließlich durch CNNF die Hostüberwachung auftreten, verfügt das Feature über ein Fail-Open-Modell, das bedeutet, dass Pakete, die CNNF nicht verarbeitet werden können, um ein Urteil zu fällen, erneut in den Stapel injiziert und akzeptiert werden.
Die Kernel-Versionen < 4.6 berücksichtigen das Fail-Open-Modell jedoch nicht, wenn der Userspace-Puffer voll ist, sondern nur, wenn die Kernel-Warteschlange voll ist.
Für Kernel-Versionen > = 4.6 wurde dieses Verhalten gepatcht und Pakete werden in solchen Fällen erneut injiziert und akzeptiert: Honor NFQA_CFG_F_FAIL_OPEN, wenn Netlink Unicast fehlschlägt .
Diese Ergebnisse wurden über '/proc/net/netfilter/nfnetlink_queue : NfnetLinkQueue - file bestätigt

Hinweis:

RHEL 7.9 mit Kernel-Version 3.10 verwirft solche Pakete.
Ubuntu mit Kernel-Version 5.8 akzeptiert solche Pakete.

Resolution

Die verfügbaren praktikablen Methoden, um dieses Problem zu beheben, sind:

Deaktivieren Sie die Host-Überwachung unter Radargeräte > Einstellungen > deaktivieren Sie die "Host-Netzwerküberwachung". Weitere Informationen finden Sie unter: Cloud Native Network Firewall (CNNF)

2. Aktualisieren Sie den Host auf eine unterstützte Kernel-Version von 4.18 oder höher (z. RHEL8 Host basiert auf Kernel 4.18, der den Patch enthält).

3. Erwägen Sie, die Größe des Userspace-Netlink-Puffers über '/proc/sys/net/core/rmem_default' und '/proc/sys/net/core/rmem_max' zu erhöhen. Wenn dieser Wert der vom Defender definierten nfqueue-Warteschlangengröße entspricht, sollten Pakete niemals verworfen werden, da der Kernel sie erneut injiziert und akzeptiert, wenn die Warteschlange voll ist: https://elixir.bootlin.com/linux/v3.10/source/net/netfilter/nfnetlink_queue_core.c#L516.

Additional Information

Wenn Sie das Netzwerküberwachungstool weiterhin verwenden CNNF möchten, aktualisieren Sie den Host auf eine unterstützte Kernel-Version von 4.18 oder höher, damit der Kernel in der Lage ist, Pakete auf organisierte Weise erneut einzuschleusen, um das Auftreten solcher Probleme zu vermeiden.
Wenn Sie den folgenden Befehl auf den Hosts ausführen, erhalten Sie die genaue Kernel-Version.

uname -r