Managing ACL Rules 3.0

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 core then can grant permission, or reject the request.

This allows administrators to tailor the user roles according to their infrastructure needs. For instance, using ACL rules you could create a group of users that can see 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 your cloud. Some examples are provided at the end of this guide.

inlinetoc

Understanding ACL Rules

Lets start with an example: 

#5 IMAGE+NET/@103 INFO+MANAGE+DELETE

This rule grants the user with ID 5 the right to perform INFO, MANAGE and DELETE operations over all Images and VNets in the group with id 103.

The rule is split in three components: User, Resources, Rights. The ID definition for User or Resources in a rule is written as:

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

The three components are separated by a space.

  • User component is composed only by an ID definition.
  • Resources is composed by a list of '+' separated resource types, '/' and an ID definition.
  • Rights is a list of Operations separated by the '+' character.

Some more examples:

This rule allows all users in group 105 to create new virtual resources: 

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

The next one allows all users to use the Virtual Network 47. That means that they can instantiate VM templates that use this network. 

* NET/#47 USE

:!: Note the difference between: 

"* NET/#47 USE"    vs    "* NET/@47 USE"

“All Users can use NETWORK with ID 47” vs “All Users can use NETWORKS beloging to the Group whose ID is 47”

Managing ACL Rules via Console

The ACL rules are managed using the oneacl command. The 'oneacl list' output looks like this:

<xterm> $ oneacl list 

 ID     USER RES_VHNIUTG   RID OPE_CDUMIPpTWY
  0       @1     V-NI-T-     *     C-----p---
  1       @1     -H-----     *     --U-------
  2       #5     --NI-T-  @104     --U-I--T--
  3        *     ---I---   #31     --U-I-----

</xterm>

The four rules shown correspond to the following ones: 

@1  VM+NET+IMAGE+TEMPLATE/*  CREATE+INFO_POOL_MINE
@1  HOST/*                   USE
#5  NET+IMAGE+TEMPLATE/@104  USE+INFO+INSTANTIATE
*   IMAGE/#31                USE+INFO

The first two were created on bootstrap by OpenNebula, and the last two were created using oneacl:

<xterm> $ oneacl create “#5 NET+IMAGE+TEMPLATE/@104 USE+INFO+INSTANTIATE” ID: 2

$ oneacl create “* IMAGE/#31 USE+INFO” ID: 3 </xterm>

The ID column identifies each rule's ID. This ID is needed to delete rules, using 'oneacl delete <id>'.

Next column is USER, which can be an individual user (#) or group (@) id; or all (*) users.

The Resources column lists the existing Resource types initials. Each rule fills the initials of the resource types it applies to.

  • V : VM
  • H : HOST
  • N : NET
  • I : IMAGE
  • U : USER
  • T : TEMPLATE
  • G : GROUP

RID stands for Resource ID, it can be an individual object (#) or group (@) id; or all (*) objects.

The last Operations column lists the allowed operations initials.

  • C : CREATE
  • D : DELETE
  • U : USE
  • M : MANAGE
  • I : INFO
  • P : INFO_POOL
  • p : INFO_POOL_MINE
  • T : INSTANTIATE
  • W : CHOWN
  • Y : DEPLOY

Managing ACLs via Sunstone

Sunstone ACL plugin offers a very intuitive and easy way of managing ACLs.

Select ACLs in the left-side menu to access a view of the current ACLs defined in OpenNebula:

This view is designed to easily undestand what the purpose of each ACL is. You can create new ACLs by clicking on the New button at the top. A dialog will pop up:

In the creation dialog you can easily define the resouces affected by the rule and the permissions that are granted upon them.

How Permission is Granted or Denied

:!: Visit the XML-RPC API reference documentation for a complete list of the permissions needed by each OpenNebula command.

For the internal Authorization in OpenNebula, there are a series of implicit rules that apply before the ACL rules are checked:

  • The oneadmin user, or users in the oneadmin group are authorized to perform any operation.
  • The owner of a resource can DELETE, USE, MANAGE, INFO and INSTANTIATE it.
  • Any user can perform USE, INSTANTIATE or INFO over a NET, IMAGE or TEMPLATE; if the object is public and belongs to the same group as the user.
  • Users can MANAGE their own USER object, to change their password.

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 his group. Consider the following example: if a user #7 is in the group @108, with the following existing rule: 

@108 IMAGE/#45 INFO+DELETE

Then the following rule won't have any effect: 

#7 IMAGE/#45 INFO

Use Case

Let's say you have a work group where the users should be able to deploy VM instances of a predefined set of VM Templates. You also need two users that will administer those resources.

The first thing to do is create a new group, and check the automatically created ACL rules: <xterm> $ onegroup create restricted ID: 100 ACL_ID: 2 ACL_ID: 3

$ oneacl list 

 ID     USER RES_VHNIUTG   RID OPE_CDUMIPpTWY
  0       @1     V-NI-T-     *     C-----p---
  1       @1     -H-----     *     --U-------
  2     @100     V-NI-T-     *     C-----p---
  3     @100     -H-----     *     --U-------

</xterm>

The rule #2 allows all users in this group to create new resources, and list the existing ones. We want users to be able to see only existing VM Templates and VM instances in their group:

<xterm> $ oneacl delete 2

$ oneacl create “@100 VM+TEMPLATE/* INFO_POOL_MINE” ID: 4

$ oneacl list 

 ID     USER RES_VHNIUTG   RID OPE_CDUMIPpTWY
  0       @1     V-NI-T-     *     C-----p---
  1       @1     -H-----     *     --U-------
  3     @100     -H-----     *     --U-------
  4     @100     V----T-     *     ------p---

</xterm>

And now we can authorize users #1 and #2 to perform any operation on the group resources. Note that we left out:

  • INFO_POOL_MINE because it is already allowed by the ACL rule #4.
  • INFO_POOL because it allows to list all the resources in OpenNebula, and we don't want them to know anything outside their group.
  • And CHOWN, because it would allow them to set any user in the system as owner of the objects in their group.

<xterm> $ oneacl create “#1 VM+NET+IMAGE+TEMPLATE/* CREATE+DELETE+USE+MANAGE+INFO+INSTANTIATE” ID: 5

$ oneacl create “#2 VM+NET+IMAGE+TEMPLATE/* CREATE+DELETE+USE+MANAGE+INFO+INSTANTIATE” ID: 6

$ oneacl list 

 ID     USER RES_VHNIUTG   RID OPE_CDUMIPpTWY
  0       @1     V-NI-T-     *     C-----p---
  1       @1     -H-----     *     --U-------
  3     @100     -H-----     *     --U-------
  4     @100     V----T-     *     ------p---
  5       #1     V-NI-T-     *     CDUMI--T--
  6       #2     V-NI-T-     *     CDUMI--T--

</xterm>

With this configuration, users #1 and #2 will manage all the resources in the group 'restricted'. Because of the implicit rules, the rest of the users can use any VM Template that they create and publish. In practice, this means that regular users in the 'restricted' group will be able only to execute 'onetemplate list/show/instantiate' and 'onevm list/show'.