Assign scopes

You can assign a scope to one or more entities to restrict access, share resources, or to create a hierarchy, as described here.

To restrict administrator access to resources, assign a scope to the administrator's user account:

The administrator can manage the locations (datacenters and public cloud regions) that are in their scope (e.g. add templates). An administrator can manage enterprises and users of the enterprises that are in their scope.
Troubleshooting and Tips
- The user must also have the other required permissions (privileges and allowed datacenters).
- A user can work in allowed datacenters (e.g. create virtual datacenters, deploy), even if the datacenters are not in their scope.

Click here to expand...

For example, a Managed Service Provider in Spain, with datacenters in Madrid, Barcelona, Valencia, and Seville. The scopes could be defined as follows:

User scope for datacenters:
- An administrator for "Spain" with a scope to access to all the Spanish datacenters
- An administrator for "Eastern Spain" with a scope to access Barcelona and Valencia (on the east coast of Spain)
User scopes for enterprises:
- An administrator for Spain may have a scope to access the top-level "Spanish HQ" to manage its users and resources. This scope may be the parent of one or more scopes to group users for management and resource sharing

To share resources (templates, VApp specs) to users of other enterprises, assign one or more scopes to the resource:

The scopes contain the enterprises that can access the resource
- The user can also select child scopes to share resources to their users

The users of the enterprises listed in the scopes can access the resource, if they have the other required permissions

Troubleshooting and Tips

If there is a hierarchy, administrators can share VM templates and VApp specs with users in scopes beneath their own scope
Administrators cannot manage the enterprises that are not directly in their user scope
You can assign a user's scope to resources to share the resources with the enterprises in the scope. The platform will only consider the enterprises in the scope, not the locations
The platform will only check if a user's enterprise is in a resource's scope. It will not consider the user's scope to determine if they can access a resource
Examples of other access limitations:
- To modify VM templates, the administrator must be in the enterprise that created the template
- To create a new version of a VApp spec, the user must work with a VApp created from the spec in the enterprise that created the spec

To create a reseller hierarchy for billing, pricing, and management and aggregation of costs and usage, assign a scope to an enterprise as its default scope:

The parent scopes of each scope define the hierarchy levels
Each scope can have one reseller and/or one key node

The resellers and key nodes define the hierarchy for management and aggregation. Administrators can share VM templates and VApp specs with users in scopes beneath their own scope.

Scope hierarchy: The administrator for Spain could also have a scope hierarchy beneath the Spain scope that includes the scopes for Eastern Spain and Central and Southern Spain and then their customers at a lower level. The administrator for Spain can only manage the users of the Spanish national organization but they can share templates and Vapp specs with tenants in the scopes at all levels of the hierarchy.
Reseller: A reseller enterprise in the hierarchy can use partner or reseller credentials for public cloud and manage billing and pricing for their hierarchy.
Key node: A key node enterprise can obtain aggregate billing and usage data for their hierarchy
Scope hierarchy diagram:
Click here to show/hide the diagram