0

Just installed Openstack victoria. Was using a previous version. For some reason I am having a bit of trouble searching the web for this question.

To the point: users who have the "members" role of a project can delete anything in that project, including items the admin role added (e.g. routers, networks, glance images).

More details: I create a project "myproject" and user "myuser". I add "myuser" to the role "members" and login to the horizon dashboard. This user can launch instances, all is well and good. However, I realized later, by accident, this user can delete routers, networks, glance images, and actually anything in the project. This is not the behaviour I desire.

I am not sure this was the default behaviour of the previous openstack install I had, but how do I prevent this behaviour now (e.g. I want to add users to the project, and have them be able to launch instances, but NOT be able to delete glance images, networks, routers, etc). For some reason I am having a tough time finding this online.

Note: I just found this old entry which outlines how to prevent user1 from deleting user2s instance. But that is only instances.

number9
  • 253
  • 2
  • 11
  • That's the default. The OpenStack permission system has always had huge room for improvement, and only in the four or so recent releases there has been a strong effort to improve the situation. It should be possible to extend the suggestion made in the referenced ask.openstack question to other APIs and other OpenStack components, but it would be a lengthy and tedious task with many pitfalls. I wonder, are the big public clouds doing a better job though? – berndbausch Feb 22 '21 at 00:13
  • Yes the big cloud providers do seem to do a better job. In particular, it is possible to create and assign policies via the API, a feature that is entirely missing from OpenStack. – berndbausch Feb 22 '21 at 00:17
  • Wait a moment, you answered the original entry I linked to. How did you come about finding the "os_compute_api:servers:delete" token? If I could find a list of those, I might be able to tediously create a list of the ones I do not want the users to delete and add that to the /etc/nova/policy.json file. Really, i have routers, networks and instances, and I do not want them to delete ones they do not own. – number9 Feb 22 '21 at 02:55
  • In the past, like all other OpenStack services Nova used a file `/etc/nova/policy.json` that contained a list of all APIs and their permissions. `os_compute_api:servers:delete` refers to the API request for deleting an instance, and `"is_admin:True or user_id:%(user_id)s"` was my off-the-cuff attempt to allow either the administrator or the owner to delete an instance. Unfortunately, this language is insufficiently documented. In any case, some releases ago `policy.json` was replaced by "policy in code", i.e. hardwired policies in Nova's code. – berndbausch Feb 22 '21 at 05:45
  • However, if you don't like the default policies, you can override them by creating a `policy.json` that just contains those policy rules you want to customize. You start with the default policies, which you can generate by [a special command](https://docs.openstack.org/oslo.policy/latest/cli/oslopolicy-policy-generator.html), e.g. `oslopolicy-policy-generator --namespace nova > /etc/nova/policy.json`, then modify that. – berndbausch Feb 22 '21 at 05:47
  • There is more info in the [Nova configuration guide](https://docs.openstack.org/nova/latest/configuration/index.html) (which I have not reviewed yet, to be honest). By the way, the policy file can also be in YAML format, and they will probably phase out the JSON format. – berndbausch Feb 22 '21 at 05:49
  • I will admit, since I posted my answer, I am even more confused. When I do, say, oslopolicy-policy-generator --namespace nova > /etc/nova/policy.json and review the file, it seems totally reasonable. Example, "os_compute_api:servers:delete": "rule:system_admin_or_owner" seems completely reasonable. However, if I login to the system as a member, I can indeed delete other users servers. Something is not correct, I think. I can also remove routers, for example, that were setup by me as the admin. but I can delete them when I am logged in as a member. – number9 Feb 22 '21 at 19:01
  • "owner" is the project, not the user. The rule `system_admin_or_owner` is defined near the beginning of the file. – berndbausch Feb 22 '21 at 23:36
  • Ohhhhh, that makes a lot more sense now as to why anyone can delete anything. Wow. – number9 Feb 23 '21 at 00:30

1 Answers1

0

This answer is really a thanks to Berndbausch, who pointed me in the right direction:

In comments, berndbausch lined to the Nova configuration guide. As with most Openstack docs, it is actually out of date as given by the warning at the top. On that page, there is a short policy section, which will also lead you to a policy concepts page (I have changed both URLs to point to Victoria, as by default openstack has "latest" in the URL, which does NOT point to the latest release).

The policy concepts page is linked here.

In essence the solution is that you can still write policy files as berndbausch points out, and nova has a default policy file generated at install, which is located here. Note at the top of that page, the policy is available in json also.

The policy can be modified in that file, or reading the concepts page I linked to above, one can actually use some built in system reader and member reader roles, but I am not 100% sure how to switch between roles on the fly, however, modifying the policy will get me where I want to go.

number9
  • 253
  • 2
  • 11