Include x-forwarded-client-certificate header

Please describe your use case / problem.

When client-certificate verification is used, the x-forwarded-client-certificate (XFCC) header is not being set (or any equivalent one), so the client app can’t know the identity of the user making the request. I think this is required for client certificate validation to be useful.

Describe the solution you’d like

In the TLSContext definition, add a property that enables setting the XFCC header.

  apiVersion: ambassador/v1
  kind: TLSContext
  name: myapp-tls-context
  hosts:
  - myapp.blabla.org
  secret: myapp-server-tls
  ca_secret: myapp-cacert
  cert_required: true / false
  xfcc: true / false  <<== for example

The configuration could go further, and allow mapping Envoy’s “forward_client_cert_details” and “set_current_client_cert_details” properties.

https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/filter/network/http_connection_manager/v2/http_connection_manager.proto.html?highlight=forward_client_cert_details#enum-config-filter-network-http-connection-manager-v2-httpconnectionmanager-forwardclientcertdetails

Describe alternatives you’ve considered

I couldn’t find any.

Additional context

Nothing.

[ovk]

It looks like there is a possible workaround to add client certificate to headers.

I stumbled upon the following special field from Envoy:

https://github.com/envoyproxy/envoy/blob/92c085afaeeed138067f289fa9294d56afc91e25/source/common/router/header_formatter.cc#L261

that appear to work fine with Ambassador.

For example:

  add_request_headers:
    x-forwarded-client-cert: "%DOWNSTREAM_PEER_CERT%"

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.