Collecting attribute instances from istio-ingressgateway on incoming requests

Policies and Telemetry
1

I’m collecting attribute instances coming in to mixer from proxies around the mesh, and I’ve noticed that while istio-ingressgateway is sending data for outgoing requests, it’s sending nothing for requests that are coming into it from outside of the cluster. I understand that istio-ingressgateway is essentially an istio-proxy container running certain configuration and it would be pretty weird to try and inject another istio-proxy sidecar into it like it’s done with regular pods (I’ve tried by the way, and it didn’t immediately work). Is there a better way to achieve what I’m looking for? Is there a guidance as to how to configure istio-ingressgateway to send attribute bags to mixer on incoming requests, not just on outgoing ones?

2

Hi,
Is there something specific you are looking for inbound requests? We normally treat ingress gateways as client-side proxies, and there’s just one set of attributes generated by gateways. The source is the gateway, the origin is the external IP, and the destination is the internal mesh service. It might help to think of gateways as “sidecars for all the rest of the internet”. The server-side gateway attribute bag would be mostly identical to what is already generated by the gateways, and we would prefer to avoid multiple policy checks/telemetry on this path.

3

I’m trying to get information about the external caller. When you say “the origin is the external IP”, which attribute(s) are you referring to? I do indeed see that the source is the gateway and the destination is the internal mesh service; if I could somehow get to the IP of the external caller through that “origin” you’re mentioning - I think I’m fine.

4

There is origin.ip attribute, which should be the external IP in ingressgateway case. However, it does require k8s to be configured to use local external traffic policy (see https://github.com/istio/istio/issues/7328). Basically, another load balancer in front of envoy (e.g. kube-proxy) could obscure the IP address.

Alternatively, you can try request.headers[“x-forwarded-for”] which should be a list of proxy IPs.

5

I’m not seeing origin.ip in the attribute vocabulary, am I looking in the wrong place?

6

Ah, sorry this is missing documentation.
We definitely produce this attribute. I double checked the integration test and proxy code.
I’ll follow up with a doc update.

1 Like