Hello everyone,
I have connected both my PVE and PBS instances to an OpenID Connect provider for easier authentication.
Despite giving my OIDC user the Administrator role over the entire tree (path "/", Role "Administrator"), there's still a bunch of things it can't do:
- Getting a root shell on the host by clicking "Shell" without re-authenticating with a password.
- Updating a host by going to the "Updates" menu, the "Upgrade" button is greyed out.
- I can't update another user's password without knowing their previous password. root@pam can do that.
- There's a bunch of options on LXC containers like the "Features" option that I can't change.
- I can't install Ceph by going to the "Ceph" menu on a host.
- and probably many more I haven't noticed yet
I found various posts on the forum, but they're all multiple years ago. There's apparently a series of patches at https://lists.proxmox.com/pipermail/pve-devel/2022-June/053150.html with the idea of introducing a "Super-Admin" role that would finally be equivalent to "root@pam", but it doesn't look like that ever got merged as I can't find that permission anywhere in my PVE or PBS system, even though it's already been four years since this was posted. I can see the patches on the mailing list but I can't find any discussions as to why this didn't get merged or if there's an alternative or if there's still work going on.
Has there been any progress in that regard? Can this be re-prioritized and eventually be implemented? It looks like the patches already exist on the mailing list so it shouldn't be that difficult. I would like to be able to give actual full root permissions to an OIDC user so there is absolutely no visible difference between being logged in as an OIDC user or being logged in as root@pam. That way I can have admins log in through OIDC without having to know a single shared root password and while still having audit logs about which admin did what on the machine. Right now, it's a bit annoying that everyone who wants to run OS updates or reset a user's password still needs to use the actual root password...
I have connected both my PVE and PBS instances to an OpenID Connect provider for easier authentication.
Despite giving my OIDC user the Administrator role over the entire tree (path "/", Role "Administrator"), there's still a bunch of things it can't do:
- Getting a root shell on the host by clicking "Shell" without re-authenticating with a password.
- Updating a host by going to the "Updates" menu, the "Upgrade" button is greyed out.
- I can't update another user's password without knowing their previous password. root@pam can do that.
- There's a bunch of options on LXC containers like the "Features" option that I can't change.
- I can't install Ceph by going to the "Ceph" menu on a host.
- and probably many more I haven't noticed yet
I found various posts on the forum, but they're all multiple years ago. There's apparently a series of patches at https://lists.proxmox.com/pipermail/pve-devel/2022-June/053150.html with the idea of introducing a "Super-Admin" role that would finally be equivalent to "root@pam", but it doesn't look like that ever got merged as I can't find that permission anywhere in my PVE or PBS system, even though it's already been four years since this was posted. I can see the patches on the mailing list but I can't find any discussions as to why this didn't get merged or if there's an alternative or if there's still work going on.
Has there been any progress in that regard? Can this be re-prioritized and eventually be implemented? It looks like the patches already exist on the mailing list so it shouldn't be that difficult. I would like to be able to give actual full root permissions to an OIDC user so there is absolutely no visible difference between being logged in as an OIDC user or being logged in as root@pam. That way I can have admins log in through OIDC without having to know a single shared root password and while still having audit logs about which admin did what on the machine. Right now, it's a bit annoying that everyone who wants to run OS updates or reset a user's password still needs to use the actual root password...
Last edited: