[
https://issues.apache.org/jira/browse/KNOX-3491?focusedWorklogId=1044192&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1044192
]
ASF GitHub Bot logged work on KNOX-3491:
----------------------------------------
Author: ASF GitHub Bot
Created on: 26/Sep/26 21:30
Start Date: 26/Sep/26 21:30
Worklog Time Spent: 10m
Work Description: hsheinblatt opened a new pull request, #1432:
URL: https://github.com/apache/knox/pull/1432
KNOX-3491 - Add pluggable request audience validation, with a Kubernetes
destination validator
## What changes were proposed in this pull request?
Adds a pluggable mechanism for validating a JWT's aud claim, and one
implementation that checks a delegation token's audience against the
request's actual destination rather than against a fixed configured
list.
RequestAudienceValidator is the pluggable check, modeled on the
existing PreAuthValidator pattern and discovered via ServiceLoader
(RequestAudienceValidatorService), resolved by a filter's
request.audience.validator init parameter. AbstractJWTFilter gains a
validator-accepting overload of doFullTokenValidation()/
validateToken(); the existing methods become one-line forwarders onto
the previous fixed-list behavior (matchesConfiguredAudiences()), so
every call site is unaffected unless it opts in. JWTFederationFilter
is the only call site wired to it; with request.audience.validator
unset its behavior is unchanged.
The one implementation added, K8sDestinationAudienceValidator
(request.audience.k8s.destination.validation), only engages for a
token carrying a delegation act claim. Each aud entry is expected to
be a URL of the form
https://cluster-domain[:port]/namespace/service-name[/resource-path],
parsed by the new AudienceResource record. An optional
request.audience.k8s.audience.path.prefix lets an entry carry extra
leading path segments before namespace and service-name, e.g. for
network routing; left unset, namespace and service-name must begin
straight after the authority. Which segments are actually compared
is driven by which trusted-header init params are configured:
namespace from a destination SPIFFE-id header
(SpiffeId, relocated from gateway-provider-security-k8s into
gateway-spi) and/or a Kubernetes server-name header (parsed by the
new DestinationServiceName record); service-name only from the
server-name header; resource-path only from a dedicated path header.
cluster-domain, checked against an allow-list, is always enforced.
At least one header param must be configured or init fails fast; when
both namespace sources are configured, they must agree or the request
is rejected fail-closed.
Every header this validator reads is trusted at face value with no
independent verification
Issue Time Tracking
-------------------
Worklog Id: (was: 1044192)
Remaining Estimate: 0h
Time Spent: 10m
> Allow JWT aud validation against request header values and include an initial
> delegation token only validator
> -------------------------------------------------------------------------------------------------------------
>
> Key: KNOX-3491
> URL: https://issues.apache.org/jira/browse/KNOX-3491
> Project: Apache Knox
> Issue Type: Sub-task
> Components: JWT
> Reporter: Harrison Sheinblatt
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Extend JWT aud claim validation to allow for custom validators that require
> the request parameter so they can validate against the destination from
> headers. Retain the existing default that validates aud claims against a
> fixed, configured allow list.
> Add a validator implementation that can validate delegation JWTs, those with
> an act claim, for kubernetes environments. aud claim values in such tokens
> were already authorized via delegation policy which can include allowed
> audience lists. This validation restricts those tokens so that they can be
> used only for k8s destinations that match. Provide flexibility in the headers
> used and enable partial matching of the aud claim so that parts of the
> destination can be used to validate the aud claim. This allows one to
> validate what can be validated in more different k8s configurations, even if
> all the destination information is not available via trusted headers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
