Problème mTLS / Vault / Istio sur EKS certains services ne communiquent plus

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.

Ah, `CertificateRequest` en `Pending` c'est le signe d'un problème avec l'`Issuer` ou avec la com' entre `cert-manager` et `Vault`.

Quelle est l'erreur dans les logs de `cert-manager controller` quand il tente de signer le `CSR` via `Vault` ?

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 -o json` 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:
      - host

Elle a été mise en place pour un autre service mais elle matchait aussi `cert-manager` et bloquait son accès à `Vault`.

Classic. Les `label selectors` qui débordent. `Cilium` est puissant mais faut faire gaffe aux `matchLabels`.

Le `Port denied (policy)` était clair. Contente que ça soit résolu.

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