Users and Permissions¶
CloudBolt Admins can create new users, associate users to Groups, and assign multiple types of roles.
- In the Admin tab, click Users.
- Click the email address of a user to view their profile, their assigned Groups and roles within that Group, and edit their Permissions.
- Users: Create users directly in CloudBolt or through an external authentication system (such as LDAP).
- Groups: Contain users and are associated with Environments.
- Group Roles: Provide users in a Group certain privileges for Environments associated with that Group. For example, a user could be made a requestor in a group called ‘Finance Dept’, which would allow them to request servers in all Environments the Finance Dept can access.
- Special Roles: These roles contain permissions that are automatically granted to users who meet certain criteria for objects (server owner for example). These roles are not shown on the Group or User details pages.
- Global Roles: Provide Users certain global privileges (such as the CloudBolt Admin role).
The permissions afforded to roles, as described above, can include permissions for default CloudBolt functionality (such as server.control_power) as well as Server Actions and Resource Actions. The permissions for running Server Actions and Resource Actions can be granted individually or in bulk.
Creating a New User¶
Only an Admin user may create users in CloudBolt.
- Click Admin > Users
- Click + Create a new User
- Enter user information for all the required fields.
- Click Create.
The first time a user logs in to their account, they will be asked to choose a security challenge question and provide an answer. This answer will be used when a Password Reset is initiated.
The answer to the security question is not case sensitive.
When an existing user’s email address is changed, a verification email with a link is sent to the corresponding address. When the user clicks this link, the email address is saved in the database and marked as verified and active. Email Verification is Enabled by default.
- Enable/Disable Email Verification:
- Click Admin > Miscellaneous Settings
- Toggle Require User Email Verification to Disable or Enable.
When a new user is created by an Admin, a temporary password is assigned to the user by the Admin.
Change a Password: After a new user is created, they may change their temporary password to a password of their choosing. Admin users may also change another user’s password.
- Click user profile (non-admin) or click Admin > Users and select a user.
- Click Manage profile
- In the Change password and Confirm password fields, enter the new password.
- Enter the old password in the Original Password field if required. See Original Password Verification in Miscellaneous Settings.
Password Reset: When a password reset is requested, the user must answer a password reset challenge question. This question is set the first time a user logs in to their account.
- On the CloudBolt login screen, click Forgot your password?
- Enter your email address. An email will be sent that contains a recovery link to reset your password.
- Click the link in the email, and enter the answer to the password reset challenge question.
- Enter a new password and re-enter in the provided fields.
- Click Save password.
If Email default from address is not set up in Email settings, the password reset email may go to the user’s spam folder.
Groups and Permissions¶
Group Roles: Who Can Do What¶
There are five different group roles that come out-of-the-box with CloudBolt.
Click Admin > Roles.
- Viewer: Basic permission to view Group servers, members, and activity.
- Requestor: Request orders for creating, modifying, or deleting servers individually or within a group to which they belong.
- Approver: Approve any requested orders for fulfillment.
- Resource Admin: Manage Parameters and networks on Groups, as well as Blueprints and servers.
- Group Admin: Manages organizational aspects of this group: membership and permissions, subgroup creation and management, and delegation of responsibilities to other group members.
Each user within a group can be assigned any combination of these roles, and depending on which roles they have, a user will be given the ability to perform certain individual or group-related actions.
Administrators can customize what permissions each of these roles have as desired, or even delete them if they are not needed.
- Restore Defaults
- Click Restore defaults to return all out-of-the-box roles to their default configuration. This also reinstates deleted default roles.
- In the Actions column, click the curved arrow icon to restore individual out-of-the-box roles to their default configurations.
Neither of the Restore defaults actions will affect any user-defined roles.
When viewing the Roles UI, there are separate sections for Roles Assignable to Users (Group Roles) and Special Roles. The Special Roles are not assignable, but are instead determined by context. For example, the Resource Owner role comes into play whenever determining permissions for a Resource that the user owns.
By default, these Special Roles get all of the permissions for the particular object type. For example, a Server Owner can do anything to a Server they own.
Delegated Group Administration¶
Delegated group administration allows organizations to decentralize CloudBolt administration at the group level by giving select users the ability to administer entire groups. Because by default Group Admins are only able to make changes within their group and not the entire CloudBolt instance, delegated group administration is a safe way for CloudBolt admins to delegate administrative responsibilities to others so that it may match existing organizational structure.
For example, if Barbara is the technical head of the investment banking division of a financial company, she might be given the out-of-the-box Group Admin role of the CloudBolt group called Investment Banking. As groups can be nested, Barbara could perform her own delegated group administration by creating subgroups for any Investment Banking subdivisions and give the Group Admin role for those subgroups to other users (assuming the Group Admin role has not been customized to remove those permissions). Delegation can also be accomplished on a more fine-grained level by associating permissions such as group.create_subgroup and group.manage_members with roles and assigning users to those roles in a group.
If a user has only the default Group Admin role, no other roles are automatically implied. This means that the Group Admin user would not automatically be able to request or approve orders unless they or another Group Admin gives them the appropriate roles and privileges.
Changing a User’s Role(s)¶
Roles granted to users for a particular group can be configured by going to the group details view and opening the Users tab or on the User’s profile page.
Inheritance of Group Permissions¶
There is an option on the Groups list page to enable inheritance of Group permissions from parent groups to subgroups. This applies to both internal and external users, but only Group Roles.
When inheritance is first enabled, all currently-configured Users and their Roles on any parent group will be inherited down to all its subgroups. Such inherited permissions will be marked as such in the UI, and cannot be removed from the subgroups.
From then on, while inheritance is enabled, any changes made to permissions on a parent group will be propagated down to its subgroup(s). This applies when a User is given a new Group Role (including through an “External User Sync” action) or a Role is removed for a User in that Group. A new subgroup will also automatically get its parent group’s permissions on creation.
Inheritance can be disabled from the Groups list page if it is no longer needed. It will change the existing permissions so they are no longer considered inherited and can be removed, but will not automatically remove them itself.
In addition to showing all the default Group Roles and Special Roles, the Roles page in the CloudBolt UI also allows editing those roles, creating new Group Roles, and deleting Group Roles.
The set of permissions that a user has in a particular context is the sum of all the permissions across all the Group Roles they have in the applicable group, as well as any Special Roles that apply.
A distinction should be made between the effect of having a permission on a Group Role and a Special Role. With a Group Role, that permission will apply to all objects in the Group, but with a Special Role the objects where the user will have that permission will only be those where they match the criteria of that Special Role. For example, the server.view permission in the default Viewers role means that any user with that role in a Group will be able to view all servers in that Group. However, having the server.view permission in the default Server Owner role only allows users to see servers they own.
When editing a Role, the configuration can consist of both permissions for various pieces of CloudBolt functionality (e.g., server.manage_snapshots) and giving that Role permission to run various Server Actions and Resource Actions. There are two possible approaches with regards to privileges for Actions. There are special permissions, server.all_actions and resource.all_actions, that can be used to give a Role permission to run all Server and Resource Actions, respectively. Alternatively, a Role can be given permission to only run specific Actions by using the Server Actions and Resource Actions fields.
For Special Roles, there are some limitations on what can be changed. For one, they cannot be deleted. They also cannot be renamed. When editing, the permissions and actions fields are modified according to the Role being edited to improve clarity. For example, giving non-server permissions to or associating Resource Actions with the Server Owner role doesn’t really make sense, so those options are not available.
There is a reference page that lists a bit more detail on the permission options, such as descriptions. It is linked to both from descriptions on the Roles list and within the help text for the permissions field in the Role edit dialog.
Global Roles include the Super Admin, Devops Admin, Global Viewer, API Access, and CloudBolt Admin roles. An end user account may be granted one or all of these roles. These roles confer extra permissions to a user.
The Super Admin role gives all permissions in CB. This includes the ability to administer CB, plus full access to all groups, servers, and resources.
The Devops Admin role gives a user access to all servers without needing to belong to that server’s group.
A Global Viewer gets permission to view, but only view, everything in the UI, with the exceptions documented below. If this is their only role, they will have no edit capabilities. Note that they may be able to view some sensitive information, such as user details and portals.
The places that a Global Viewer actually cannot see include:
- Lists and details for all types of Actions (base Actions, Orchestration Actions, Server Actions, Resource Actions, Rules, etc.)
- Lists and details for Recurring Jobs
- Lists and details for Continuous Infrastructure Testing
- Lists and details for Configuration Managers
- Lists and details for External Orchestrators
- Lists and details for Security Information and Event Management
- Details for Parameters
- Details for Blueprints
- The Version Info details
- Lists and details for LDAP Utilities
- The SSL Root Certificates page
- The Email Settings page
- The Miscellaneous Settings page
- Other items under the Maintenance and Support Tools sections of the Admin page, including: Export & Download Database, View Application Log, Download All CloudBolt Logs, Download Web Server Logs, and the Django Database Browser
Normally, a user may request an API token (via the Authentication endpoint), which grants them access to use the API. If this permission is disabled on a user’s profile, they will be unable to request an API token and will therefore be unable to use the API.
This permission is only present if the CB_ADMIN_ENABLED setting is set to True in `customer_settings.py`. For most CloudBolt users, using the Super Admin global role provides sufficient granularity of administrator permissions, and CloudBolt Admin is not necessary.
The CloudBolt Admin role gives a user access to the CloudBolt Admin page which allows creating and editing of all CloudBolt objects including:
- resource handlers
This admin page also lets CloudBolt Admins make changes to email notification and other global settings.
CloudBolt Admins are also the only users allowed to create top-level groups in the group tree.
CloudBolt Admins are not automatically granted any permissions on groups, servers, or resources (they only have the right to administer CloudBolt itself).
Admin Capabilities for Passwords¶
The following are special password options that a CloudBolt Admin can perform, using the command line or Shell Plus.
Command Line Password Changes
PASSWORD_HISTSIZE: Password history tracking (to ensure that users cannot reuse “X” most recent passwords).
AUTH_PASSWORD_VALIDATORS: Set up password requirements such as length, special characters, etc. See Django password validation docs.
PASSWORD_EXPIRATION_HOURS: Set the amount of time in hours after which a password will expire and the user will need to create a new one.
PASSWORD_RESET_TIMEOUT_DAYS: Determines how long a password reset token is valid.
EMAIL_VERIFICATION_TIMEOUT_DAYS: Determines how many days a user has to use an email verification link before it expires. Default is 1 day.
Change CloudBolt Admin Password (Shell Plus) Ssh into your CB instance and run these commands:
first = User.objects.first() first.is_superuser = True first.set_password('your_new_password') first.save() exit
This will change your password to the text entered in the parentheses after first.set_password