[Request] Ability to run the management-api on a different port than the public api

[berkes]

Description

We would love an option to set the port of these "management api" different from those of the public api.
So that we can protect our management API endpoints in a more flexible way than an nginx proxy.

Currently the way to protect the management API's is by configuring a proxy so that it requires authentication for /v0/* and no authentication for everything else.

Motivation

The API documentation¹ mentions the following:

Authentication & Authorization

UniCore has no user management or authentication built in by default. The API does not check for any roles or scopes. Currently, it is expected that the application which calls UniCore only performs calls which have been checked in the consumer business logic. If you want to make your UniCore deployment reachable via the internet, you MUST restrict direct access to the API by running it behind a reverse proxy or some form of API gateway and check for an API key or similar. In most cases, only the endpoints behind /v0 need to be protected and all other non-sensitive endpoints can stay publicly accessible in order for other participants (such as wallets) to interact with UniCore.
Example reverse proxy configuration

Here is an example Nginx configuration that restricts access to the /v0 endpoints by checking for a valid API key in the headers:
...

However, in context of k8s, swarm etc, such authentication is much easier and far securer to implement if the service provides these endpoints on e.g. different ports. Or even in separate pods.

That way, we can (either/or/and)

• create separate servers or pods that read/write the same event-store for the public part and for the management part. Allowing for flexibility in scaling. Each pod would simply expose only the relevant port.
• expose the management part in a VPN, or otherwise protected network only and the public part on the web. E.g. issuer.internal and issuer.example.com
• bind different urls to the different apis. E.g. management.issuer.example.com and issuer.example.com.

Putting an nginx proxy in front is a quick way, but falls apart in context of k9s, WAF, or other more "production grade" infra very fast. It also makes scaling and fallback quite hard.

Obviously many WAF and ACL solutions such as kong, traefik, AWS WAF do have some access protection based on url patterns in place. But doing so on port is often easier and securer.

I think it's a good idea to keep the defaults so that both the management and public port are the same if not set explicitly. And therefore to keep the url prefixes (/v0) in place as well.

¹ Should maybe be part of the Deployment section of the documentation, instead of the swagger/openapi docs?

Requirements

1. A config option and ENV var to set the port of the management-api endpoints different from that of the public api.
2. Default to the same port, so that by default everything remains working as it does now
3. Regardless of the port settings, management api endpoints should probably always route to /v0/{thing} urls as they do now.
4. preferably the service listens on both ports as it does now with metrics endpoint as well.

Open Questions

Must a single running service listen on both ports, or only one?

In other words: can a single service instance handle both managment-api and public api, or can it handle only one of these ever?
The metrics endpoint, listening on 9090 makes it seem like it should be possible, but maybe that's a different instance/process, idk.

Are you planning to contribute this in a PR?

Yes