Add the support on clock_skew_seconds in request authentication

[freedomljc]

It's to mimic the support of clock_skew_seconds on jwt_authn https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/jwt_authn/v3/config.proto

[istio-policy-bot]

😊 Welcome @freedomljc! 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.

[istio-testing]

Hi @freedomljc. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[howardjohn]

In what scenario do you need more than a 60s clock skew?

[freedomljc]

In what scenario do you need more than a 60s clock skew?

I guess there're two scenarios we might want to adjust clock_skew_seconds:

• Short-lived JWT token: There's an example mentioned in jwt_authn: update to jwt_verify_lib with 1 minute clock skew envoyproxy/envoy#13872 (comment): By having short-lived JWT token that expires in ~5 minutes (or even shorter), 1 minute skew means at least 20% difference.
• Long-lived JWT token with more flexible handling on expired token: Instead of letting requestAuthentication directly reject the expired token, there could be a grey area regarding whether to handle the expired token: we can have subsequent envoy filter or domain app to decide based on business logic.

[howardjohn]

The short lived case is a pure hypothetical from 6 years ago not a real use case. It sounds more like what you want is not "clock skew" but to disable expiry validation?

[freedomljc]

The short lived case is a pure hypothetical from 6 years ago not a real use case. It sounds more like what you want is not "clock skew" but to disable expiry validation?

I'd like to disable the expiry validation within requestAuthentication and let subsequent components determine how to handle expired tokens instead.
Also, rather than hard-coding a 60-second clock skew, it would make more sense to make that value configurable.

[freedomljc]

@howardjohn , would you mind to follow-up and share your thoughts?

Having envoyfilter to override jwt_authn configuration is quite inconvenient, due to the MERGE operation in istio EnvoyFilter at this level requires the entire provider proto message, so all fields that istiod would normally generate must be re-declared. Additionally, to avoid configuring inlined jwks key material in envoyfilter, we'd need to have Envoyfilter with remote_jwks specified, which requires to create istio destination_rule/service_entry for generating envoy cluster.