PowerVC 1.3.3 includes several role-related changes including UI support, a removed role, a renamed role and a new role. Let’s dive in and look at each of these changes!
Prior to PowerVC 1.3.3, role assignments had to be made with CLI commands. PowerVC 1.3.3 brings this capability to the web UI. An admin can now view and modify role assignments for the currently-selected project by going to Configuration -> Users and Groups.
Select the user or group who needs a role assignment and click on the Edit Assigned Roles button. Some roles donâ€™t work well with others, so they have radio buttons (allowing you to only select one), but others have checkboxes that allow you to combine multiple roles for the same user or group. Once saved, your changes will apply to all subsequent logins.
Note that users may have roles via their group memberships in addition to the roles that they have been assigned directly. Such assignments are included in the Inherited Roles column, but are only editable on the Groups panel.
In the screenshot above, we have given user_1 both the Image manager and Virtual machine user roles. We can also see this reflected in the Users table:
To revoke all roles from a user or group, select the user or group, click Edit Assigned Roles, and select None. If a user or group has multiple roles and you only wish to remove some of them, simply deselect the checkboxes for the roles you wish to remove. In either case, make sure to save your changes.
The OpenStack role assignment CLIs that were used for granting and revoking role assignments to users and groups in previous releases are now deprecated in favor of the UI. They will still work, but support will be removed in a future release. It is recommended that you use the UI instead.
Removed deployer role
The deployer role was deprecated in PowerVC 188.8.131.52 with notice that it would be removed in a future release. The functionality remained available in the 1.3.1.x and 1.3.2.x releases to give time for PowerVC admins to migrate users to other roles, but the time has finally come to remove it.
During the upgrade to PowerVC 1.3.3, any users or groups that still have a deployer role assignment will have that assignment replaced with image_manager, storage_manager and vm_manager role assignments. That combination of roles was chosen as the closest approximation of the old deployer role, but you should review the role definitions and decide whether or not these are best for your situation. For instance, if a user doesn’t need image_manager permissions, remove that assignment to follow the principle of least privilege.
A user named bob and a group named deployer_group have the deployer role in PowerVC 184.108.40.206:
After upgrading to 1.3.3, bob and any users in the deployer_group group have 3 roles: image_manager, storage_manager and vm_manager:
Renaming deployer_restricted role
The role formerly called deployer_restricted is being renamed to deployer. With the removal of the original deployer role, the more concise and intuitive name became available. There are no changes to the privileges that this role currently holds and all users and groups with the deployer_restricted role prior to upgrade will have the same privileges after upgrading to PowerVC 1.3.3, although their role will now be called deployer.
A user named sally and a group named depres_group have the deployer_restricted role in PowerVC 220.127.116.11.
After upgrading to 1.3.3, sally and any users in the depres_group group have the deployer role, with the same permissions formerly afforded by the deployer_restricted role.
New project_manager role
The admin role is very highly privileged in OpenStack deployments. An admin is allowed to see and control the infrastructure on which PowerVC operates: compute hosts, storage providers, etc. Though there is work underway in the OpenStack community to restrict this, currently an admin can even see and do some things in projects where they donâ€™t have a role assignment.
In a cloud setting, it is common to have multiple projects for different teams. As the number of projects and users grows, it will become harder and harder for the small set of users entrusted with the powerful admin role to do things like review every self service user request. Enter the project_manager role. This role is introduced specifically for IBM Cloud PowerVC Manager to fill the gap between the admin and self_service roles. A user with the project_manager role cannot see the underlying infrastructure and has no access to other projects on which they do not have a role, but within the scope of their assignment project they are otherwise much like an admin. Delegation of the project_manager role should free up admin users to manage the infrastructure and PowerVC itself.
The exact permissions of the project_manager role are:
â€¢ Viewing and editing cloud policies
â€¢ Viewing and editing email server and template configuration
â€¢ Approving or rejecting requests from self service users
â€¢ Editing virtual machine ownership and expiration dates
â€¢ Viewing quotas and resource usage information
â€¢ Deploying virtual machines from a deploy template
â€¢ Deleting, resizing, starting, stopping, or restarting virtual machines
â€¢ Configuring their own email preferences (if an email server has been configured)
Admin: Has complete access to and control of PowerVC. Due to current OpenStack limitations, these permissions might not be constrained to the project for which this role is assigned.
Viewer: Has read-only access to the assigned project. Cannot perform any actions.
Self_service*: Has a greatly simplified view. Cannot see virtual machines that they do not own. Allowed to perform a limited set of actions on virtual machines that he or she owns, subject to cloud policies that might require approval from an administrator or project_manager.
Project_manager*: Has a simplified view but significant permissions within that view to reduce the need for admin involvement.
*: Available in IBM Cloud PowerVC Manager only.
Vm_manager: Can view most things and has significant control over virtual machines from deployment through deletion but cannot control infrastructure, storage, or images.
Storage_manager: Can view most things but canâ€™t affect much other than storage.
Image_manager: Can view most things but canâ€™t affect much other than images.
Vm_user: Can view most things but canâ€™t affect much other than performing lifecyle operations on existing virtual machines.
Deployer: Can view most things but canâ€™t affect much other than deploying new virtual machines.
Authors : Matthew Edmonds, Archana Prabhakar