feat: add `presence: IGNORED` and `failedStatusMetadataKey` to JWTRule by sayap · Pull Request #3801 · istio/api

sayap · 2026-10-09T02:57:00Z

presence: IGNORED makes the requirement always satisfied. In this mode, requests with a missing token and requests with an invalid token are both allowed.

failedStatusMetadataKey, if set, adds verification failure to the dynamic metadata under this key, such that failures are always observable regardless of the presence value.

istio-testing · 2026-10-09T02:57:13Z

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

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

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.

istio-testing · 2026-10-09T02:57:13Z

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

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

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.

sayap · 2026-10-09T03:04:10Z

This builds on top of #3737, mapping presence: IGNORED to allow_missing_or_failed in Envoy, to support the 1st bullet point of istio/istio#43982, while making it observable.

In Consul, this is even hardcoded to be allow_missing_or_failed.

keithmattix · 2026-10-19T16:29:47Z

/ok-to-test

keithmattix · 2026-10-19T17:18:04Z

Can you provide some more context on the exact-use case here and what this API will solve?

howardjohn · 2026-10-19T17:19:35Z

+  // If set to true, a verification failure is written to the filter's dynamic metadata
+  // under the fixed key `istio_jwt_verification_failure`. The failure is then observable
+  // even when the request is not rejected, such as when `presence` is `IGNORED`.
+  bool failed_status_in_metadata = 16;


This feels like something that should just be not a flag and used if IGNORED is used

Yeah I was undecided about this, and then I thought it might be useful to also enable this flag with OPTIONAL / REQUIRED as well.

In our case, when we transition a provider from IGNORED (dry-run) to OPTIONAL (enforce), keeping the same level of observability is desirable. So we just leave this flag enabled all the time.

I have changed this from bool to string. Previously, I used bool to be consistent with the hardcoded EnvoyJwtFilterPayload = "payload". However, payload is more for internal usage, and there can only be one anyway. Meanwhile, this failed status is more external facing, to be used in conjunction with Telemetry CR, Lua filter, etc. Furthermore, when there are multiple providers, Envoy can add multiple verification failures to dynamic metadata. So I think a configurable string field is a better fit here.

sayap · 2026-10-20T02:34:28Z

Can you provide some more context on the exact-use case here and what this API will solve?

We want to handle the first scenario described in istio/istio#43982, i.e. having a dry-run period where a mistake in mesh config or a misbehaving client does not result in 401.

keithmattix · 2026-10-20T13:09:46Z

    REQUIRED = 1;
+
+    // The JWT requirement is always satisfied. A request with a missing or
+    // failed token is not rejected. A present token is still verified and


Can we tighten the language so it's clear what a "failed" token is? It should be clear to users what the difference between IGNORED and OPTIONAL is

Right, I updated the wordings to use "invalid" instead of "failed" (this came from Envoy), and also show the difference between the 3 options.

keithmattix · 2026-11-04T05:19:03Z

+  // `{"code": 3, "message": "Jwt is expired"}`. When there are multiple
+  // providers, each one should use its own key, otherwise failures can
+  // overwrite each other.
+  string failed_status_in_metadata = 16;


nit: I think this should be failed_status_metadata_key but we can fix in a follow up

Thanks, that's a good suggestion. I should rename it

Renamed, let me update the PR title and description as well

`presence: IGNORED` makes the requirement always satisfied. In this mode, requests with a missing token and requests with an invalid token are both allowed. `failedStatusMetadataKey`, if set, adds verification failure to the dynamic metadata under this key, such that failures are always observable regardless of the `presence` value.

sayap requested a review from a team as a code owner October 9, 2026 02:57

istio-testing added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. needs-ok-to-test labels Oct 9, 2026

istio-testing added ok-to-test Set this label allow normal testing to take place for a PR not submitted by an Istio org member. and removed needs-ok-to-test labels Oct 19, 2026

howardjohn reviewed Oct 19, 2026

View reviewed changes

keithmattix reviewed Oct 20, 2026

View reviewed changes

sayap force-pushed the jwt-authn-presence-ignored branch from 2cac46c to 0561058 Compare October 21, 2026 12:57

istio-testing added the needs-rebase Indicates a PR needs to be rebased before being merged label Nov 3, 2026

sayap force-pushed the jwt-authn-presence-ignored branch from 0561058 to 0996cc9 Compare November 3, 2026 23:08

istio-testing removed the needs-rebase Indicates a PR needs to be rebased before being merged label Nov 3, 2026

keithmattix previously approved these changes Nov 4, 2026

View reviewed changes

sayap dismissed keithmattix’s stale review via 2d46074 November 4, 2026 05:26

sayap force-pushed the jwt-authn-presence-ignored branch from 0996cc9 to 2d46074 Compare November 4, 2026 05:26

sayap changed the title ~~feat: add presence: IGNORED and failedStatusInMetadata to JWTRule~~ feat: add presence: IGNORED and failedStatusMetadataKey to JWTRule Nov 4, 2026

keithmattix approved these changes Nov 4, 2026

View reviewed changes

Conversation

sayap commented Oct 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

istio-testing commented Oct 9, 2026

Uh oh!

istio-testing commented Oct 9, 2026

Uh oh!

sayap commented Oct 9, 2026

Uh oh!

keithmattix commented Oct 19, 2026

Uh oh!

keithmattix commented Oct 19, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sayap commented Oct 20, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

sayap commented Oct 9, 2026 •

edited

Loading