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.jsonfile for the keystone component. On the node where thekeystone-serverrole is deployed, copy the file to/etc/keystone/CUSTOM_policy.json. For details, see Section 13.1, “Editingpolicy.json”.Create a custom
keystone_policy.jsonfile for the horizon component. On the node where thenova_dashboard-serverrole is deployed, copy the customkeystone_policy.jsonfile 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.jsonfile 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.jsonfile 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.jsonand 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-serverrole is deployed, copy the file to/etc/keystone/CUSTOM_policy.json. Usually, thekeystone-serverrole 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.jsonand 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.jsonon the node where thenova_dashboard-serverrole 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_fileparameter to point to theCUSTOM_policy.jsonfile. For example:{ [...] "policy_file": "mypolicy.json",and the changes to the keystone barclamp.
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_pathparameter to point to the directory where you copied the newly addedCUSTOM_keystone_policy.jsonfile. 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
identityparameter within thepolicy_filesection (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"and the changes to the horizon barclamp.
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_adminrole 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_adminrole 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_adminrole 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_adminrole 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.jsonmay 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.jsonthat 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.