Forward JWT Claims

[heilmela]

What question do you have?: Im in the process of migrating to contour and im a bit confused on how the (JWT) authn filter is typically used. In envoy the JWTs are verified (and decoded) and there a various options to forward claims. However contour seems to only support forwarding the authorization header/query parmeter, which forces the upstream to decode the token again to obtain any claims. (expecting the token to be already verified)

Additionally, its cumbersome to cover cases where authn is optional and clients are able to send authorization headers which would be decoded by the upstream without verifying the signature (since contour has no setting to optionally verify and decode the header). This makes the configuration a bit bloated.

Consider an example for optional authn where the endpoint /some/endpoint wants to use a verified identity (which can be empty) For that i have to duplicate endpoints (e.g. /some/endpoint).

• /some/endpoint where the JWT filter is disabled such that i need to rewrite the auth header (delete any auth header since it wont be verified by the upstream)
• /some/endpoint turn on JWT filter on the same endpoint to allow auth header with valid JWTs to pass through

It would be way easier by allowing the claims to be passed upstream in a custom header (e.g. x-identity) which would be set by the proxy on every request, thus the upstream can be sure that even empty claims are "verified" Now any upstream service can rely on the fact that either the header is populated with some verified data or its empty in case of the absence of authentication.

Even without taking optional auth into consideration i think it would make sense to allow some configuration on how the token claims are passed upstream, since it reduces the overhead of implementing JWT decoding in every upstream. (i know its only base64 but in a large architecture its quite a bit of overhead which has to be tested since its pretty important to correctly work with provided claims). Even worse when JWE is used and the upstream has to decrypt the token again (which renders the whole idea to be useless since every upstream has to repeat same process: fetch public keys + decrypt)

Anything else you would like to add: Envoy settings which would make the handling easier: "forward_payload_header" "pad_forward_payload_header": "payload_in_metadata": "header_in_metadata": "claim_to_headers": []

Environment:

• Contour version: 1.25
• Kubernetes version: (use kubectl version): 1.26
• Kubernetes installer & version: kubeone
• Cloud provider or hardware configuration: hetzner
• OS (e.g. from /etc/os-release): ubuntu LTS

[github-actions[bot]]

Hey @heilmela! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[sunjayBhatia]

Thanks for the detailed issue!

We had some contributors off-line express interest in this topic, particularly in being able to configure the payload_in_metadata field

Adding this as a help wanted feature