Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com › SUSE OpenStack Cloud Crowbar 9 Documentation › Deployment Guide using Crowbar › Setting Up OpenStack Nodes and Services › Limiting Users' Access Rights
ContentsContents
Deployment Guide using Crowbar
  1. About This Guide
  2. I Architecture and Requirements
    1. 1 The SUSE OpenStack Cloud Architecture
    2. 2 Considerations and Requirements
  3. II Setting Up the Administration Server
    1. 3 Installing the Administration Server
    2. 4 Installing and Setting Up an SMT Server on the Administration Server (Optional)
    3. 5 Software Repository Setup
    4. 6 Service Configuration: Administration Server Network Configuration
    5. 7 Crowbar Setup
    6. 8 Starting the SUSE OpenStack Cloud Crowbar installation
    7. 9 Customizing Crowbar
  4. III Setting Up OpenStack Nodes and Services
    1. 10 The Crowbar Web Interface
    2. 11 Installing the OpenStack Nodes
    3. 12 Deploying the OpenStack Services
    4. 13 Limiting Users' Access Rights
    5. 14 Configuration Files for OpenStack Services
    6. 15 Installing SUSE CaaS Platform heat Templates
    7. 16 Installing SUSE CaaS Platform v4 using terraform
  5. IV Setting Up Non-OpenStack Services
    1. 17 Deploying the Non-OpenStack Components
  6. V Troubleshooting and Support
    1. 18 Troubleshooting and Support
  7. A Using Cisco Nexus Switches with neutron
  8. B Documentation Updates
  9. Glossary of Terminology and Product Names
Navigation←→
documentation.suse.com › SUSE OpenStack Cloud Crowbar 9 Documentation › Deployment Guide using Crowbar › Setting Up OpenStack Nodes and Services › Limiting Users' Access Rights
Top
←→
Applies to SUSE OpenStack Cloud Crowbar 9

13 Limiting Users' Access Rights

13.1 Editing policy.json
13.2 Editing keystone_policy.json
13.3 Adjusting the keystone Barclamp Proposal
13.4 Adjusting the horizon Barclamp Proposal
13.5 Pre-Installed Service Admin Role Components

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:

  1. 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”.

  2. 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”.

  3. Make the keystone component aware of the CUSTOM_policy.json file by editing and reapplying the keystone barclamp. For details, see Section 13.3, “Adjusting the keystone Barclamp Proposal”.

  4. Make the horizon component aware of the keystone_policy.json file by editing and reapplying the horizon barclamp. For details, see Section 13.4, “Adjusting the horizon 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.

  1. Copy /etc/keystone/policy.json and save it under a different name, for example CUSTOM_policy.json.

    Important
    Important: Use Different File Name

    If you use the same name as the original file, your custom file will be overwritten by the next package update.

  2. 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",
  [...]

  3. 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",

  4. Save the changes.

  5. 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).

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.

  1. Copy /srv/www/openstack-dashboard/openstack_dashboard/conf/keystone_policy.json and save it under a different name, for example CUSTOM_keystone_policy.json.

    Important
    Important: Use Different File Name

    If you use the same name as the original file, your custom file will be overwritten by the next package update.

  2. 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",
  [...]

  3. 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",

  4. 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.

13.3 Adjusting the keystone Barclamp Proposal

  1. Log in to the Crowbar Web interface.

  2. Select Barclamps › All barclamps.

  3. Go to the keystone barclamp and click Edit.

  4. In the Attributes section, click Raw. This shows the complete configuration file and allows you to edit it directly.

  5. Adjust the policy_file parameter to point to the CUSTOM_policy.json file. For example:

    {
  [...]
  "policy_file": "mypolicy.json",

  6. Save and Apply the changes to the keystone barclamp.

13.4 Adjusting the horizon Barclamp Proposal

  1. Log in to the Crowbar Web interface.

  2. Select Barclamps › All barclamps.

  3. Go to the horizon barclamp and click Edit.

  4. In the Attributes section, click Raw. This shows the complete configuration file and allows you to edit it directly.

  5. 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.

  6. 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"

  7. Save and Apply 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_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.

    Warning
    Warning: Changing 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.

→Chapter 14 Configuration Files for OpenStack Services←Chapter 12 Deploying the OpenStack Services
Print this page

© 2021 SUSE