I’m looking to handle authN through the Service Mesh. I need to be aware of the identity of specific containers, but because of the nature of these containers, I need to not rely on the service within to self-identify. What I’m hoping is that perhaps Consul can somehow pass on mTLS identity to the service these containers are connecting to? Fwiw, my stack also includes Nomad and Vault.
Hi @khionu,
Someone recently replied to this existing thread (Configuring envoy to forward mTLS identity to workload as http header) with an example Consul escape hatch configuration that enables Envoy to forward mTLS identity to a downstream application via the XFCC HTTP header.
We are interested in exposing this XFCC config as a first-class configuration item in Consul. Feel free to file an issue on Consul’s GitHub repo so that we can track this feature request.
Thanks.
That is very nice for HTTP, but I’m not using HTTP for all my containers. I could as a temporary solution, but I’m looking to use other protocols, namely capnproto over quic. I understand there isn’t a place like HTTP headers to easily insert that data, but maybe there could be opt-in packet framing? I’m not fussed on the how, it just seems like an oversight that identification can’t be done via the mesh
I suspect this will require changes to be made in Envoy in order to support attaching mTLS identity information to non-HTTP connections. I recommend filing an issue in https://github.com/envoyproxy/envoy/ to discuss this further with the Envoy maintainers.