Why Is Istiod Accessed Using a Proxy?

[6174495]

at lines 345-354 in kubernetes/istio.go

func (in *K8SClient) GetPodProxy(namespace, name, path string) ([]byte, error) {
return in.k8s.CoreV1().RESTClient().Get().
Timeout(httputil.DefaultTimeout).
Namespace(namespace).
Resource("pods").
SubResource("proxy").
Name(name).
Suffix(path).
DoRaw(in.ctx)
}

Why does Kiali access Istiod services through the proxy of the APIServer instead of directly accessing Istiod services?
Example of directly accessing the istiod service：

resp, err := http.Get("http://[istiod-address]/path")
if err != nil {
return err
}

[lucasponce]

Hi @6174495 (happy if you can put a name we can refer to :) ),

Kiali provides two features related to check the status of the Control Plane and Data Plane in Istio.

The plane is related to the status of the sidecars/proxies deployed into the workloads that belongs to the Mesh.

One fundamental check is to inform the user if a proxy is synced with the control plane, that's the purpose of that query, to implement a similar https://istio.io/latest/docs/reference/commands/istioctl/#istioctl-proxy-status command but within Kiali.

At least there was not an api to query the same information fetched in that query (talking about Istio 1.9, if Istio 1.10 has updated this endpoint probably this logic can be upgraded).

[6174495]

I mean, why do I need to access Istiod through the APIServer? Why can't Istiod services be directly accessed?

[lucasponce]

I guess you mean that instead to query using the proxy subresource through the pods

func (in *K8SClient) GetPodProxy(namespace, name, path string) ([]byte, error) {
	return in.k8s.CoreV1().RESTClient().Get().
		Timeout(httputil.DefaultTimeout).
		Namespace(namespace).
		Resource("pods").
		SubResource("proxy").
		Name(name).
		Suffix(path).
		DoRaw(in.ctx)
}

it can be changed to query directly the "istiod" service.

Is that what you suggest ?

I guess yes, if the endpoints are available that would work, too.

[6174495]

Yes, that's what I meant, and thank you very much for your reply.

[lucasponce]

Now I'm working on that code I remember one of the motivations to not call directly the istiod service but using the proxy: in some clusters the service/port was not available per security reasons, so we decided to use the proxy to put that query under the RBAC constraints and also help on those scenarios.
Note that this data is also cached.

[xeviknal]

There is one key reason to not consume the istiod at service level: precision and lack of information.
There is the scenario where there are multiple istiod pods behind one service. Each pod has different synchronization information because each istiod splits the work to control a unique set of workloads. So if you consume the service, you'll only receive the list of sync info of the istiod which respond the request, AFAIU.

Therefore, the alternative way of using the Kube API for sending requests is to use the IP associated to the pod. I have recently discovered that one pod can has network visibility to pod's local IPs. When developing the feature, I didn't thought of that option, tbh.

Approaching this consuming each pod's local IP (instead of the pods/proxy sub-resource) would definitely prevent users to open ports from kubeAPI to the control plane (which sounds a bit more secure)[1].

One extra win of using IP's would be that it'd cover the scenarios where istiod is outside of the cluster (no supported at all right now, afaik).

As a result, this whole step 1 could be converted into an issue to consume pod's IPs and remove the requirement to open port 8080 from kube API to the control plane(s).

[1] https://kiali.io/documentation/latest/faq/#google-cloud-private-cluster