Brinkster Cloud Orchestrator has a powerful and flexible inbuilt permissions system that allows you to manage users' access to resources comprehensively and with a high degree of flexibility. It does this by allowing different sets of finely grained permissions to be added to individual groups or users. Each user can belong to one or more groups and each group can have one or more sets of permissions, allowing you to build flexible permissions structures to suit your business requirements. Permissions can also be assigned to individual users in the same way as assigning permissions to a group. You can also assign permissions to resources. 

Overlapping Permissions

Brinkster Cloud Orchestrator has a hierarchical permissions system, which means you can set permissions on a resource which are inherited by resources within that resource. For example, adding the allow start/stop servers permission to a VDC means you don't need to add the allow start/stop servers permission for each server in the VDC individually.

If conflicts arise between permissions, the more specific permission is used. For example, if the deny create servers permission is set on a VDC, but the allow create servers permission is set on a customer with access to the VDC, the permission set on the VDC overrides that set on the customer, preventing users of the customer from creating servers in the VDC.

The hierarchy of the permissions system is as follows:

This means that if a permission is specified on a virtual resource within in a VDC, it overrides any permissions set on the VDC. If no specific permission is set on the resource or the VDC, a check is performed to see if there are permissions set at a higher level, for example on a group or customer.

Permission settings for groups

If users are members of multiple groups, only one set of group permissions are applied. For user created groups, if there is a permissions conflict the deny permission is applied. For example, User A is a member of Group 1 and Group 2. Group 1 has the allow attach/detach permission for disks, and Group 2 has the deny attach/detach permission for disks. Unless there are more specific permissions set on a VDC or virtual resource within the VDC, the deny attach/detach permission is applied, preventing User A from attaching or detaching disks.

For the default groups, the permissions of the Locked group override those of the Admin and Everyone groups, and the permissions of the Admin group override those of the Everyone group. 

Setting Permissions

Permissions are set using the following fields:

• Permission - Whether to allow or deny the user or group the ability to perform the action specified using the Capability drop down menu.
• Type - Whether the permission applies to a group, or an individual user.
• User/Group - The user or group to which the permission applies.
• Capability - The action that the user or group is specifically allowed or denied the ability to perform.
• Resource - The type of resource that the Capability pertains to, for example server, disk, or user.

Examples

Read only access

By default when a user is invited into a customer account they have read only access as they join the 'Everyone' Group, which as standard only has read only access. If required, you can either add the user to additional groups with higher access, or change the level of access for the everyone group; this latter course of action is however not advised.

Allowing a group of users to start and stop servers in a particular VDC, but not modify, create, or delete them

Let's say the Marketing team want to start and stop servers for a particular project that is confined to its own VDC, but you as the administrator don't want to allow Marketing access to change anything else in the VDC, as you have already configured it per company policies. To do this:

1. Create a new group called Marketing. For information on how to do this, see article on Creating a Group.
    
2. Add the required users into the Marketing Group. For information on how to do this, see the article on Managing a Group.
    
3. On the VDCs widget, manage the project's VDC by clicking the Manage button next to it. 
   
   
4. Add Allow Start/Stop permissions for all servers in the VDC. To do this:
   
   1. Click on the Permissions section.
   2. Specify the following:
      
      • Permission = Allow.
      • Type = Group.
      • Group = Marketing.
      • Capability = Start/Stop.
      • Resource = Server.
   3. Click the Add button. 

Allowing one of the users from the group above to have full access to the VDC

As time goes on you want to allow one of the Marketing team who is more technical to be able to provision new servers in the project VDC, from existing images that you have shared with them, but you don't want to allow everyone in Marketing to do this. To do this, manage the project's VDC and add the following permissions for the relevant user:

• Allow All permission for servers. 
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = All.
  • Resource = Server.
    
    
• Allow Create permission for NICs.
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = Create.
  • Resource = Nic.
    
    
• Allow Create permission for disks.
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = Create.
  • Resource = Disk.

Adding a NIC to a server

To create and add a new network interface to a server, the following permissions are required:

• Allow Create permission for NICs. This permission can be added to the server the NIC is to be added to, the VDC containing the server, or the network that the NIC allows the server to communicate with.
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = Create.
  • Resource = Nic.
     
• Allow Modify permission for servers. 
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = Modify.
  • Resource = Server.

This is because in some environments some organisations will segment the network and systems teams, so Brinkster Cloud Orchestrator allows finely grained separation of those permissions if required, although in general slightly wider permissions are normal, reflecting the tendency towards multi-faceted skill sets among staff.

Creating a disk and adding it to a server

To add a disk to a server, the following permissions are required:

• Allow Create permission for disks. This permission can be added to the VDC containing the server, or to the server itself.
  
  • Permission = Allow.
  • Type = User.
  • User = Required user.
  • Capability = Create.
  • Resource = Disk.

Allowing a group to start and stop all servers in a VDC apart from one

Brinkster Cloud Orchestrator has a hierarchical permissions system, which means you can set permissions on a resource which are inherited by resources within that resource. For example, adding the allow start/stop servers permission to a VDC means you don't need to add the allow start/stop servers permission for each server in the VDC individually. However, if a more specific permission contradicts a more general one, the more specific permission takes priority.

There may however be circumstances that require the explicit removal of permissions from certain resources which are affected by inherited permissions, for example allowing the Marketing group to start and stop all servers in a particular VDC apart from one. To do this:

1. On the Servers widget, manage the required server by clicking the Manage button next to it. 
   
   
2. Add Deny Start/Stop permissions for the required server. To do this:
   
   1. Click on the Permissions section.
   2. Specify the following:
      
      • Permission = Deny.
      • Type = Group.
      • Group = Marketing.
      • Capability = Start/Stop.
      • Resource = Server.
   3. Click the Add button.