mTLS intermittent avec Istio et Vault sur services legacy

hello! souvent les problèmes mTLS avec des services legacy ça vient de la rotation des certs. tes services hérités ils rechargent bien les certs envoy injectés par istio/vault quand ils sont renouvelés?

c'est ça que je suspecte. vault renouvelle les certs. istio les injecte dans les sidecars envoy. mais si le pod legacy tourne depuis des semaines sans restart il pourrait avoir un trust bundle périmé?

exactement. le trust bundle du CA intermédiaire qui sert à signer tes certs mTLS a une durée de vie. si ton pod ne le rafraîchit pas il ne peut plus valider les nouveaux certs de ses peers

comment on force ça? on peut pas juste faire un rolling restart sur tous les services legacy toutes les 24h c'est risqué pour la prod

istio est censé gérer le rechargement via envoy. mais parfois si le service lui-même cache le trust bundle ou ne fait pas de reconnect il peut y avoir un souci. t'as regardé les logs du sidecar envoy pendant les erreurs?

les logs envoy montrent des erreurs du genre certificate_verify_failed ou TLSV1_ALERT_UNKNOWN_CA. ça confirme l'hypothèse

en fait le secret kubernetes contenant le trust bundle est bien mis à jour par istio. mais c'est le sidecar envoy dans le pod legacy qui ne voit pas toujours ce changement ou ne le propage pas au service application

mais l'application n'utilise pas le trust bundle. c'est envoy qui fait le mTLS. c'est envoy qui devrait le recharger non?

oui c envoy qui doit. mais il y a des versions d'envoy ou istio où ce rechargement n'est pas toujours optimal sans un cycle de vie du pod. surtout si le pod est très vieux. t'as quelle version d'istio?

istio 1.15. on a upgrade récemment mais les pods legacy n'ont pas été tous redéployés

1.15 ça devrait être bon. le problème c'est que le sidecar peut mettre du temps à voir la mise à jour des secrets kube. solution temporaire: rolling restart des services legacy sur une fenêtre de maintenance. solution long terme: mettre en place un Deployment ou statefulset avec un imagePullPolicy: Always et un trigger de redéploiement sur changement de configmap/secret

on peut pas faire de imagepullpolicy: always sur ces services c'est des déploiements très statiques. on a un job qui déploie ces services une fois

si c'est statique alors il faut un méchanisme qui force le pod à redémarrer ou à recharger sa config envoy. un operator qui watch les secrets istio et redémarre les pods si besoin. ou juste un cron qui fait un kubectl rollout restart deployment

un cron pour les restarts c'est la seule solution sans refactoriser les services legacy en profondeur. on va tester ça sur un environnement de staging d'abord

c'est la solution la plus simple pour l'instant. ça permet au sidecar de reprendre un nouveau lease avec le trust bundle à jour. assure-toi que tes HPA sont bien tunés pour absorber le traffic pendant le rolling update

j'ai mis en place un cron kubectl rollout restart toutes les 24h sur les services legacy critiques. plus d'erreurs 503 côté mtls. un peu bourrin mais ça fait le taf. thx tout le monde