reproing a repro of an old istio vulnerability

tl;dr - see my repro repo here.

I recently got nerd-sniped by a blog post that explored an old istio vulnerability. The vulnerability meant that istio users whose access to Kubernetes secrets was restricted by RBAC policies could circumvent those policies in order to access kubernetes secrets in any namespace that istio had access to (which is all of them by default).

I remember when this bugfix shipped and I didn't think much of it at the time. I got confused trying to follow the steps and then realized there were some key bits of information missing. To be fair to the author, as someone who teaches people to use istio for a living I appreciate how hard it is to explain this stuff. This is not intended as a critique of the author but an addition to the conversation.

The repro environment involves deploying istio with two custom ingress gateways into separate namespaces called ns-a and ns-b. The author advises readers to do this by the use of two different customized installation profiles however in the browsers I tried the YAML rendering in the blog post seemed mangled somehow which made it hard to read. It is unnecessary to use two separate profiles to achieve the desired configuration of a gateway in each namespace so I merged them into a single profile.

Also the provided installation profile installs istio without any of the CRD's or the istiod controller which provides the gateway injection webhook functionality. As it is impossible to reproduce this issue as described without both of those things, my modified profile installs them as well.

The subsequent steps outlined in the post involve modifying and apply more of those hard to read manifests. This was a bit fiddly so I have checked-in formatted versions in here.

After applying these manifests the cluster will have a toy workload (I used nginx) in each namespace, a virtualservice in each namespace to route traffic to the toy workload, and a gateway configuration in each namespace to terminate TLS. TLS termination is performed using a self-signed certificate and key found in a kubernetes secret called foo-dot-com. Crucially however, the secret only exists in the ns-a namespace.

If the istio version being tested is vulnerable to the security issue, then it will be possible to connect to the gateway in namespace ns-b using TLS, despite the fact that the secret necessary for terminating TLS is not there.

If the istio version being tested is not vulnerable, then it will not be possible and the gateway will reset the connection. I have included a test script to validate this.