JWT SecurityPolicy does not forward Authorization header by default

[akhenakh]

The JWT SecurityPolicy if enabled does not forward the Authorization header upstream.

This is the default behaviour in Proxy if forward is not set to true:
https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter#jwtprovider

Yet it is a weird behaviour for a gateway to temper headers from the original request.

https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter#jwtprovider
relevant code

gateway/internal/xds/translator/jwt.go

Lines 139 to 145 in f3e4e93

	jwtProvider := &jwtauthnv3.JwtProvider{
	Issuer: irProvider.Issuer,
	Audiences: irProvider.Audiences,
	JwksSourceSpecifier: remote,
	PayloadInMetadata: irProvider.Issuer,
	ClaimToHeaders: claimToHeaders,
	}

Adding Forward: true will result of not removing the Authorization header.

I'm not sure myself what would be a sane default, but this could become a parameter or at least documented in Gateway.

[akhenakh]

Slack discussion https://envoyproxy.slack.com/archives/C03E6NHLESV/p1701708137782169

[zhaohuabing]

Thank you @akhenakh for raising this.

We have two options here:

1. Expose Envoy forward knob to EG SecurityPolicy API and let the users decide whether to forward the jwt or not
2. Set forward to true when translating the xds without exposing it to EG API

I am leaning towards option 2 because it doesn't harm to pass down the JWT token header. WDYT @arkodg @envoyproxy/gateway-maintainers

[arkodg]

looks like we went ahead with 2. which was completed with #2300, can this be closed @zhaohuabing ?

[zhaohuabing]

looks like we went ahead with 2. which was completed with #2300, can this be closed @zhaohuabing ?

Yes, this isssue can be closed.

We don't have to modify API with option 2. And if we need to give users the choice to move the token out later, we can add it to the API.