13 Limiting Users' Access Rights #
To limit users' access rights (or to define more fine-grained access
rights), you can use Role Based Access Control (RBAC, only available with
keystone v3). In the example below, we will create a
new role (ProjectAdmin
). It allows users with this role to
add and remove other users to the member
role on the same
project.
To create a new role that can be assigned to a user-project pair, the following basic steps are needed:
Create a custom
policy.json
file for the keystone component. On the node where thekeystone-server
role is deployed, copy the file to/etc/keystone/CUSTOM_policy.json
. For details, see Section 13.1, “Editingpolicy.json
”.Create a custom
keystone_policy.json
file for the horizon component. On the node where thenova_dashboard-server
role is deployed, copy the customkeystone_policy.json
file to/srv/www/openstack-dashboard/openstack_dashboard/conf/
(default directory for policy files in horizon). For details, see Section 13.2, “Editingkeystone_policy.json
”.Make the keystone component aware of the
CUSTOM_policy.json
file by editing and reapplying the barclamp. For details, see Section 13.3, “Adjusting the . Barclamp Proposal”Make the horizon component aware of the
keystone_policy.json
file by editing and reapplying the barclamp. For details, see Section 13.4, “Adjusting the . Barclamp Proposal”
13.1 Editing policy.json
#
The policy.json
file is located in
/etc/keystone/
on the node where the
keystone-server
role is deployed.
Copy
/etc/keystone/policy.json
and save it under a different name, for exampleCUSTOM_policy.json
.Important: Use Different File NameIf you use the same name as the original file, your custom file will be overwritten by the next package update.
To add the new role, enter the following two lines at the beginning of the file:
{ "subadmin": "role:ProjectAdmin", "projectadmin": "rule:subadmin and project_id:%(target.project.id)s", [...]
Adjust the other rules in the file accordingly:
"identity:get_domain": "rule:admin_required or rule:subadmin", [...] "identity:get_project": "rule:admin_required or rule:projectadmin", [...] "identity:list_user_projects": "rule:admin_or_owner or rule:projectadmin", [...] "identity:update_project": "rule:admin_required or rule:projectadmin", [...] "identity:get_user": "rule:admin_required or rule:projectadmin", "identity:list_users": "rule:admin_required or rule:subadmin", [...] "identity:list_groups": "rule:admin_required or rule:subadmin", [...] "identity:list_roles": "rule:admin_required or rule:subadmin", [...] "identity:list_grants": "rule:admin_required or (rule:subadmin and project_id:%(target.project.id)s)", "identity:create_grant": "rule:admin_required or (rule:subadmin and project_id:%(target.project.id)s and 'member':%(target.role.name)s)", "identity:revoke_grant": "rule:admin_required or (rule:subadmin and project_id:%(target.project.id)s and 'member':%(target.role.name)s)", [...] "identity:list_role_assignments": "rule:admin_required or rule:subadmin",
Save the changes.
On the node where the
keystone-server
role is deployed, copy the file to/etc/keystone/CUSTOM_policy.json
. Usually, thekeystone-server
role is deployed to a Control Node (or to a cluster, if you use a High Availability setup).
13.2 Editing keystone_policy.json
#
By default, the keystone_policy.json
file is
located in
/srv/www/openstack-dashboard/openstack_dashboard/conf/
on the node where the nova_dashboard-server
role is
deployed. It is similar (but not identical) to
policy.json
and defines which actions the user with a
certain role is allowed to execute in horizon. If the user is not
allowed to execute a certain action, the OpenStack Dashboard will show an
error message.
Copy
/srv/www/openstack-dashboard/openstack_dashboard/conf/keystone_policy.json
and save it under a different name, for exampleCUSTOM_keystone_policy.json
.Important: Use Different File NameIf you use the same name as the original file, your custom file will be overwritten by the next package update.
To add the new role, enter the following two lines at the beginning of the file:
{ "subadmin": "role:ProjectAdmin", "projectadmin": "rule:subadmin and project_id:%(target.project.id)s", [...]
Adjust the other rules in the file accordingly:
"identity:get_project": "rule:admin_required or rule:projectadmin", [...] "identity:list_user_projects": "rule:admin_or_owner or rule:projectadmin", [...] "identity:get_user": "rule:admin_required or rule:projectadmin", "identity:list_users": "rule:admin_required or rule:subadmin", [...] "identity:list_roles": "rule:admin_required or rule:subadmin", [...] "identity:list_role_assignments": "rule:admin_required or rule:subadmin",
Save the changes and copy the file to
/srv/www/openstack-dashboard/openstack_dashboard/conf/CUSTOM_keystone_policy.json
on the node where thenova_dashboard-server
role is deployed.
13.3 Adjusting the Barclamp Proposal #
Log in to the Crowbar Web interface.
Select
› .Go to the
barclamp and click .In the
section, click . This shows the complete configuration file and allows you to edit it directly.Adjust the
policy_file
parameter to point to theCUSTOM_policy.json
file. For example:{ [...] "policy_file": "mypolicy.json",
13.4 Adjusting the Barclamp Proposal #
Log in to the Crowbar Web interface.
Select
› .Go to the
barclamp and click .In the
section, click . This shows the complete configuration file and allows you to edit it directly.If needed, adjust the
policy_file_path
parameter to point to the directory where you copied the newly addedCUSTOM_keystone_policy.json
file. By default, its value is an empty string—this means that the default directory will be used.Enter the new file's name as value of the
identity
parameter within thepolicy_file
section (1):{ "policy_file_path": "", "policy_file": { "identity": "mykeystone_policy.json", 1 "compute": "nova_policy.json", "volume": "cinder_policy.json", "image": "glance_policy.json", "orchestration": "heat_policy.json", "network": "neutron_policy.json", "telemetry": "ceilometer_policy.json"
13.5 Pre-Installed Service Admin Role Components #
The following are the roles defined in SUSE OpenStack Cloud Crowbar. These roles serve as a way to group common administrative needs at the OpenStack service level. Each role represents administrative privilege into each service. Multiple roles can be assigned to a user. You can assign a Service Admin Role to a user once you have determined that the user is authorized to perform administrative actions and access resources in that service.
The main components of Service Administrator Roles are:
nova_admin
role in the identity service (keystone) and support innova policy.json
. Assign this role to users whose job function it is to performnova-compute
-related administrative tasks.neutron_admin
role in the identity service and support inneutron policy.json
. Assign this role to users whose job function it is to perform neutron networking-related administrative tasks.cinder_admin
role in the identity service and support incinder policy.json
. Assign this role to users whose job function it is to perform cinder storage-related administrative tasks.glance_admin
role in the identity service and support inglance policy.json
. Assign this role to users whose job function it is to perform cinder storage-related administrative tasks.Warning: Changingglance_policy.json
may Introduce a Security IssueThe OpenStack Security Note OSSN-0075 https://wiki.openstack.org/wiki/OSSN/OSSN-0075 describes a scenario where a malicious tenant is able to reuse deleted glance image IDs to share malicious images with other tenants in a manner that is undetectable to the victim tenant.
The default policy
glance_policy.json
that is shipped with SUSE OpenStack Cloud Crowbar prevents this by ensuring only admins can deactivate/reactivate images:"deactivate": "role:admin" "reactivate": "role:admin"
SUSE suggests these settings should not be changed. If you do change them please refer to the OSSN-0075 https://wiki.openstack.org/wiki/OSSN/OSSN-0075 for details on the exact scope of the security issue.