Added support for configuring JWKS using local file

[wulianglongrd]

fix istio/istio#50196

[istio-policy-bot]

🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?

Courtesy of your friendly test nag.

[istio-policy-bot]

😊 Welcome @wulianglongrd! This is either your first contribution to the Istio api repo, or it's been
a while since you've been here.

You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines
by referring to Contributing to Istio.

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[howardjohn]

Is the real use case here "load from secret" and we are implementing it by "load from file" when its maybe not the best option? Or do we think file is a primary use case?

cc @louiscryan @costinm @aryan16

[wulianglongrd]

JWKS is a public key set, so I don't think it is security sensitive.

update: I realize that we are not describing the same thing: I meant that the file is local to envoy, not to istiod.

[howardjohn]

Isn't the use case in istio/istio#50196 that is linked stating it is private for their use case?

[wulianglongrd]

Oh yes. From what I understand, the Secret is just the way the file is stored, not how envoy perceives it? After the Secret is mounted to the container, is it just a normal text file to envoy? (I'm not familiar with kubernetes, I would be grateful if you could point out my mistake)

@ks-yim Can you describe your operation in detail? It would be nice to describe how envoy reads and uses mounted Secret. Thanks.

[howardjohn]

Oh yes. From what I understand, the Secret is just the way the file is stored, not how envoy perceives it? After the Secret is mounted to the container, is it just a normal text file to envoy? (I'm not familiar with kubernetes, I would be grateful if you could point out my mistake)

Correct. But Istio can also read Secrets directly and send them to envoy.

On that note - JWKS are generally considered public and shown directly in envoy config dumps, logs, etc. Secrets are not shown. This may be problematic

[wulianglongrd]

No matter if the jwks is public or private, it should be public to envoy. We can use Secret or any other method to mount the file, as long as the end result for envoy is a readable local file.

I think this api just tells envoy to read a file from a certain address, and envoy doesn’t care why the file exists.

Also, like you said, if istio reads the Secret directly and sends it to envoy, then it will be directly shown in the envoy config dumps. But using files will not, so this api seems to have its purpose.

[howardjohn]

Also, like you said, if istio reads the Secret directly and sends it to envoy, then it will be directly shown in the envoy config dumps. But using files will not, so this api seems to have its purpose.

No, certificate private keys are sent from Secret to envoy and obscured in config dumps, logs, etc.

[hzxuzhonghu]

Loading jwks from local file is commonly used in microservice. But in istio managed no matter sidecar or gateway, mounting secret seems not that native.

[ks-yim]

The motivation of istio/istio#50196 was that there's no easy way to securely validate JWTs signed by symmetric key algorithms without leaking private jwks somewhere in plaintext and I wish istio has a native API to support this use case.

The original workflow that I had in mind was mounting a Secret that contains jwks as file onto istio-proxy container and let jwt_authn filter refer to the mounted file and I thought this can be achieved without excessive efforts because Envoy's jwt_auhtn has the feature built-in. jwks are not leaked because only the filename will be shown in the config dump.

This, though, requires users an extra work to mount the secret on their own to istio-proxy container and if there's still a room for improvement on how istio-proxy reads the secret, I am up for it.

(BTW, glad that someone in Istio team looked into this. Many thanks!)

[wulianglongrd]

Also, like you said, if istio reads the Secret directly and sends it to envoy, then it will be directly shown in the envoy config dumps. But using files will not, so this api seems to have its purpose.

No, certificate private keys are sent from Secret to envoy and obscured in config dumps, logs, etc.

Send using SDS? Otherwise, how does it work?

[wulianglongrd]

friendly ping @louiscryan @costinm @aryan16

Could you please take a look and provide some suggestions for improvement?

[costinm]

How about just allowing jwksURI to use a file:// prefix ? I.e. just doc change in this PR.

[wulianglongrd]

How about just allowing jwksURI to use a file:// prefix ? I.e. just doc change in this PR.

I think it's good.

[wulianglongrd]

Close, it looks like implementing it by extending jwksURI is possible.