in the documentation it is explained that your services have to resend a set of headers to enable pilot/Zipkin to correlate the information.
But who generates the first headers and set its values? The Istio Ingress controller?
How can I configure it, enable/disable it?
Thank you.
The Istio sidecar proxy (Envoy) generates the first headers. According to https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#x-request-id:
Envoy will generate an x-request-id header for all external origin requests (the header is sanitized). It will also generate an x-request-id header for internal requests that do not already have one.
Related
When a request is denied the reply back is:
HTTP 403
RBAC: access denied
Is there any way of customising this error to have a different status code and reply body?
It is currently not possible with Istio API, however there is a feature request for that on Github.
There is also a workaround using an envoy filter to customize that response.
Note, however, that Envoy filters are low-level constructs compared to Istio API and Istio doc says:
This feature must be used with care, as incorrect configurations could potentially destabilize the entire mesh.
So, I need to set DSCP byte for HTTP/2 traffic on client side, which is an IP header. This is easily done using setsockopt IP_TOS on the socket sending the HTTP POST request.
But, we are using istio in our project, hence all traffic goes through envoy proxy, and I verified that the envoy proxy is stripping away all IP headers when proxying.
Ie, client sends http post to envoy with DSCP set -> envoy sends HTTP post to the actual recipient, but all IP headers set by setsockopt is gone.
Looking at envoy documentation, it seems that the solution is to use a 'tcp filter', and envoy already has a selection of filters inbuilt: https://github.com/envoyproxy/envoy/tree/main/source/extensions/transport_sockets
But, sadly, the documentation is quite cryptic. But this must be a common requirement, so does anyone know how to get envoy to preserve IP headers set by setsockopt?
Thank you for any advice!
I think you can try config CLUSTER’s upstream_bind_config by using istio envoyfilter API, the related doc are here. I did not try it, but seems it is what you need.
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto.html?highlight=bindconfig
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/address.proto#envoy-v3-api-msg-config-core-v3-bindconfig
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/socket_option.proto#envoy-v3-api-msg-config-core-v3-socketoption
In my integration scenario I need to veryfy some data of TLS certificate.
Is there a way to get details of TLS certificate (eg. subject name) in sequence?
No, you can do that in wso2. In any of wso2 scopes (Axis2/Axis2-Client/Transport/Operation/Synapse), you don't have access / information to used TLS certificate in request.
Some workaround, could be use reverse proxy, for example HAProxy to add information in request header, like described here: SSL Client Certificate Information in HTTP Headers and read in sequence from header. In nginix I belive that is also possible.
Last way, I think, is to modify source code, or implement own TransportReceiver for https requests.
our istio ingressgateway is only reachable via an authenticating reverse proxy. That proxy adds headers for the authenticated user (but no JWT).
Is it possible to configure istio to use this header for the origin identity?
If I understand istio correctly, what I'm looking for is setting the request.auth.user field in a filter(?) to a header value from the incoming request. Basically the opposite of this: https://discuss.istio.io/t/question-decode-jwt-and-put-sub-into-a-request-header/1213
So I had a working mTLS service mesh until one of the services got updated with some header manipulation logic. This logic was getting the headers from the request the service got, and then adding those headers to the request this service was making to another one.
With this logic in place, mTLS was broken between this service and the next one, and if I activate PERMISSIVE mode, connection works as usual.
So then I went to this service’s container and did a curl request to the next service but without the Host Header and the request came through.
So, same request, just that without Host header mtls works, and with host header it doesn’t.
I would like to know the reason why this happens. Is it related with mTLS and how both services are trusting each other?
Thanks
I think that the best way to approach this issue would be to analyze the differences between services' versions before and after the header manipulation logic.
In order to dump headers' request you can use the helper httbin server from Istio official doc here.
You can find more info regarding how to use it here.
Please let me know if that helped.