ViPR 2.1 - Assign Access Control List (ACL) to a resource using the ViPR REST API

Table of Contents

ACLs

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.

ACLs can be assigned to the following ViPR resources:
  • Block virtual pool
  • File virtual pool
  • Virtual arrays
  • Projects

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.

The EMC ViPR REST API Reference provides a description and complete list of parameters for the REST API methods used in this article.

Back to Top

Virtual array and virtual pool ACLs

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.

Back to Top

Examples: Virtual array and virtual pool ACL APIs

The examples in this section show some commonly-used APIs for managing virtual array and virtual pool ACLs.

Virtual array: Assigning the USE ACL to a tenant

The following example shows how to give a tenant privileges to use a virtual array. If no ACL exists on the virtual array, all tenants have access to it.

Request
PUT https://<ViPR_VIP>:4443/vdc/varrays/urn:storageos:VirtualArray:f49f6e36-0fe5-4181-9622-49d116204d86:vdc1/acl
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>

<acl_assignment_changes>
  <add>
    <privilege>USE</privilege>
    <tenant>urn:storageos:TenantOrg:7985d438-9980-41df-bba1-29d6a873f811:global</tenant>
  </add>
</acl_assignment_changes>

Response:

HTTP 200 OK
Content-Type: application/xml
<acl_assignments>
  <acl_assignment>
    <privilege>USE</privilege>
    <tenant>urn:storageos:TenantOrg:7985d438-9980-41df-bba1-29d6a873f811:global</tenant>
  </acl_assignment>
</acl_assignments>

Virtual array: Removing the USE ACL from a tenant

Request
PUT https://<ViPR_VIP>:4443/vdc/varrays/urn:storageos:VirtualArray:f49f6e36-0fe5-4181-9622-49d116204d86:vdc1/acl
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>

<acl_assignment_changes>
  <remove>
    <privilege>USE</privilege>
    <tenant>urn:storageos:TenantOrg:7985d438-9980-41df-bba1-29d6a873f811:global</tenant>
  </remove>
</acl_assignment_changes>

Response:

HTTP 200 OK
Content-Type: application/xml
<acl_assignments/>

Virtual pool: Assigning the USE ACL to a tenant

The following example shows how to give a tenant privileges to use a virtual pool. If no ACL exists on the virtual pool, all tenants have access to it.

Request

PUT https://<ViPR_VIP>:4443/file/vpools/urn:storageos:VirtualPool:4394653f-cf2e-4301-8f11-9e8d3e7e7fa9:vdc1/acl
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>

<acl_assignment_changes>
  <add>
    <privilege>USE</privilege>
    <tenant>urn:storageos:TenantOrg:d61d9fa1-9886-40ef-85d3-c40b6de2c72f:global</tenant>
  </add>
</acl_assignment_changes>

Response:

HTTP 200 OK
Content-Type: application/xml
<acl_assignments>
  <acl_assignment>
    <privilege>USE</privilege>
    <tenant>urn:storageos:TenantOrg:d61d9fa1-9886-40ef-85d3-c40b6de2c72f:global</tenant>
  </acl_assignment>
</acl_assignments>

Back to Top

Project ACLs

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.
Back to Top

Examples: Project ACL APIs

The examples in this section show some commonly-used APIs for managing project ACLs.

Get the ACLs for a project

Request
GET https://<ViPR_VIP>:4443/projects/{Project_URN}/acl
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>
Response
HTTP 200 OK
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<acl_assignments>
  <acl_assignment>
    <privilege>ALL</privilege>
    <subject_id>jordab@sanity.local</subject_id>
  </acl_assignment>
  <acl_assignment>
    <privilege>BACKUP</privilege>
    <subject_id>jordab2@sanity.local</subject_id>
  </acl_assignment>
</acl_assignments>

Assigning the USE ACL to a user

The following example sets the project ACL using a user's subject_id. A subject_id or group can be assigned the ALL or BACKUP permission.

Request

PUT https://<ViPR_VIP>:4443/projects/<project urn>/acl
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>

<acl_assignment_changes>
  <add>
    <privilege>ALL</privilege>
    <subject_id>jordab2@sanity.local</subject_id>
  </add>
</acl_assignment_changes>

Response

HTTP 200 OK
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<acl_assignments>
  <acl_assignment>
    <privilege>ALL</privilege>
    <subject_id>jordab@sanity.local</subject_id>
  </acl_assignment>
  <acl_assignment>
    <privilege>ALL</privilege>
    <privilege>BACKUP</privilege>
    <subject_id>jordab2@sanity.local</subject_id>
  </acl_assignment>
</acl_assignments>

Back to Top

Examples: Changing a project's owner

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 jordab@sanity.local is displayed as the project owner.
GET https://<ViPR_VIP>:4443/projects/{Project_urn}
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>
 
HTTP 200 OK
Content-Type: application/xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<project>
    <creation_time>1400267698359</creation_time>
    <global>true</global>
    <id>urn:storageos:Project:7581d618-e124-4c7f-9a04-624cad271ff2:global</id>
    <inactive>false</inactive>
    <internal>false</internal>
    <link rel="self" href="/projects/urn:storageos:Project:7581d618-e124-4c7f-9a04-624cad271ff2:global"/>
    <name>Snapshot Project</name>
    <tags/>
    <vdc>
        <id>urn:storageos:VirtualDataCenter:030618c2-c6b2-40b0-a105-6b669983f58f:vdc1</id>
        <link rel="self" href="/vdc/urn:storageos:VirtualDataCenter:030618c2-c6b2-40b0-a105-6b669983f58f:vdc1"/>
    </vdc>
    <owner>jordab@sanity.local</owner>
    <tenant>
        <id>urn:storageos:TenantOrg:2b5f6d7c-e670-4aee-9fc1-ddbf0fc8de22:global</id>
        <link rel="self" href="/tenants/urn:storageos:TenantOrg:2b5f6d7c-e670-4aee-9fc1-ddbf0fc8de22:global"/>
    </tenant>
</project>

Changing the owner of a project

This example changes the ownership of the project shown in the previous example to jordab2@sanity.local. Note that this is done by changing the owner attribute of the project, rather than through an ACL call.

Request
PUT https://<ViPR_VIP>:4443/projects/{Project_URN}
Content-Type: application/xml
X-SDS-AUTH-TOKEN: <AUTH_TOKEN>

<project_update>
  <owner>jordab2@sanity.local</owner>
</project_update>
Response
HTTP 200 OK
Content-Type: application/xml

Back to Top