I help teams fix systemic engineering issues: processes, architecture, and clarity.
→ See how I work with teams.
Openstack lacks on sophisticated rights management, the most users figure. But that's not the case, role management in Openstack is available.
First users and groups needs to be added to projects, this can be done per CLI or GUI [1]. Lets say, a group called devops shall have the full control about OpenStack, but others not in that group can have dedicated operation access like create snapshot, stop / start / restart an instance or looking at the floating IP pool.
Users, Groups and Policies
OpenStack handles the rights in a policy file in /etc/nova/policy.json, using roles definitions per group assigned to all tasks OpenStack provides. It looks like:
{"context_is_admin": "role:admin",
"admin_or_owner": "is_admin:True or project_id:%(project_id)s",
"default": "rule:admin_or_owner",...
}
and describes the default - a member of a project is the admin of that project. To add additional rules, they have to be defined here.
In my case, I created a goup devops, added the users and defined the rights like:
"devops": "is_admin:True or (project_id:%(project_id)s and not role:user and not role:guest)",
and assigned the role to all tasks, an DevOps team member should be able to perform. Project owners / admins can operate with instances in her project, but in an controlled way. Basically, I revoked all delete / move / reassign tasks, like network and subnet management or delete an instance.
The full policy file is available in my GitHub repo [2].
[1] http://docs.openstack.org/admin-guide/cli-manage-projects-users-and-roles.html[2] https://github.com/alo-alt/OpenStack/blob/master/policy.json
If you need help with distributed systems, backend engineering, or data platforms, check my Services.