Can I ditch PVEPROXY? I guess not...

[Deleted member 205422]

not sure, not too familiar with the bug, but if you wrote an new answer with new information, we usually respond (but maybe not instantly )

I am not sure either

Cf. https://bugzilla.proxmox.com/show_bug.cgi?id=4252

 

[wbk]

Hi Esiy,

Would it be an option to set up a custom GUI in front of a firewall or proxy, that would just expose the functionality needed by you and forwards it to the API on port 8006 behind the firewall? With the Proxmox IP's on a separate management plane, accessible via the proxy, it should close not only the GUI, but also the unneeded API surface.

- edit -

as a single control pane

... so to speak ;-)

 

[Deleted member 205422]

Hi Esiy,

Would it be an option to set up a custom GUI in front of a firewall or proxy, that would just expose the functionality needed by you and forwards it to the API on port 8006 behind the firewall? With the Proxmox IP's on a separate management plane, accessible via the proxy, it should close not only the GUI, but also the unneeded API surface.

- edit -

... so to speak ;-)

Thanks for chipping in, but it's a misquote to begin with. When I mentioned the "a single control pane" I was getting at the fact (unaware of the actual reality) that perhaps PVE started without clusters support and at that time the single (as in only, not as in unified) GUI on the host made perfect sense, then came the idea to make it "accessible anywhere" equally and thus need to have it JS shooting at the API and proxying requests if need be.

On your suggestion, I am aware of what everything can be filtered or proxied etc and indeed I was about to be putting sort of "custom GUI" calling the API shots there, but basically my whine (if you will) was about being uncomfortable how the API proxy is being mixed in with pieces of code catering for browser specifics.

The fact that we would shield it behind own "proxy" would not for instance change the fact that PVE's management plane, if I am not wrong again relies on the e.g. LISTENIP of the very pveproxy codebase (which I would be frantically auditing with every new release if it's this architecture) and I was already dismayed at how the user management does not allow to restrict them from certain br interfaces. Am I wrong on this last one?

 

[wbk]

, but it's a misquote to begin with...

... on purpose ;-) That's what you could start, a PVE-managermanager. Just a single control plane, to expose certain features, and so on

my [worry] was about being uncomfortable how the API proxy is being mixed in with pieces of code catering for browser specifics.

I did not delve all too deep into the specifics, let alone the code, so I'm easy to convince ;-) If there's an API proxy that has browser specifics, does it exclude the API being clean?

 

[Deleted member 205422]

I did not delve all too deep into the specifics, let alone the code, so I'm easy to convince ;-) If there's an API proxy that has browser specifics, does it exclude the API being clean?

Hey @wbk, sorry for late reaction, I did intend to reply, even with specifics, but as I was also basically told to take it to the Bugzilla, I won't abuse the forum with my opinions what's safe or unsafe way of CSFR prevention on REST APIs. Obviously I had an issue with that, forum apparently is not the appropriate junction. Not that I feel like I would be censored, but it's also wasted efforts at the point at which it reaches a forum if those design decisions were taken 10 years ago.