Hi IsThisThingOn,
thanks for your impressions. I tried to answer them in the best way, even if the topic is a very long one.
It depends.
Windows uses the User / share permission and uses a more restrictive AND permission logic.
But for Users and groups, it uses the less restrictive OR permission logic.
And Synology does this stuff again differently by using the more restrictive AND permission logic "your user might have permission, but he/she also belongs to group X which has no permission, so no permission for him/her".
In Windows environments you can do both at the same time, permission management via User/Groupmembership for the filesystem as well as explicit share permissions.
Both need to allow access to a shared folder, or it will result in no access.
This usually leads to situations where the configuration allows everybody access to the share
and then the permissions on the filesystem ensures the access control. (and explicitly deny permissions).
But that is filesystem permission management, not api management. (I have no experience with Synology)
A recommended way in an organization is using at least user- and ressourcegroups:
- usergroups to group the people that needs permissions according their organizational position (e.g. teams)
- ressourcegroups to group permissions on ressources (e.g. read or write access to shared folders, or in pve permissions on ressourcepools)
PVE and PBS is very strong at this point because they allow a very fine grained configuration for the permissions of groups. Unfortunately there is no nesting of groups, which can work fine with external realms which manages the usergroups.
This setup allows delegating various permissions including the partly administration of the clusters., following the principal of segregation of duties.
By this reason every regular user should able to create his/her own tokens, for the automation of specific tasks.
People will change their role within an organization (joiner-mover-leaver) and therefore their membership in the usergroups (handled by external realms). Which means they will gain or lose permissions on the specific ressources, due to inheritance. Tokens do only exist in the PVE/PBS world. So it is a necessary requirement that as well the token as also the user owning the token has the necessary requirements. Otherwise the tokens a cluster administrator would not be deactivated in an automated way, after the person left the company or changed her/his role.
So I would argue, it is not very logical. On the contrary I would argue that most API tokens handle it differently than PBS.
For API keys or for SSH access, I would naturally assume it to behave differently than how it currently does in PBS.
First of all, I don't get why an API Token even has to be connected to a user.
I just want a token that has the permission to do X, like with almost any other API.
That forces me to create a user, which in return makes that user possible to login in the webGUI over the pbs realm.
But I don't want my backup1 API token to have a the user backup1, and then I have add 2FA, because otherwise my public webGUI has a brute force vector. I just want that I can create a backup API token, that has certain permissions defined for the token and nothing more.
You will need that user anyway e.g. the root user, or the personalized admin users, or (because personal and service account should actually not beeing mixed) a service user with a very complex password + MFA + monitoring ... The permissions of that service user can be restricted, too. And in an ideal world there should be an automated expiring process, the requires the confirmation of the necessity of that service within a given time period.
The WebUI also relies on the API for authentication and runs on the same port. So a simple ip based separation, is not possible. Tokens do not require separation of privileges by default.
Instead I have to create the user, add 2FA, add the user permission, add the token permission.
For me, having a token or public key and not needing passwords is the whole point of using tokens instead of users. With the current implementation, one big advantage of public_key instead of password falls on its face.
Compare that to something like an S3.
You create a API token, what capabilities it has, what buckets it has access to and that is it.
No user, nothing.
Mhm, can you elaborate how to implement automatic lifecycle management for tokens with S3-Buckets for cases of joiner-mover-leaver?
BR, Lucas
