Wildcard egress: remove arbitrary domain section

[howardjohn]

This doc has been a nuisance for many years. It recommends an extremely
complex and dangerous pattern, relying on deploying nginx, extremely
complex EnvoyFilters enabling unsupported, custom, alpha Envoy c++
filters, and a number of other scary practices. IMO this does not belong
in Istio docs at all, and certainly not in our top level taks.

Please provide a description for what this PR is for.

And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.

• Configuration Infrastructure
• Docs
• Installation
• Networking
• Performance and Scalability
• Policies and Telemetry
• Security
• Test and Release
• User Experience
• Developer Infrastructure

[frankbu]

I think we should either remove this whole document, or if not, update the earlier material in the doc based on the second section being removed. For example, earlier in the doc it says: The first, and simplest, way to access a set of hosts within a common domain ..., so that needs to be reworded given that there is only the "first way" in the doc. It should probably, at a minimum, explain the limitation of the config used in the task, and allude to what would need to be done in the general case, even if it doesn't include an example config in the task.

[frankbu]

Does this section need to be deleted too? Seems that it's really only the next section that uses the nginx proxy and is the overly complex config that we don't want to recommend.

[howardjohn]

Good call, added it back

[craigbox]

/cherrypick release-1.14

[istio-testing]

In response to a cherrypick label: new pull request created: #11381

[joshperry]

I have no qualms with the "shouldn't be in our main tasks" change, but it seems kind of wrong to just delete this information from existence... I'm at this PR because I remember reading this method when we first deployed istio about a year back and had to look at the docs repo commit history to figure out why it disappeared.

Does it make sense to bring this back somewhere, or to maybe get some heads together to modernize the methodology? Not being able to handle wildcard TLS origination makes using these gateways for eastern egress really quite painful.

Often a complex solution that works is a good starting point to improve; we're already building a custom proxy with two custom C++ filters to shift TLS origination for NATS and postgres into the sidecar, so this seems fairly straightforward from my perspective.

[psandhu79]

So there is no alternative apart from putting in all host entries, we have setup an egress gateway to funnel requests from our sidecars. We have setup a ext auth policy on the egress gateway to add a token to the request before it makes the request. However we do not know all the hosts only ..petclinic.com, so what is your recommendation here.

[howardjohn]

Alternatives can go in blogs, github wikis, etc. IMO there is a bar for making it into istio.io. In the current state we have had many many issues with this doc over the years since folks expect things in istio.io to be production ready/good ideas -- this doc is not.

The general concept of wildcard egress is useful certainly - but not with this implementation, and there are no current alternatives.