[
https://issues.apache.org/jira/browse/KNOX-3534?focusedWorklogId=1053407&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1053407
]
ASF GitHub Bot logged work on KNOX-3534:
----------------------------------------
Author: ASF GitHub Bot
Created on: 08/Nov/26 15:22
Start Date: 08/Nov/26 15:22
Worklog Time Spent: 10m
Work Description: lmccay commented on PR #1476:
URL: https://github.com/apache/knox/pull/1476#issuecomment-6723287096
@hsheinblatt - It has taken me a while to get my head around this enough to
formulate my questions. Sorry for the delay.
I want to revisit the need to split it into ingress and non-ingress routing
in more detail here. I also want to make sure that tokens with an actor
(delegated auth tokens) can be accepted via this path if required by the
deployment with a clear description as to why they sometimes shouldn't be.
Hairpinning calls could actually be required based on certain deployment
scenarios and this would break the ability to do that with delegated
authentication.
I need to better understand the source of non-delegated authn tokens that
might come through this path that would need audience enforcement. SSO related
tokens should have a separate topology path and enterprise tokens would need to
be federated tokens from the enterprise IDP.
OAuth client_credentials flow should also request a specific
resource/audience be included in the resulting acces token.
The only other possibility that I can think of is a service account
projected credential. These could potentially have audiences included by
depending on a deployment. But s2s traffic doesn't require a hairpinning call
unless there is some cross cluster complication for the involved services that
prevent multi-cluster mesh or some other mechanism from working. In which case,
I would expect a same subject token exchange for the other service to be done.
And this used through the ingress. But this PR would block that.
Anyway, I could use a bit more description of what we are preventing here by
disallowing delegated authn tokens and what unscoped user tokens we would
expect through the ingress and this topology path.
Issue Time Tracking
-------------------
Worklog Id: (was: 1053407)
Time Spent: 1h (was: 50m)
> Add k8s request audience validator bypass for JWTs from an ingress
> ------------------------------------------------------------------
>
> Key: KNOX-3534
> URL: https://issues.apache.org/jira/browse/KNOX-3534
> Project: Apache Knox
> Issue Type: Sub-task
> Components: JWT
> Reporter: Harrison Sheinblatt
> Assignee: Harrison Sheinblatt
> Priority: Major
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The existing K8sDestinationAudienceValidator feature focus on service to
> service audience validation. Enable using the validator for the use case
> where a single topology is to validate all jwts, both service to service and
> ingress traffic JWTs.
> Add flags to enable a feature to match JWTs coming from an ingress gateway
> and treat them differently: either validate the audience against the same
> static whitelist used for the rest of the traffic, or skip audience
> validation. This path would be split and evaluated first. Delegation tokens
> are not allowed on that path, so even if they come from an ingress, still
> treat them as they are now.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
