Proxmox Datacenter Manager 1.0 (stable)

[IsThisThingOn]

Sorry, I am a total noob when it comes to REST API. Does that mean that:
A: Is the connection always and mandatory secured with HTTPS, just like with PBS?
B: you recommend a VPN instead exposing the host, since it is best practice?
C: Does the REST API have a "brute force protection" by using a SHA256 key, instead of username + password?

Because then I found the easiest way for me to (just like with PBS) simply create a Firewall rule that looks like this, instead of using a VPN:
Allow all incoming TCP on all ports, from STATIC_IPV6_REMOTE to STATIC_IPV6_LOCAL.

 

[sterzy]

A: Is the connection always and mandatory secured with HTTPS, just like with PBS?

Yes, all remotes are only connected to via HTTPS.

B: you recommend a VPN instead exposing the host, since it is best practice?

This depends on your setup. If everything is local in your network, a VPN may not be necessary. If you split your infrastructure across several networks, and it is not possible for PDM to connect to all remotes, then yes using a VPN or similar to allow direct connections from PDM to its remotes is recommended.

C: Does the REST API have a "brute force protection" by using a SHA256 key, instead of username + password?

There are numerous protections in-place. However, you should not rely on any single measure, but rather try to pursue a “defense in-depth” approach. I am not sure what exactly SHA256 is supposed to protect in this scenario. However, in terms of brute force protection when it comes to authentication I am aware of the following measures:

- When authentication fails, the API adds an intentional 3s delay to all requests. This should prohibit fast retries.
- Passwords are stored and verified with yescrypt. Yescrypt uses a work and space factor as well as salts. This should limit various attacks on passwords, such as rainbow tables. It is also hard for an attacker to get access to the actual password from the generated hash. The work and space factors also make it harder to compute hashes fast, preventing brute force attacks to some degree.

 

[IsThisThingOn]

Sounds great, thanks a lot for the explanation

 

[p-user]

I found a tiny error, nothing major by all means. I have two pve nodes, pve1 and pve2 and they both show up under clustername pve. When I go to the cluster then when I want to view the data per node it shows up fine, as far as I can see, but not for the "Notes" tab, that one shows the same "Note" for both nodes. I believe that's an error. Although very minor. FYI, I am using the latest pdm version available.

 

[winterwonderland]

Hello!

I just updated Beta to 1.0.2 mainly to check out the new OpenID Realm authentication option.

That worked fine, I can now log in using our SSO account instead of being root@pam. But...

When logged in with the new user, I see 0 configured remotes? Root still sees all three remotes just fine.

It is really diminishing the value of per-user logins if everyone needs to set up their own tokens and accesses to clusters.

There is only one remotes.cfg so it makes much more sense to have the remotes configuration product-wide instead of per-user.

Having this per-user also introduces funny licensing questions. Say the root user is <80% for seeing all clusters (including test ones); but I can create a personal login seeing only the Standard clusters. Then I can not receive enterprise updates but simultaneously can receive enterprise updates for the system, depending on who I log in as? Schrödinger's licensing?

 

[sterzy]

When logged in with the new user, I see 0 configured remotes? Root still sees all three remotes just fine.

I think you are misunderstanding something here. The remote configurations are not per user. You probably just haven't given your new user any permissions, so it does not see existing remotes. Simply configure appropriate permissions for the OpenID user in the Access Control menu.

 

[winterwonderland]

I think you are misunderstanding something here. The remote configurations are not per user. You probably just haven't given your new user any permissions, so it does not see existing remotes. Simply configure appropriate permissions for the OpenID user in the Access Control menu.

Indeed, that was me being stupid

All is well now, but raises the next point: PVE has group management with OIDC; on PDM you can only manage permissions for individual users. Feature parity with PVE would be nice here.

 

[sterzy]

All is well now, but raises the next point: PVE has group management with OIDC; on PDM you can only manage permissions for individual users. Feature parity with PVE would be nice here.

Yes there is already an open bug to track implementing groups for PDM [1]. The context there is LDAP/AD realms, but of course OpenID realms would be part of that too once we implement it.

[1]: https://bugzilla.proxmox.com/show_bug.cgi?id=6883

 

[winterwonderland]

Great to hear! Another (minor) thing would be to get certificates via ACME from sources other than LetsEncrypt, as already supported in PVE.

 

[crystianluis]

We will start the tests today! Great Work!

 

[Leonid Kanareykin]

Nice start!
1. Why don't you count quantity of remotes, i want to now how many clusters i have, i want create Dashboard for all DCs and see number of cluster as i see number of nodes
2. We all need storage tab with name, size, IO, latency, and other performance statistic, and also dashboard regarding most utilized storage space and maybe IO
3. Maybe you can add orphaned VMs and unused disks report
4. Also needed view Host network throughput and usage and dashboard with Highest host network load

 

[Howard A2 Labs]

Having the majority of server non-prod is certainly not a common use case.

Just wanted to reply to this specifically and I have a suggestion. The reason it seems we have more non-prod is that the non-prod nodes with community subscriptions are a pile of teeny quad-core single socket boxes. The prod servers are relatively monstrous 2U 2-socket machines and run orders of magnitude more VMs at any given time.

Would it be possible for you to have PDM calculate its subscription status by % of subscribed sockets rather than by subscribed nodes?

 

[ghandalf]

Just wanted to reply to this specifically and I have a suggestion. The reason it seems we have more non-prod is that the non-prod nodes with community subscriptions are a pile of teeny quad-core single socket boxes. The prod servers are relatively monstrous 2U 2-socket machines and run orders of magnitude more VMs at any given time.

Would it be possible for you to have PDM calculate its subscription status by % of subscribed sockets rather than by subscribed nodes?

Hi,
I would even say, it should be calculated by subscribed cores.

For example on my side:

• Standard subscription: 6 nodes a 32 physical cores -> 192 cores
• Community subscriptions: 3 nodes a 12 physical cores -> 36 cores

From my calculations, this would be 84 % instead of only 66 %

 

[Howard A2 Labs]

Hi,
I would even say, it should be calculated by subscribed cores.

For example on my side:

• Standard subscription: 6 nodes a 32 physical cores -> 192 cores
• Community subscriptions: 3 nodes a 12 physical cores -> 36 cores

From my calculations, this would be 84 % instead of only 66 %

That would be help the math there, however we subscribe to PVE per socket rather than per core and I hope that does not change.

I just think it would fair to make nodes count by socket since we've bought PVE by socket.