Expose PadForwardPayloadHeader in JWTRule

[dio]

Describe the feature request

Currently, when outputPayloadToHeader is specified in the JWTRule config there is no way to force padding the (base64) forwarded value. It is controlled by: pad_forward_payload_header on Envoy jwt_auth filter.

We need this PadForwardPayloadHeader to be exposed in JWTRule.

As comparisons with other products, in Consul we have this field exposed here: https://developer.hashicorp.com/consul/docs/connect/config-entries/jwt-provider#forwarding-padforwardpayloadheader.

Describe alternatives you've considered

We needed to craft our own EnvoyFilter.

Affected product area (please put an X in all that apply)

[x] Networking
[x] User Experience

[dio]

cc. @zirain

[howardjohn]

Can you explain why we need this? IIUC this means we are going to take a encoded token that we said we would forward and modify it? Why?

[dio]

Another service will consume the forwarded encoded token (produced by the envoy's jwt_authn filter) via the specified header. For some implementations, decoding base64 string without padding causes an issue (for example: a legacy service owned by a different team). Setting PadForwardPayloadHeader to true makes sure the encoded value has proper padding.

[MeruFM]

What @dio said is correct. The proxy/mesh/gateway team is often not the same team as underlying services that assume padded Base64. This is especially true when integrating onto large existing systems. Older versions of golang default to require padding.

Since this flag is already present in Envoy, there's likely use cases for it and should be reasonably expected here as well?