Add require_expiration field to JWTRule

[laiwaikin]

What this PR does

Adds a new requireExpiration boolean field to RequestAuthentication's JWTRule (under spec.jwtRules).

When set to true, a JWT that does not carry an expiration (exp) claim is rejected. This enforces that every accepted token is short-lived and will eventually expire — a recommended posture for zero-trust deployments that rely on token expiration rather than revocation (e.g. SPIFFE JWT-SVID expiration restrictions).

This simply surfaces Envoy's existing jwt_authn require_expiration option through the Istio API. Today operators can only enable it via a brittle, low-level EnvoyFilter; this makes it a first-class, declarative field. The default value is false, which preserves the current behavior (a JWT without an exp claim is accepted and treated as non-expiring), so the change is fully backward compatible.

Notes

• Only request_authentication.proto is hand-edited; the .pb.go, .pb.html, and customresourcedefinitions.gen.yaml changes are generated via make gen.
• I'm willing to implement the full feature. This API PR is step 1; the istiod wiring (JwtProvider.require_expiration) plus tests will follow in istio/istio once this lands. Happy to bring it to the security working group if needed.

Part of istio/istio#59200

[istio-policy-bot]

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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: laiwaikin / name: Ted Li (a1bc551)

[istio-testing]

Hi @laiwaikin. 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.