admin UI app on different port?

[mattpr]

Couldn't find this searching or under #246. Not sure if it is already asked/answered.

It appears that currently vaultwarden serves everything on a single port (customizable via ROCKET_PORT env).

It would be quite nice if the "admin" functions (API or otherwise) were able to be split off into a second server instance running on a different port (e.g. via ADMIN_PORT env).

Example scenario...

• running in non-container mode
• nginx providing SSL termination
• don't want to expose admin features through firewall (e.g. access via tunnel to localhost only)
• don't want to have to resort to path matching rules in nginx (e.g. special cases for /admin) and would rather just rely on port-based firewall rules.

Maybe this doesn't make sense because the admin APIs are part of standard bitwarden protocol stuff that a client might use. But normally I prefer to put as little as necessary on public ports, so would be nice if there was a way to partition "normal bitwarden protocol" APIs from admin functions at a port/firewall level.

It might be a little clunky, but you could make launching admin stuff (UI+APIs) on different rocket server/port contingent on that new ENV/config being set (ADMIN_PORT) which would allow this to be a non-breaking change.

[mattpr]

After a few minutes playing around with bitwarden, I see the web-vault UI also has a fair bit of admin stuff as well.

I know I can disable web vault. I know I can also use custom reverse-proxy rules to try and do filtering at the application level for any traffic coming through the reverse proxy. This requires that I know details about exactly which paths/routes are used by various features and that I keep abreast of any changes and new features that might be located on new paths. So it would be nice to be able to easily partition the UI/admin stuff by (optionally) running it on a different port so firewall rules can be used to expose UIs to say VPN interfaces but not public.

In an ideal world I would have "bitwarden protocol", "UI-users (no admin function)" and "UI-admin" all optionally separable via different servers/ports. I know I can turn off web-vault and admin UI..but maybe I just want them accessible to me via VPN interface rather than running on the public port.

Of course I could just put EVERYTHING behind the VPN (bitwarden clients won't be able to connect to vaultwarden unless they are on VPN), but that might be too heavy handed for my users...and I am not sure if it breaks things that depend on connectivity with bitwarden's own APIs.

[BlackDex]

The admin interface is rather simpel, just do not allow access to /admin, and maybe some resources it uses.

The web-vault admin is rather difficult I think, and personally i wouldn't even try to do that.

But if you really want and don't mind being logged out or getting strange errors. I would suggest to look at the code for everything which has AdminHeaders or OwnerHeaders, and block those endpoints.

An example:

vaultwarden/src/api/core/organizations.rs

Line 284 in ad8484a

headers: OwnerHeaders,

But, that does mean, if something changes, like an endpoint needs to allow managers or users in the future, or only allow owners while it first was also for managers, you have to watch and adjust your security.

[mattpr]

The admin interface is rather simpel, just do not allow access to /admin, and maybe some resources it uses.

Yeah this requires relying on reverse proxy to filter certain paths. I'm aware but would prefer to just not have those services available on that http port....but I would like to be able to access that UI still (e.g. via tunnel/VPN).

The web-vault admin is rather difficult I think, and personally i wouldn't even try to do that.

Yeah I understand that the user web-vault and admin user features are mixed together. While splitting them would be nice, I understand it is not practical at this point.

So here it would be same as the admin ui...ability to run the web vault but on a different port (ie like with the /admin interface). Then it is all or nothing. web-vault is either available on public port via reverse proxy or it isn't (only accessible via tunnel). Simple firewall rules control access.

I envision something like additional (optional) environment...

• ROCKET_PORT_ADMIN - if set, create additional rocket server on this port and mount the admin routes to it. If not set, mount the admin routes on the default rocket server. (contingent of course on ADMIN_TOKEN enabling admin UI).
• ROCKET_PORT_WEBVAULT - same thing. if set, create additional rocket server on this port and mount the web-vault routes to it. If not set, mount the web-vault routes on the default rocket server (contingent on web vault being enabled).

So if these new env are not set, there is no (breaking) behaviour change. If these are set, there are additional rocket servers created and these services (admin and web vault) are mounted on those other servers so that functionality is partitioned (bitwarden API vs webvault UI vs admin UI)...makes it much easier to manage with firewall.

[BlackDex]

That isn't really possible in an easy way.
We would have to split all the code into specifically admin or client and run two different rocket servers and that will make it only more complex.

Then we also have an issue with if people want to keep it running on one port, we then need to some how either proxy everything internally, or make it flexible enough that if both ports are set the same, we not run in split mode.

In my eye's that is just too much hassle, and too much which can go wrong.

The ROCKET_ADDR, ROCKET_PORT are btw not env's handled by Vaultwarden it self, but by the rocket crate.
You can simply block /admin via a reverse proxy and only allow it from certain IP's or only with authentication via either Basic Auth, or Authelia or something similar.

The client endpoint is much harder to filter, since all is handled by the client's it self. The Web-Vault only sends the main uri for the login, and all specific admin or organization web-vault endpoints are never sent to the server, only the underlying API Endpoint calls.