Ability for non-admins to create tags
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| MAAS |
Wishlist
|
Unassigned |
Bug Description
MAAS 2.8
Ubuntu 18.04 LTS
Currently based on the api documentation when setting a tag -
POST /MAAS/api/
You will get a 403 error as regular user -
HTTP Status Code : 403
Content
Must be a superuser or supply a rack_controller.
There is a case to be made that this ability should not be an administrative tasks only and should be allowed as a non-administrative tasks for regular users.
From customer -
Then please consider this an RFE. Setting tags should not be restricted to administrators (I can see an argument for *creating* tags being administrative). Consider this example use case. MAAS user/roles PSB, MORPHEUS, ADMIN. Both PSB and MORPHEUS are, themselves, infrastructure management systems which parcel systems out to end users. Ideally, neither PSB nor MORPHEUS should be able to take over each others systems (so should NOT be administrators). But if they aren't administrators, they can't use the tagging system (e;g. to mark a machine as needing non-MAAS remediation (see our cases about Dell BOSS, MAAS deficiencies in sanitizing NVMe, DELL BOSS, Dell/Samsung SSD), etc). Tags may well be used for a wide variety of purposes, and non-administrative users being barred from assigning a tag to a system it "owns" makes either tags, or the non-administrative facility useless in our context.
Similarly, for setting storage ... having allocated a machine to "PSB" why should PSB not be able to configure the desired storage?
This is not an exhaustive list .. but it seems to us that non-administrative roles are overly constrained. I suppose for compatibility purposes this would mean either a recasting (a generic, perhaps bitflag controlled (this feature on, that feature off) with the default non-administrative roles to be locked down as they are now, or a third kind of role). To a first approximation what we expected/require is that the non-administrative roles can't change MAAS itself, nor should they be able to see or manipulate systems that are allocated to other users. No other limitations on what these users can do ...
With the current setup, this means all users are administrative ... which means there are no protections against one user/role taking over systems that are in use by others (which is unfortunate, to say the least).
tags: | added: sts |
Changed in maas: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |