Passing the client CN as a header variable or a header

[nyodas]

Title: Passing the client CN as a header variable or a header

Description:

When using Envoy for client-cert proxy authentication, it would be useful to be able to specify a Header where the client CN is passed. Or a header variable like %SSL_CLIENT_S_CN% or similar.

Use case

We currently have a need to pass the client certificate common name to the envoy backend. Particularly via a header. (The name does not matter in that case) Unfortunately the value of the header can not be parsed further down (Leaving us unable to use the xfcc header.)

Apache,hap,nginx (with some lua) are able to pass that informations along fairly easily. We however want to keep using envoy for the cool apm/tracing integration , hitless reload etc. We're particularly interested in the seamless restarts on certificate rotations and plan to have a SDS sidecar dedicated to that effect. Also because as we move to istio we're gonna use envoy more an more and having it everywhere means we get to know it better.

[Relevant Links] One of those backend could be kubernetes apiserver apache

[htuch]

@nyodas does https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#config-http-conn-man-headers-x-forwarded-client-cert meet your needs?

[nyodas]

Unfortunately no. Because the value set in the header is too complex for the downstream app.

for example x-forwarded-client-cert: By=http://frontend.lyft.com;Hash=468ed33be74eee6556d90c0149c1309e9ba61d6425303443c0748a02dd8de688;Subject="/C=US/ST=CA/L=San Francisco/OU=Lyft/CN=Test Client";URI=http://testclient.lyft.com;DNS=lyft.com;DNS=www.lyft.com The downstream app would have to parse the header value to get Test Client

What i'm looking for is more something along the line of X-REMOTE-USER: Test Client

[htuch]

Yeah, it doesn't seem unreasonable to add this to https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#config-http-conn-man-headers-custom-request-headers.

What I would be interested is if we could make custom request headers expressive enough to replace XFCC. That would be a good litmus test of a design for this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or other activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted". Thank you for your contributions.

[holgero]

Would adding a custom request header help here? Something like:

route:
  cluster: www
  request_headers_to_add:
    - header:
        key: "x-remote-user"
        value: "%DOWNSTREAM_PEER_SUBJECT%"

It would be at least a bit less complex than the XFCC header, but maybe the complete subject is still too much.

[holgero]

I will try to solve this with a lua filter (to read the value of the XFCC header and set x-remote-user from the parsed values in the subject) for now. Do you think that might make sense? Or is something else already under way?

[roboll]

(@nyodas and I work together)

For our use case we'd need only one field from the subject. having the whole subject can't work. (We don't control the behavior of the downstream app so can't change it.)