16 commentaires
ton erreur sent le mismatch entre la clé privée et le certificat qui sont streamés par sds vers envoy
j'ai dump la config de l'endpoint qui fail et tout a l'air cohérent au niveau du hash
istioctl pc secret my-pod-name -o jsonlance un openssl s_client sur le port du sidecar pour voir ce qu'il présente réellement pendant le handshake
j'ai fait le test et voilà le résultat ça pique les yeux
depth=0 CN = my-service.default.svc.cluster.local
verify error:num=20:unable to get local issuer certificatetu utilises quelle version du vault-agent-injector parce que les vieilles versions géraient mal le bundle fullchain
on est en 0.25.0 et on utilise le template standard pour injecter les certifs dans les volumes partagés
voici le bout de code incriminé
{{ with secret "pki/issue/my-role" "common_name=my-service" }}
{{ .Data.certificate }}
{{ end }}tu récupères juste .Data.certificate donc tu n'as pas l'intermediate ca c'est pour ça que la validation mtls explose
si je concatène comme ça ça devrait suffire non
{{ .Data.certificate }}
{{ .Data.issuing_ca }}oui exactement mais fais attention à l'ordre sinon la lib ssl va encore râler sur le format du pem
ça fonctionne enfin les handshakes passent tous et l'erreur a disparu des logs envoy
merci les gars je vais aller corriger tous nos templates avant que la prochaine rotation globale ne casse tout le reste
Laisser une réponse
Vous devez être connecté pour poster un message !
gros souci sur notre mesh istio dès qu'on a une rotation de certificats via vault les sidecars se mettent à rejeter les connexions avec une erreur cryptolib mystérieuse
le pire c'est que ça ne touche que certains services de manière aléatoire et les logs envoy sont pas très causants sur l'origine du mauvais flag