ProxmoxVE and the shared root account for update/upgrades.

J

_--James--_

Member
May 17, 2023
78
44
23
First off, there is already a Bugzilla tracking this issue dating back to 2018: https://bugzilla.proxmox.com/show_bug.cgi?id=1856

Proxmox has grown significantly in enterprise adoption since then. It's time to bring this issue to resolution.

The continued requirement to use the shared root@pam account for host administration is incompatible with many enterprise compliance frameworks and security policies. This is no longer a feature request for convenience. It is an enterprise adoption blocker.
 
Last edited:
  • Like
Reactions: LnxBil and SteveITS
There is also an answer and review of @gyptazy patch by @t.lamprecht which basically mirrors the reasoning from tge ticket against providing such a feature due to security concerns. Personally I have no fixed opinion ( imho needing to use a tool like ansible to automate upgrades is fine but I can see that this might not cut it in complex and/or heavily regulated environments) but the developers propably won't change their mind until enough subscribers chine in in favour of such a feature.
 
  • Like
Reactions: gyptazy
Hey there,

as @LnxBil and @Johannes S already mentioned, there's a patch which I created some times ago. However, it got rejected for "security" reasons (as in security of operators running upgrades). I'm not fully with this opinion as operators might also not fully judge a presented package list and their potential impacts. However, we should keep in mind that this affects only minor updates (major ones are out of scope). When running large scaled clusters, most ones switch to automated patch management solutions or automation tools like Ansible which basically perform the same commands as the patch does.

In the past, I repackaged this patch for the API as a Debian package which allowed a quick integration but I'm not maintaining this anymore as other solutions took place. Most known ones are probably PegaProx and ProxPatch. By different solutions, invoking this via sudo users is also possible to make sure those things won't be executed by the root user.
 
  • Like
Reactions: Johannes S
I think the main issue with adding such a feature to the API would be that anybody who can do system upgrades basically gets "root" powers. So if your compilance requirements are that you need to limit the potential breakage done by a single person you are lost at that point anyhow: If the person is somebody with the (fictional) api permission systemupdate they can also do everything possible with root.
If however your compilance requirement is also that a natural person should never have root powers, this requirements can't be fulfilled due to being contradictory. Now I'm aware that conflicting requirements have never stopped managers from insisting that they be met in full. So in the end it boils down whether you agree with the technical argument or whether on a practical level you are fine with enabling such a thing in the API and advising admins to get their "We accept the risc" stampf of approval from their compilance/checkboxes theater managers.

For large environments dedicated tools like ansible, proxpatch together with proxmox-offline-mirror or some other patch management tool (like pul/foreman etc) etc are the better path anyhow
 
Last edited:
  • Like
Reactions: bl1mp
gyptazy said:
Hey there,

as @LnxBil and @Johannes S already mentioned, there's a patch which I created some times ago. However, it got rejected for "security" reasons (as in security of operators running upgrades). I'm not fully with this opinion as operators might also not fully judge a presented package list and their potential impacts. However, we should keep in mind that this affects only minor updates (major ones are out of scope). When running large scaled clusters, most ones switch to automated patch management solutions or automation tools like Ansible which basically perform the same commands as the patch does.

In the past, I repackaged this patch for the API as a Debian package which allowed a quick integration but I'm not maintaining this anymore as other solutions took place. Most known ones are probably PegaProx and ProxPatch. By different solutions, invoking this via sudo users is also possible to make sure those things won't be executed by the root user.
Click to expand...
This is exactly why this must be owned as a solution by Proxmox. Relying on third parties (ansible), and community projects (PegaProx/ProxPatch) is not suitable from an enterprise solution when first party support is expected for a rudimentary function. Sure the Ansible angle is a legit path, but it should not be the only one just because Proxmox can't deliver a solution to unbridge WebGUI based updates from that damn root account.
 
Johannes S said:
I think the main issue with adding such a feature to the API would be that anybody who can do system upgrades basically gets "root" powers. So if your compilance requirements are that you need to limit the potential breakage done by a single person you are lost at that point anyhow: If the person is somebody with the (fictional) api permission systemupdate they can also do everything possible with root.
If however your compilance requirement is also that a natural person should never have root powers, this requirements can't be fulfilled due to being contradictory. Now I'm aware that conflicting requirements have never stopped managers from insisting that they be met in full. So in the end it boils down whether you agree with the technical argument or whether on a practical level you are fine with enabling such a thing in the API and advising admins to get their "We accept the risc" stampf of approval from their compilance/checkboxes theater managers.

