Skip to content

Managing ACL rules

The ACL authorization system enables fine-tuning of the allowed operations for any user, or group of users. Each operation generates an authorization request that is checked against the registered set of ACL rules. The authorization core can then grant permission, or reject the request.

This allows administrators to tailor the user roles according to their infrastructure needs. For instance, with the use of ACL rules, a group of users can be created with permissions to view and use existing virtual resources, but not create any new ones; or, grant permissions to a specific user to manage Virtual Networks for some of the existing groups, but not to perform any other operation in the cloud fabric.

Some examples are provided at the end of this guide.

Managing ACL rules is an advanced mechanism. For most use cases, you should be able to rely on the built-in resource permissions and the ACL Rules created automatically when a group is created, and when physical resources are added to a VDC.

Understanding ACL Rules

An example of an ACL rule string:

Example

#5 IMAGE+TEMPLATE/@103 USE+MANAGE #0

This rule grants the user with ID 5 the right to perform USE and MANAGE operations over all Images and Templates in the group with ID 103.

The rule is split in to four components, separated by a space:

  • User is comprised of only by an ID definition.
  • Resources is comprised of by a list of ‘+’ separated resource types, a ‘/’ and an ID definition.
  • Rights is a list of operations separated by the ‘+’ character.
  • Zone is an ID definition of the zones where the rule applies. This last part is optional, and can be ignored unless HyperCloud is configured in a federation.

ID definition syntax

Users

For a User in a rule, the ID definition is written as:

  • #<id> : for individual IDs
  • @<id> : for a group ID
  • * : for All

Resources

For a Resource, a % symbol is used before the ID numeral.

  • %<id> : for cluster IDs

A couple of examples:

Example 1

This rule allows all Users in Group 105 to create new virtual resources.

@105 VM+NET+IMAGE+TEMPLATE/* CREATE

Example 2

This rule allows all Users in Group 106 to use Virtual Network 47, meaning they can instantiate VM templates that use this network.

@106 NET/#47 USE

Note

The difference between * NET/#47 USE and * NET/@47 USE

All Users can use NETWORK with ID 47 vs All Users can use NETWORKS belonging to the Group ID 47.

The following rule allows Users in Group 106 to deploy VMs in Hosts assigned to the Cluster 100.

@106 HOST/%100 MANAGE

Managing ACL rules via Console

The ACL rules are managed using the hypercloud acl command. The hypercloud acl list output looks like this:

SoftIron:HCLegacy\dashboard> hypercloud acl list
  ID     USER RES_VHNIUTGDCOZSvRMAPt   RID OPE_UMAC  ZONE
   3       @1     -H----------------     *     -m--    #0
   4       @1     --N---------------     *     u---    #0
   5       @1     -------D----------     *     u---    #0
   0       @1     V--I-T---O-S----P-     *     ---c     *
   1        *     ----------Z-------     *     u---     *
   2        *     --------------MA--     *     u---     *
  • The ID column identifies each rule's ID. This ID is needed to delete rules, using hypercloud acl delete <id>.
  • The USER column identifies which Users are referenced by the rule: individual (#), group (@), or ALL users (*).
  • The Resources column lists the existing Resource types initials. Each rule fills the initials of the resource types it applies to.
  • The RID (Resource ID) column can be an individual object (#), group (@), or cluster (%) ID; or ALL (*) objects.
  • The Operations column lists all the allowed operations initials.
  • The Zone column shows the zone(s) where the rule applies. It can be an individual zone ID (#), or ALL (*) zones.
Key Resource Key Resource
V VM O DOCUMENT
H HOST Z ZONE
N NET S SECGROUP
I IMAGE v VDC
U USER R VROUTER
T TEMPLATE M MARKETPLACE
G GROUP A MARKETPLACEAPP
D DATASTORE P VMGROUP
C CLUSTER t VNTEMPLATE
Key Operation
U USE
M MANAGE
A ADMIN
C CREATE

How permission is granted or denied

For the internal Authorization in HyperCloud, there is an implicit rule:

  • The oneadmin group is authorized to perform any operation.

If the resource type is VM, NET, IMAGE, TEMPLATE, or DOCUMENT the object's permissions will be keyed accordingly:

PERMISSIONS                                                                     
OWNER                    : um-                 
GROUP                    : ---                 
OTHER                    : ---

The output above shows that the owner of the object has USE and MANAGE rights.

If none of the above conditions are true, then the set of ACL rules is iterated until one of the rules allows the operation.

An important concept about the ACL set is that each rule adds new permissions, and they can’t restrict existing ones.

If any rule grants permission, the operation is allowed.

This is important because you have to be aware of the rules that apply to a user and its group. Consider the following example:

If a user #7 is in the group @108, with the following existing rule:

@108 IMAGE/#45 USE+MANAGE

Then the following rule won’t have any effect:

#7 IMAGE/#45 USE

Special authorization for Virtual Network Reservations

There is a special sub-type of Virtual Network: reservations. For these Virtual Networks, the ACL system makes the following exceptions:

  • ACL rules that apply to ALL (*) are ignored.
  • ACL rules that apply to a cluster (%) are ignored.

The other ACL rules are enforced: individual (#) and Group (@). The Virtual Network object's permissions are also enforced as usual.