Closed ronsonx closed 11 months ago
@ronsonx Can you please provide more details as to what exactly you are trying to accomplish here? When you say that the header is being discarded by Apigee, do you mean that it is not visible as part of the debug information on Apigee or the request flow information?
Is your goal to get the certificate information as part of the headers?
@g-greatdevaks I found that the x-forwarded-client-cert populated by Envoy does not appear in trace nor is available for variable reassignment (request.header.x-forwarded-client-cert
) in Apigee.
I attempted to resolve this issue by setting it to x-apigee.tls.client.raw.cert
from Envoy to match with the Hybrid default. However, this too did not appear in the trace or become available for further processing.
I am assuming that Apigee is dropping these headers as part of some sanitization logic. As a solution, I set a custom header x-raw-client-cert
. Please let me know if you have any questions or concerns about this issue.
Thanks for the suggestion @ronsonx! We have discussed this internally and decided that we don't want to change the behavior of the default implementation as this could lead to unintended consequences e.g. sending the client cert down to the backend service.
I'm inclined to adding this as a note to the mTLS solution's Readme file to let others know of the workaround.
What's changed, or what was fixed?
Fixed forwarding of client certificate in case of mTLS: Envoy can populate x-forwarded-client-cert header. But this header was being discarded by Apigee. So, assigned the value of
%DOWNSTREAM_PEER_CERT%
command operator to a custom header namedx-raw-client-cert
in the envoy config.