mTLS intermittent avec Istio et Vault sur services legacy

Question

salut! on a istio en mode mTLS strict avec vault pour les certs. sur les services récents nickel. mais sur des services legacy qui sont rarement mis à jour on a des erreurs de handshake mTLS genre 503 upstream connect error ou tls handshake timeout
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: global-allow-all
spec:
  rules:
  - {}

mathilde-carpentier · Answer

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?

yclerc · Answer

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é?

guy-carre · Answer

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

yclerc · Answer

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

mathilde-carpentier · Answer

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?

yclerc · Answer

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

josette76 · Answer

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

yclerc · Answer

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

guy-carre · Answer

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?

yclerc · Answer

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

mathilde-carpentier · Answer

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

yclerc · Answer

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

josette76 · Answer

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

yclerc · Answer

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

mathilde-carpentier · Answer

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

yclerc · Answer

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

mTLS intermittent avec Istio et Vault sur services legacy

16 commentaires

Laisser une réponse

Les Datas Source sur Terraform

Découverte et utilisation de l'outil Packer

Configuration des clés SSH pour sécuriser vos accès GitLab

Comment fusionner vos commits avec le Squash sur GitLab

Ajouter des utilisateurs sur GitLab et gérer la collaboration

Rejoindre la communauté