My hunch is that Pilot is not using mTLS to fetch the JWKS certs - and indeed if I exec into the pilot pod I’m not able to fetch the certificates.
If I use mTLS: PERMISSIVE for keycloak then Pilot can fetch the certificates, but I would rather avoid this.
How should my DestinationRule, Policy and MeshPolicy to instruct Pilot to use mTLS?
I talked with some folks and confirmed that we don’t go through sidecar by default when Pilot is fetching the Jwt public key, so then obviously mTLS fetching a IdP within cluster wont work…
And In future release, Pilot will use kube apiserver signed DNS cert. won’t have a sidecar.
I also remeber some customers are requiring to use customized key/cert when fetching public key (their IdP maybe is a normal https, with cert signed by internal CA). Maybe we can have some discussion/proposal around how to make this cutomizable…
From my perspective it would be very nice to make fetching of JWT public keys customizable.
My use-case is the following:
Istio ingress gateway with mTLS to downstream services
IdP issuing JWTs running mTLS, but without JWT checking, as this would cause a chicken-and-egg problem.
All services running mTLS and JWT checking from the IdP
controlPlaneSecurityEnabled: true
So the only thing in this setup that doesn’t support mTLS is Pilot. It seems un-intiutive that the IdP needs to run in Permissive mTLS mode instead of Strict.
Until we have a proposal for the above I think it should be mentioned in the documentation regarding JWT Policies that the JWKS URI cannot use mTLS.
It took quite some debugging to find out that mTLS was the problem
@incfly Is there any update on mTLS for Pilot when fetching the JWT public key or atleast support for customized key/cert in environments where the cert is signed by an internal CA?