Use sub-paths instead of sub-domains for the EOEPCA building blocks ingresses

[spinto]

I was just advised that ESA is discouraging the use of wildcard DNSes and wildcard certificates. For internal ESA services, wildcard certificates will not be provided anymore, as these increase the "attach surface" and make in general our applications less secure in the face of the growing treats.

Based on this, it would be a good advise to limit the use of DNS domains in EOEPCA, and for sure not use dynamically provisioned domains. This will also reduce the dependency on cert-manager and Let's encrypt, which is an issue on some deployments.

I believe it would be good then if in EOEPCA we strive to support this shift, and try to use as more as possible sub-paths instead of sub-domains as the default deployment of the EOEPCA building blocks. So have eoepca.local/zoo instead of zoo.eoepca.local , etc...

I have already tested some of the EOEPCA applications, like Zoo, pyCSW, eoAPI, STAC Browser, etc... and they both work with relative paths or a allow a prefix to be configured, so deploying them with sub-paths should be just a simple configuration change in the ingress (and in the app configuration, if prefix is needed to be set).

For other applications, if the do not support the deployment as sub-path, we should at least strive to include this support in the next WO.

We can discuss this in the next EOEPCA technical meetings also, if you think that could help clarify the vision.

[rconway]

During phase 1, we did start to follow this path. I recall that pycsw and maybe zoo addressed the path prefix approach.
One option is to place a roadmap item on each BB to ensure they support the use of path prefix for ingress.