Do not send 'failed with error' JWTs to the webhook authenticator #123871
Conversation
This change prevents authentication tokens that are handled and fail authentication via the service account or JWT authenticator from being sent to any configured webhook authenticator. The old behavior of forwarding these tokens to the webhook authenticator can be temporarily restored by disabling the StrictAuthenticationTokenHandling feature gate. Some important implementation details: tokenAuthenticators are now split into opaqueTokenAuthenticators and jwtSchemaAuthenticators but the webhook authenticator is modeled as as jwtSchemaAuthenticator because it just needs to come at the end. opaqueTokenAuthenticators and jwtSchemaAuthenticators are unioned and will continue to the next authenticator on error. Bootstrap tokens are handled before service account tokens (this should be a no-op since they have no schema overlap). Swap the ordering of the service account authenticators so that new style tokens are attempted first. The service account authenticators are unioned together because we do not validate that their issuers do not overlap. This should also be a no-op with a slight performance improvement since legacy tokens are rare in comparison to the new style service account tokens. jwtSchemaAuthenticators are unioned but will fail on the first error. Validation already guarantees that the JWT issuers of these authenticators never overlap, so the only behavioral change is that if a incoming JWT has an issuer that matches either the service account authenticators or the any JWT authenticators, they will never be sent to the webhook authenticator. Previously, if all of the prior JWT schema authenticators failed to validate the token, it would be sent to the webhook authenticator so that it could attempt to validate the token. Note that any non-JWT tokens will continue to be sent to the webhook authenticator, even if they fail with an error on any one of the previous opaqueTokenAuthenticators. Signed-off-by: Monis Khan <[email protected]>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enj The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/hold For remaining tasks noted above. |
|
Changelog suggestion (may be incorrect; I've based what I wrote on what I understood the existing text to mean) -Authentication tokens that are handled and fail authentication via the service account or JWT authenticator are no longer sent to any configured webhook authenticator. The old behavior of forwarding these tokens to the webhook authenticator can be temporarily restored by disabling the StrictAuthenticationTokenHandling feature gate.
+Revised how the API server treats authentication tokens that fail verification.
+For authentication tokens that are handled via the service account or JWT authenticator, and that fail authentication,
+these are no longer sent to any configured webhook authenticator. The previous behavior of forwarding such
+tokens to the webhook authenticator can be restored by disabling the `StrictAuthenticationTokenHandling`
+feature gate (which is beta, and is enabled by default). |
|
PR needs rebase. 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. |
|
Hello @enj 👋🏻 This PR has not been updated for a long time, so I'd like to check the status. The As the PR is tagged for 1.31, is it still planned for this release? |
|
Hi @enj, following up to check the status of this PR. Reminder: Code freeze starts |
|
/milestone v1.32 |
|
Hello @enj @thockin @apelisse |
|
/assign enj |
|
|
|
/milestone v1.33 I will sort it out next release. |
|
@enj |
|
Hello @enj @aramase Friendly reminder that code freeze is starting at 02:00 UTC Friday 21st March 2025 (about 4 weeks from now), and while there is still time, we want to ensure that each PR has a chance to be merged on time. As the issue is tagged for 1.33, is it still planned for this release? |
|
Just want to checking again whether this issue is still plan to resolve for v1.33 release? If so, a gentle reminder that the code freeze has started 02:00 UTC Friday 21st March 2025 . Please make sure related PRs have both lgtm and approved labels ASAP, and file an Exception if you haven't done it yet. |
|
This pr has not been updated for a long time, so I'd like to check what's the status. If there's anything we can do, please let us know. The code freeze is starting 02:00 UTC Friday 25th July 2025 (about 4 weeks from now). As the issue is tagged for 1.34, is it still planned for this release? Please make sure the PR has both lgtm and approved labels before the code freeze. Thanks! |
This change prevents authentication tokens that are handled and fail authentication via the service account or JWT authenticator from being sent to any configured webhook authenticator. The old behavior of forwarding these tokens to the webhook authenticator can be temporarily restored by disabling the StrictAuthenticationTokenHandling feature gate.
Some important implementation details:
tokenAuthenticators are now split into opaqueTokenAuthenticators and jwtSchemaAuthenticators but the webhook authenticator is modeled as as jwtSchemaAuthenticator because it just needs to come at the end. opaqueTokenAuthenticators and jwtSchemaAuthenticators are unioned and will continue to the next authenticator on error.
Bootstrap tokens are handled before service account tokens (this should be a no-op since they have no schema overlap).
Swap the ordering of the service account authenticators so that new style tokens are attempted first. The service account authenticators are unioned together because we do not validate that their issuers do not overlap. This should also be a no-op with a slight performance improvement since legacy tokens are rare in comparison to the new style service account tokens.
jwtSchemaAuthenticators are unioned but will fail on the first error. Validation already guarantees that the JWT issuers of these authenticators never overlap, so the only behavioral change is that if a incoming JWT has an issuer that matches either the service account authenticators or the any JWT authenticators, they will never be sent to the webhook authenticator. Previously, if all of the prior JWT schema authenticators failed to validate the token, it would be sent to the webhook authenticator so that it could attempt to validate the token.
Note that any non-JWT tokens will continue to be sent to the webhook authenticator, even if they fail with an error on any one of the previous opaqueTokenAuthenticators.
/kind bug
/kind api-change
/sig auth
/triage accepted
/milestone v1.31
Remaining tasks: