An Access Control List (ACL) is a list of permissions attached to a
ViPR resource that specifies which tenants are authorized to access that resource as well as what operations are allowed on that resource.
This article applies to EMC ViPR 2.0.
ACLs can be assigned to the following
Block virtual pool
File virtual pool
For each virtual array, virtual pool, or project resource, there is a limit of 100 ACLs. Therefore, there is a maximum of 100 user/group assignments for projects and 100 tenant assignments for a virtual array or virtual pool.
Assigning an ACL to a resource is one means of setting up which users and groups are authorized to access
ViPR functionality .
Assigning roles to users and groups is another method.
At creation time, virtual arrays and virtual pools are public. They are accessible to all tenants.
A System or Security Administrator can assign an ACL to a virtual pool or virtual array to restrict them to be used by specified tenants.
The ACL permission associated with virtual arrays and pools is of the type USE. If a specific tenant has a USE ACL on a virtual pool, this means that all the users who are mapped to that tenant will be allowed to use that virtual pool in their provisioning operations.
All newly created virtual arrays and pools will have an empty ACL. The System or Security Administrator is responsible for managing the ACL. If no ACLs are set, the virtual arrays and pools remain accessible to the provider tenant and all other tenants in the ViPR system.
For virtual pools and virtual arrays, you cannot assign an ACL to a user (subject ID) or group. Only tenants can be assigned ACLs for these resources.
The following table shows the APIs that allow a system or security administrator to modify ACLs for virtual arrays and virtual pools. Note that there are separate API calls for file and block virtual pools.
A Tenant Administrator can access all projects for their tenant. Project Administrators can only access projects that they own.
Newly created projects will have an empty ACL.
The project ACLs can be created or modified by a Tenant Administrator, a Security Administrator, or a project owner. Project owners are assigned the OWN ACL. The user that creates the project is the owner of that project unless they, or a tenant administrator, transfers ownership of that project to another user.
The default ACL behavior of a project is different from the default ACL behavior of a Virtual Array or Virtual Pool. Whereas, the default ACL for a Virtual Array or Virtual Pool enables anyone to use them, the default ACL for the Project prevents all but the Tenant Admin or Project owner from using it (for example, to create a volume in the project). For other users or groups to use a project, that user or group must be explicitly added to the ACL for that project.
The ACL permissions associated with projects are listed in the following table.
The example in this section shows how to change the owner of a project.
The OWN ACL is assigned to a project's creator, giving that user ownership rights to that project. A tenant admin, a project admin or the project's owner can reassign the ownership of the project to another user.
Checking the owner of a project
The user that owns the project is displayed in the <owner> field of the project resource. Here, the user firstname.lastname@example.org is displayed as the project owner.
This example changes the ownership of the project shown in the previous example to email@example.com. Note that this is done by changing the owner attribute of the project, rather than through an ACL call.