Cloudify’s Approach to Resource Governance and Role-Based Access Control (RBAC)

One of the main tasks of an orchestrator is to provide its users balance between flexibility and control. The flexibility is required to manage a large variety of applications, services, and processes without forcing changes on them. The control is mandatory as the orchestrator lives in a complex environment where many components, and sometimes users, work together, each with different roles and permissions.
Ensuring this balance was one of our main goals in Cloudify’s latest versions, and with the recent release of Cloudify 4.3, we would like to present the four-layered approach of Cloudify’s governance feature set.

Check out our Application-Defined Governance white paper

Four layers of resource governance and role-based access control

Tenant and user management

The lowest level is resource separation – tenant and user management capabilities allow you to implement a multi-tenant solution in order to enable complete separation between your applications, represented in Cloudify as sets of blueprints, plugins, and secrets (or resources). You can then define which users have access to what tenants, giving you complete role-based access control over all of the various components in the organization.

User roles

The second layer is user-roles. Each of the five default options is based on commonly used permission sets for defining role-based access control to Cloudify resources in a tenant. These roles are:

• Tenant Manager
• Tenant User
• Tenant Operations
• Tenant Viewer
• System Administrator

The first four roles apply in the context of a tenant, so a user can have one role in one tenant and a different role in another tenant, as you can see in the below image.

Assigning a user to different tenants with different roles

The last role, System Administrator, gives the user full permissions to all of the manager’s tenants as well as the ability to perform management actions such as defining new users and tenants.
This layer allows more flexibility, as it support a finer-grained access control over different resources.

Resource visibility

The next layer up provides visibility control for the resources themselves. Upon uploading or creating a resource in a tenant in Cloudify Manager, its creator (as well as the sysadmin) can set its visibility level to one of the following:

• Private resource – visible to its creator, tenant managers, and system admins
• Tenant resource – visible to all users who are assigned to the tenant the resources exists in.
• Global resource – visible to all users who are assigned to at least one tenant on the manager. (This option requires sysadmin permissions)

Resources may also be changed from Private to Tenant or Global, or from Tenant to Global (but not the other way around due to sharing security issues that can arise).

Different resources can have different visibilities levels (Private, Tenant and Global, as represented in the icons above), defining who can see them.

The UI

The final piece to this puzzle is the user interface, called Cloudify Console, which adds another dimension to governance and role-based access control. Our graphical user interface is built as a framework of pages containing widgets. Each Widget exposes a specific set of data or functionality – for example blueprints, plugins, tenants and so on. The sets of pages presented to each user after logging into the manager depends on the user’s role in the specific tenant.
Cloudify provides several page templates out-of-the-box for each role, but users can create their own templates and therefore define what functionalities are presented based on how Cloudify is implemented in their organization. They can even add their own custom widgets or remove existing ones, as the user interface also remains loyal to our principles of being open source and having an open architecture.
Completing the previous layers which define what your end-users can do, the Cloudify Console framework gives you the flexibility to decide what they can see – you can personalize Console down to specific users – in order to create the most accurate dashboards to focus your team on the things that are most relevant to them within Cloudify.

Resource governance for your organization

Now that we are familiar with the four layers of Cloudify governance, we can define the process of designing the best resource management implementation based on our environment.
First, we need to understand which services or applications are going to be orchestrated, and the level of separation we want between them. This will then assist us in defining the number of Cloudify Tenants.
Second, we need to assign the users to the relevant tenants, according to the sets of permissions each of them should have in each tenant. That set of permissions will be represented by the roles we assign them.
Third, whenever we upload or create a resource to the manager we will first decide which tenant it is meant for (meaning, in what group of resources it belongs), and under which visibility level – by defining to whom it needs to be visible. The visibility options can be changed after the resource’s creation, but only to a higher level of visibility, so this step should be thought through in advance.

Setting the resource’s visibility level is possible, but only to a higher level.

And last but not least, we can edit and update the UI, Cloudify Console, to present only the widgets relevant for each user-role in each of the system’s tenants:

Creating custom page templates

With this powerful feature set, you can tailor Cloudify to your exact needs for tenant separation, user management, and resource access and control. Like everything else we do in Cloudify, our goal is to provide you with a strong and reliable framework that’s also flexible and dynamic, so you can create a solution that fits your organization’s needs best, and will be easily adjustable if your working scenario changes.