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 the keystone-server
role is
deployed, copy the file to
/etc/keystone/CUSTOM_policy.json
.
For details, see Section 13.1, “Editing policy.json
”.
Create a custom keystone_policy.json
file for the
horizon component. On the node where the
nova_dashboard-server
role is deployed, copy the custom
keystone_policy.json
file to
/srv/www/openstack-dashboard/openstack_dashboard/conf/
(default directory for policy files in horizon). For details, see
Section 13.2, “Editing keystone_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”
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 example
CUSTOM_policy.json
.
If 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, the keystone-server
role is deployed to a Control Node
(or to a cluster, if you use a High Availability setup).
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 example
CUSTOM_keystone_policy.json
.
If 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 the nova_dashboard-server
role is
deployed.
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 the
CUSTOM_policy.json
file.
For example:
{ [...] "policy_file": "mypolicy.json",
and the changes to the keystone barclamp.
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 added
CUSTOM_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 the policy_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"
and the changes to the horizon barclamp.
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 in nova policy.json
. Assign this role to
users whose job function it is to perform nova-compute
-related
administrative tasks.
neutron_admin
role in the identity service and support
in neutron 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
in cinder 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
in glance policy.json
. Assign this role to users
whose job function it is to perform cinder storage-related administrative
tasks.
glance_policy.json
may Introduce a
Security Issue
The 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.