Stalls mTLS aléatoires sur Vault avec sidecars Envoy

Salut. Quand tu as des timeouts TLS aléatoires dans un mesh, il faut regarder si ce n'est pas lié au renouvellement des certificats par l'agent local.

Check les logs de ton sidecar `istio-proxy` au moment du bug avec `kubectl logs -c istio-proxy`. Regarde si tu vois des rotations de SDS (Secret Discovery Service).

Si c'est du mTLS pur, regarde aussi la MTU de ton interface réseau. Si un paquet de handshake (souvent gros à cause de la chaîne de certs) dépasse la MTU de ton tunnel (VXLAN ou Geneve), il est fragmenté.

Si un firewall ou une policy eBPF drop les fragments, ton handshake ne finira jamais. Lance un `tcpdump` pour voir la taille des paquets lors du Hello.

J'ai fait la capture. Effectivement, le certificat envoyé par Vault est énorme (on a une grosse chaîne de confiance intermédiaire).

Le paquet fait 1480 octets. Ma MTU sur les interfaces `veth` est à 1450 à cause de l'overlay Calico. On a de la fragmentation IP.

tcpdump -i eth0 -nn -vv 'port 8200'

Le kernel flaggue certains paquets avec le bit DF (Don't Fragment), donc ils sont jetés.

Bingo pour la MTU. Mais ça n'explique pas pourquoi c'est aléatoire. Normalement, si c'est trop gros, ça échouerait 100% du temps, non ?

Pas forcément. Ça dépend du chemin réseau pris par le paquet dans le mesh. Si ça passe par un gateway ou un autre node avec une config différente, ça peut changer.

Aussi, vérifie si Vault n'utilise pas des suites de chiffrement qui forcent des échanges de clés plus longs selon le client qui se connecte.

Je viens de voir un autre truc. Dans les logs de Vault, j'ai des `high heartbeat latency` pile au moment des timeouts TLS. Le processeur semble freezer.

[WARN] raft: heartbeat missed: last-index=123456

Est-ce que le processus d'encryptage TLS pourrait bouffer tout le temps CPU et retarder Raft ?

Possible si tu es sur des instances avec peu de coeurs. Vault est très sensible à la latence I/O et CPU pour son quorum Raft.

Si Envoy sature le CPU pour déchiffrer le mTLS, Vault n'a plus assez de cycles pour répondre aux heartbeats. Tu devrais isoler les coeurs CPU pour le processus Vault.

On est sur du `c6i.xlarge`, on devrait être larges. J'ai lancé `top` pendant un incident, et j'ai des pics de `sy` (system) énormes. Ça sent le syscall qui bloque.

J'ai fait un `strace -c -p $(pgrep vault)` et je vois énormément de temps passé dans `getrandom`.

Attends, `getrandom` ? C'est le kernel qui génère de l'entropie. Si ton pool d'entropie est vide, l'appel système bloque en attendant que le kernel récolte assez de bruit hardware.

C'est un problème connu sur les VMs sans hardware RNG pass-through. Vérifie la valeur dans `/proc/sys/kernel/random/entropy_avail`.

La valeur descend à 128 pendant les pics de connexion. C'est ultra bas !

Le handshake TLS appelle `getrandom` pour générer les secrets de session, et comme le kernel n'a plus assez d'entropie, il fait stalle le thread. Ça explique les 503 et les heartbeats manqués.

C'est ça. Pour corriger ça proprement sans changer d'instance, tu peux installer `rng-tools` ou `haveged` sur tes hosts pour réalimenter le pool d'entropie artificiellement.

Ou mieux, si tu es sur un kernel récent (5.6+), le kernel utilise une implémentation basée sur Chacha20 qui ne devrait plus bloquer. Quelle est ta version de kernel ?

On est sur une vieille image Amazon Linux 2 avec un kernel 4.14. On est en plein milieu d'une migration, mais on n'y est pas encore.

J'ai testé d'activer `rngd` sur un des noeuds :

systemctl start rngd
cat /proc/sys/kernel/random/entropy_avail

C'est remonté à 3000 instantanément.

Parfait. Teste tes pipelines CI/CD maintenant. Si le pool d'entropie reste haut, les handshakes TLS ne devraient plus jamais bloquer dans le kernel.

On a lancé 50 jobs en parallèle, zéro erreur. C'était bien la combinaison d'un kernel ancien et d'une forte demande en entropie pour le mTLS qui flinguait Vault.

Je vais packager `rngd` dans notre AMI de base pour tous les noeuds Vault. Merci pour l'aiguillage sur les syscalls, j'étais parti beaucoup trop loin sur le réseau Istio !