For large environments dedicated tools like ansible, proxpatch together with proxmox-offline-mirror or some other patch management tool (like pul/foreman etc) etc are the better path anyhow
Click to expand...
Compliance in healthcare, Legal, and Financial requires least privileged access. The fact we are still getting update controls wrapped around root is a violation of this. The other fact of this, I can SSSD/OAuth to any host at PVE/PAM or even a custom realm. I can drop into Host>Shell manually or hit SSH and do the update/upgrade via dropping into su- against any of my sudo privileged accounts. However, logged into the PVE GUI on such privileged account does not grant update/upgrade access to the elemental controls. In the current state, this is a broken feature of Proxmox to deliver a supportable least privilege access method to control updates and upgrades on their stack. Of course on the Linux side of the stack you can build this out like any other Linux system, but that again is not first party ownership and support.
 
But if you do an update you also get the possibility to execute code that way. I'm aware of the issue with heavily regulated environments. My point is that introducing such a feature might check a box but won't change the fundamental security issue with granting executing code as root
 
Johannes S said:
But if you do an update you also get the possibility to execute code that way. I'm aware of the issue with heavily regulated environments. My point is that introducing such a feature might check a box but won't change the fundamental security issue with granting executing code as root
Click to expand...
You're still conflating execution context with authentication. The process will always execute as root. My point is that no administrator should have to authenticate as a shared root identity to initiate that process. That's why sudo, polkit, and enterprise IAM exist. They preserve individual identity and accountability while allowing the backend to perform privileged operations.
 
_--James--_ said:
You're still conflating execution context with authentication. The process will always execute as root. My point is that no administrator should have to authenticate as a shared root identity to initiate that process. That's why sudo, polkit, and enterprise IAM exist. They preserve individual identity and accountability while allowing the backend to perform privileged operations.
Click to expand...
What is stopping you from executing this by sudo, as you already mentioned this? I mean, ProxPatch exactly supports this for exactly this reason ;)
 
  • Like
Reactions: Johannes S
gyptazy said:
What is stopping you from executing this by sudo, as you already mentioned this? I mean, ProxPatch exactly supports this for exactly this reason ;)
Click to expand...
The workaround isn't the issue. The issue is first-party ownership. I shouldn't have to deploy ProxPatch or another community project to achieve an enterprise identity model for one of the most fundamental lifecycle operations of the platform.
 
gyptazy said:
True. Then it's probably about starting to contribute :)
Click to expand...
You mean as in paying for the subscriptions? which every enterprise I manage have deployed PVE on does? Love how this comes back to "you want a feature then contribute" when that is not even the issue here. If you mean open a ticket, or file a bug report? Both have been done, the bug report dates back to 2018.
 
I can drop into Host>Shell manually or hit SSH and do the update/upgrade via dropping into su- against any of my sudo privileged accounts. However, logged into the PVE GUI on such privileged account does not grant update/upgrade access to the elemental controls. In the current state, this is a broken feature of Proxmox to deliver a supportable least privilege access method to control updates and upgrades on their stack
Click to expand...

Well, you can limit the sudo priviledge by specifying the exact commands that should be capable to run.
(e.g. %test ALL=(ALL:ALL) /usr/bin/apt update, /usr/bin/apt upgrade -y) and sudo logs all actions to journalctl

If you like to try out a LCM solution with GitOps in mind you might be interested to take a look at https://gitlab.com/cloudandheat/pve/engine.
That one enables to run declarative Ansible from a runner, without personal priviledged users on the PVE hosts.
The access to the cluster is then controlled and tracked, by the access and commits to the git repo.

BR, Lucas
 
  • Like
Reactions: Johannes S
bl1mp said:
Well, you can limit the sudo priviledge by specifying the exact commands that should be capable to run.
(e.g. %test ALL=(ALL:ALL) /usr/bin/apt update, /usr/bin/apt upgrade -y) and sudo logs all actions to journalctl

If you like to try out a LCM solution with GitOps in mind you might be interested to take a look at https://gitlab.com/cloudandheat/pve/engine.
That one enables to run declarative Ansible from a runner, without personal priviledged users on the PVE hosts.
The access to the cluster is then controlled and tracked, by the access and commits to the git repo.

BR, Lucas
Click to expand...
I agree that GitOps, Ansible, sudo, and similar tooling are all valid operational approaches. My point isn't that there are no workarounds. My point is that the supported first-party GUI still lacks an enterprise identity model for host lifecycle operations. That's a product capability discussion, not an automation discussion.
 
You must log in or register to reply here.
Top Bottom
Back