John Howard

The virtual service part could probably be improved fairly easily with a PR. But I bet if you split it manually like: ```yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: cnn-https...

I don't think we should do this. Running as hostNetwork is not safe and I don't support encouraging it. You can do this on your own if you want --...

You are free to set any field you want in the Kubernetes API with almost any install or CI/CD tool (https://istio.io/latest/docs/setup/additional-setup/customize-installation-helm/ etc).

hostNetwork is an operational and security risk. I don't know the motivation behind other projects adopting it, but to me personally I don't want to in any way encourage users...

If you must run on an effectively broken Kubernetes distribution, I would put the webhook behind a load balancer that is accessible to the control plane before resorting to hostNetwork....

https://istio.io/latest/docs/setup/additional-setup/customize-installation-helm/ (or many other approaches) can modify a chart, without forking. > appears redundant and more cumbersome to maintain. It is. A `hostNetwork` is a security and operational risk. Given...

Deleting a secret is ignored by Envoy. I would say that is "working as intended" but maybe that is too strong.... its at least "working as _implemented_"

> Should a ticket towards Envoy be created for this issue? No, its intended behavior from Envoy and its fixable in Istio with a code change if we need to

The issue I am concerned with is the difference between "Secret was removed" vs "Secret never existed" vs "Caller doesn't have permission to access the secret". How we distinguish those...

Its not clear to me how that would solve this problem. Secrets are already kind of "delta" even with SotW