Security and RBAC

This page describes the security and role-based access control system in QMCLOUD.

QMCLOUD components are secured using an RBAC (Role based access control) system. The RBAC system consists of users, roles, permissions, and scope.


All users (also referred to as an identity) accessing QMCLOUD are required to be defined as part of the RBAC system. A user can belong to one or more Organization(s). A user object requires additional attributes to be defined including username, email address, password, address details, the associated organization and security roles.


A Role is a set of permissions assigned to a user object. A role can assign permissions using sets to the following objects – ORGANIZAITON, USERS, WORKSAPCE, STACKS, and ROLES.


Permissions are a combination of one or more of the following actions - GET, CREATE, UPDATE and DELETE. Each of these permissions are associated with an action in Q-Cloud.

For example:

For a user who is assigned a role that allows CREATE permissions, can CREATE various objects including users, roles, workspace, organization, and stacks.


A scope defines the organization boundary of the permission sets. Scope can be either LOCAL or GLOBAL.

A local scope explicitly defines a single organization where the permission applies. This organization is defined at the user level.

A global scope applies to all organizations defined in Q-Cloud.

Example RBAC system:

The following diagram depicts the RBAC system components and their relationships. There are two fictious organizations shown – namely - ACME and TOYSR.

Diagram - RBAC components and their relationship

A fictious user John Doe is assigned the “Admin” role and is assigned to both the organization. The scope of the admin role is defined as GLOBAL. Based on this definition of the role, John has admin access with all the permissions to both the organizations.

A fictious user Mary Joe is assigned “TOYSR-Admin” role. The scope of this ‘TOYSR-Admin” role is defined as LOCAL. Mary is assigned to the TOYSR organization with the “TOYSR-Admin” role. In this case, Mary is limited to administering the TOYSR organization and does not have any access to the ACME organization.

Last updated