Granular Access Controls in CloudStack [feedly]

----
Granular Access Controls in CloudStack
// CloudStack Consultancy & CloudStack...

An oft-cited limitation in Apache CloudStack is the lack of granular access controls.  Historically, when creating an account, there have been four built-in roles to choose from: Root Admin, Resource Admin, Domain Admin, and User.  Unfortunately, these built-in roles have been insufficient for the needs of many organizations, who have resorted to various workarounds.  Thankfully, this will change in the upcoming CloudStack 4.9 release with the addition of the Dynamic Role-Based API Access Checker feature.

With CloudStack versions prior to 4.9, the main workaround to modify access controls is to edit a configuration file on the management server.  This can work for some situations, but it really is not ideal because changes to the file do not replicate to other management servers and new roles cannot be created.  In the past there was some work done toward implementing an Identity Access and Management feature, however this was unfortunately never completed.  The idea behind the new Dynamic Role-Based API Access Checker feature is to build on and improve the existing functionality.  The old properties file has been eliminated and the functionality moved to the database.  Crucially, new roles can now be created.  And finally, the configuration is now entirely handled by new API commands.

The workflow to use the feature is straightforward.  The administrator needs to create a new role, create permission rules for the role, and lastly create an account using the role.  This can be done with the new API commands for Roles and RolePermissions, which will be noted in the API documentation and can currently be found in the design document for the feature.  Or, it can be done through the UI, which has a new Roles tab.

In this tab a new role can be added with the Add Role button, and by selecting a role the permission rules can be edited.  The rules themselves can allow or deny specific API commands or multiple commands using a wildcard.  The built-in roles are there, too, but cannot be deleted.  This is the Rules page for the Root Admin:

This new feature opens up a lot of possibilities.  One common request is read-only roles for use by monitoring systems, auditors, or IT security teams, for example.  This can be done by creating a new role and creating rules allowing the required APIs or denying unnecessary APIs, or some combination thereof.  Something like this:

Another possibility is a backup operator or administrator.  Such a role might be similar to the above read-only role but additionally be granted access to all snapshot APIs, thus allowing someone to create or delete snapshots for backup purposes.  Besides roles focused on cloud administration, user-oriented roles can be created.  For example, consider the template upload capability offered by CloudStack.  While useful in general, this is not always desirable, perhaps due to potential licensing issues.  With the new feature, administrators can now easily prevent certain end-users from uploading their own templates, forcing them to deploy VMs using only templates uploaded by the administrator.

This new feature clearly eliminates many common pain points in CloudStack.  While it is not a complete RBAC implementation, it is a very welcome addition.  Further work will be done in future releases to add functionality and improve the access control capabilities of CloudStack.

----

Shared via my feedly newsfeed

Sent from my iPhone