14 commentaires
C'est la galère quand mTLS lâche. TLS_ERROR peut être un paquet de trucs. Est-ce que les services qui foirent ont des SPIFFE IDs corrects ?
Check istioctl proxy-status et istioctl verify-install. S'il y a des différences d'Istio version sur tes pods ça peut mettre le bordel aussi.
Ouais et si Vault est la CA, faut voir les leases des certs. Est-ce que cert-manager arrive bien à renouveler ?
Regarde les logs du cert-manager controller et des Vault agent sidecars s'il y en a. Un vault status aussi, histoire de voir si la CA est pas scellée ou en panne.
Alors istioctl verify-install est clean. proxy-status aussi. Tout est sur SYNCED. Pas de versions mélangées.
Les Vault agent sidecars ne montrent rien d'anormal. Vault est unsealed et dispo. Par contre les CertificateRequest de cert-manager pour les Istio CA sont bloqués en Pending depuis des heures pour certains namespaces.
Précisément. Et c'est quoi ton Issuer ou ClusterIssuer Vault ? Comment il est configuré pour l'authentification à Vault ? Kubernetes Auth Method ?
On a déjà eu des soucis si le ServiceAccount utilisé par cert-manager n'a pas les bonnes permissions sur Vault pour le PKI backend.
Le ClusterIssuer est configuré pour Kubernetes Auth Method. Le ServiceAccount de cert-manager a les bonnes permissions, j'ai double-check les policies Vault. L'authentification au Vault API via JWT se fait nickel.
Les logs du cert-manager controller montrent :
I0503 10:45:01.12345 controller.go:123] "msg"="failed to sign request" "error"="Post \"https://vault.example.com:8200/v1/pki/sign/istio-intermediate\": dial tcp 10.0.0.10:8200: connect: connection refused"C'est un connection refused vers Vault ! Mais pas pour tous les CSR.
Connection refused vers Vault ? Ça sent la NetworkPolicy mal configurée ou un problème de ServiceEntry pour Vault si Istio gère son trafic.
Ou même un firewall OS côté cert-manager pod si c'est pas via Istio. C'est bizarre que ça ne le fasse pas pour tous les CSR.
Si c'est sporadique ou par namespace, c'est probablement une CiliumNetworkPolicy ou une Kubernetes NetworkPolicy qui s'applique de manière sélective.
Si vous utilisez Cilium, le connection refused peut aussi venir d'un eBPF hook qui rejette le paquet avant même qu'il n'atteigne iptables ou le processus. Lance un cilium monitor --type drop depuis un des cert-manager pods qui foire.
Je suis allé sur un cert-manager pod concerné et j'ai lancé cilium monitor --type drop.
Pendant la tentative de renouvellement :
DROP: Port denied (policy) flow 0x1234 from endpoint 5678 to endpoint 9012 (ip 10.1.2.3:4567 -> 10.0.0.10:8200)Ok c'est clairement Cilium qui drop le trafic. Mais on n'a pas de CiliumNetworkPolicy explicite pour le cert-manager namespace.
Port denied (policy) même sans CiliumNetworkPolicy explicite, ça peut être une Default Deny policy sur le namespace cert-manager ou une policy appliquée par Label Selector qui choperait le cert-manager pod par erreur.
Tu peux voir les policies appliquées à un pod avec `cilium endpoint get et chercher les policy IDs. Ou kubectl get cnp -A` pour toutes les voir.
C'est ça. Ou une policy au niveau du Node si tu as des règles plus globales. Ou même si Istio est en mode strict enforcement ça peut rajouter des règles eBPF que Cilium interprète.
Vérifie bien les labels du cert-manager pod et s'ils correspondent à un egress toEndpoints ou toCIDR d'une CiliumNetworkPolicy existante, même si elle n'est pas dans le même namespace.
Vous aviez raison. Il y avait une CiliumNetworkPolicy un peu trop générique qui utilisait un matchLabels qui choppait certains cert-manager pods dans certains namespaces (ceux qui ont un label app.kubernetes.io/component=controller)
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: deny-egress-to-vault
namespace: some-other-namespace
spec:
endpointSelector:
matchLabels:
app.kubernetes.io/component: controller
egress:
- toPorts:
- ports:
- port: "8200"
protocol: TCP
- toEntities:
- hostElle a été mise en place pour un autre service mais elle matchait aussi cert-manager et bloquait son accès à Vault.
J'ai corrigé la CiliumNetworkPolicy avec des selectors plus précis et les CertificateRequest sont en train de se signer. Les mTLS connections sont revenues à la normale.
Un grand merci pour le coup de main, le cilium monitor a été la clé !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut à tous
J'ai un souci bien relou sur notre cluster EKS 1.27 avec Istio 1.18. Depuis quelques jours on a des échecs de connexion aléatoires entre microservices inter-namespace. Les logs
Envoycôté client montrent des erreursupstream connect error or disconnect/reset before headers. reset reason: TLS_ERROR.On utilise
Vaultcomme CA pourIstioetcert-managergère la rotation. Je suis sûr que lesServiceEntryetVirtualServicesont ok.Quelqu'un a déjà vu ça ?