Access Control Lists

Overview

Access Control Lists (ACLs) allow you to modify/view permissions for an API resource. Resources are identified using a unique ID and corresponding resource name. Not all resources are supported by the ACL function. See the ACL-Managed Resources section below for the list of supported resources.

Any user with administration permissions (perms) on a resource can view/modify the ACL for that resource using the ACL Management APIs APIs:

  • View ACL Resource Details
  • Update ACL Resource Details

ACL-Managed Resources

The following table identifies the resources that are supported by the ACL function along with the corresponding pages that provide additional information for the resource. This information is identical to the resourceName attribute used by the Workload Manager APIs.

EnumerationDescription
POLICY

See Policy Management > Scaling Policies or Aging Policies

ACTION_POLICY

See Policy Management > Action Policies

DEPLOYMENT_ENVIRONMENT See Deployment Environment
APPLICATION

See Application Profile

  • Model an Application
  • Model an Application by Importing the Profile
REPOSITORYSee Share Artifact Repositories
CLOUD_ACCOUNT See Configure Cloud(s)
SYSTEM_TAGSee System Tags
SECURITY_PROFILESee Security and Firewall Rules
SERVICESee Manage Services
CUSTOM_ACTIONSee Policies > Custom Actions 
PROJECTSee Projects
IMAGESee Manage Images

DISTRIBUTED_JOB

See Deployment Environments > Sharing Deployments
EXTENSION See Extensions
ACI_EXTENSIONSee ACI Extensions
SERVICE_NOW_EXTENSIONSee ServiceNow Extensions (Effective CloudCenter Legacy 4.8.2)
ACTION See Actions Library (Effective CloudCenter Legacy 4.8)
VIRTUAL_MACHINESee VM Management (Effective CloudCenter Legacy 4.8)
AGING_POLICYSee Policies (Effective CloudCenter Legacy 4.8.2)
SUSPENSION_POLICY

Default Permissions for ACL Resources

Permissions are tightly controlled by Workload Manager and not all permissions are applicable to all resources. You will receive validation errors in the following cases:

  • When you apply a permission that is not applicable to a particular resource.

    For example, move_in and move_out are only applicable to deployment environments. If you apply either of these two strings to any other resource, you will receive a validation error.

  • When you apply a random string that is not listed in the perms array. For example, if you assign your own permission value like readwrite, you will receive a validation error.

  • Imported VMs do not have any default permissions.

ACL Manage Permissions

As this information is identical to the perms attribute used by the Workload Manager APIs, the same information is included here.

resourceName Permissions →

Enumeration ↓

read
write
create
delete
administration
executemove_in
move_out
access
approve
authorize
managenotify

POLICY

YesYes


ACTION_POLICY

Yes



PUBLISHED_APP

Yes



DEPLOYMENT_ENVIRONMENT 

YesYesYesYes

APPLICATION

Yes

Yes




REPOSITORY

Yes



CLOUD_ACCOUNT 

Yes



SYSTEM_TAG

Yes



SECURITY_PROFILE

Yes



SERVICE

Yes



CUSTOM_ACTION

Yes

Yes
PROJECTYes


Yes
IMAGEYes



MANAGE_EXPORTYesYes


MANAGE_IMPORTYesYes


Permission Categories

Permissions are divided into the categories that the following table describes:

Permission Category
(id and perms)
Description
Users
  • Users can be a tenant admin, promoted admin, co-admin, root admin, or a standard user.
  • Each user is identified by the User ID, and permissions are granted to the User ID for the specified resource.
  • Set the perms array with the specific permissions (enumerations) to be provided for this user.
User Groups
  • A collection of one or more users. If a group consists of 10 users, all 10 users will be assigned permissions based on the group permissions.
  • Each group is identified by the Group ID, and permissions are granted to the Group ID for the specified resource.
  • If you add future users, the added users receives the same permission that the other 10 users already have by virtue of being a member of this group. If you delete a user from this group, the deleted user no longer has permissions for this group.

Tenant Users

  • All users belonging to this tenant will be assigned permission.
  • Each tenant is identified by the Tenant ID, and permissions are granted to the Tenant ID for the specified resource.

Tenant & Sub-Tenants

  • Extends tenant level permissions to all sub-tenants at any level below (down the hierarchy) this tenant-level and all users within each of those sub-tenants as well.
  • Each tenant is identified by the Tenant ID, and permissions are granted to the Tenant ID for the specified resource.

Default ACL Resource Permissions

The following default permissions are automatically granted to ACL resources after each resource is created. 

  • User permissions are granted to the user who created the resource.

  • Tenant permissions are granted to:

    • All users of the tenant to which the logged-in user belongs.

    • All users in sub-tenant hierarchy starting at tenant of the user who created the resource.


If not specified for Vendor and Tenant then default permissions are not available at that level.

The following table describes ACL resource permissions.

PermissionsUserVendorTenant
POLICY
  • read
  • write
  • create
  • delete
  • administration
  • execute


ACTION_POLICY
  • read
  • write
  • create
  • delete
  • administration


PUBLISHED_APP
  • read
  • write
  • create
  • delete
  • administration
READ
DEPLOYMENT_ENVIRONMENT
  • read
  • write
  • create
  • delete
  • administration
  • execute
  • move_in
  • move_out
  • approve
  • authorize
  • manage


APPLICATION
  • read
  • write
  • create
  • delete
  • administration
  • execute


REPOSITORY
  • read
  • write
  • create
  • delete
  • administration


CLOUD_ACCOUNT
  • read
  • write
  • create
  • delete
  • administration


SYSTEM_TAG
  • read
  • write
  • create
  • delete
  • administration
READ
SECURITY_PROFILE
  • read
  • write
  • create
  • delete
  • administration
READ
SERVICE
  • read
  • write
  • create
  • delete
  • administration
READREAD
CUSTOM_ACTION
  • read
  • write
  • create
  • delete
  • administration


PROJECT
  • read
  • write
  • create
  • delete
  • administration
  • notify


IMAGE
  • read
  • write
  • create
  • delete
  • administration


NODE_STATUS_DEFINITION
  • read
  • write
  • create
  • delete
  • administration
  • execute



UI and API Differences

ACL Configuration differences between the UI and API:

  • UI – If you have a complicated hierarchy with multiple permission combinations in a tenant hierarchy, then the UI only displays permission for the current level. Permissions for parent and child tenants will not be visible to the logged in user.

  • API – API users can view or modify permissions for all levels, regardless of this user's level in the tenant hierarchy. Only prerequisite is that the logged in user has administration perms on this resource.

If you are the tenant owner, you can provide any permission to the sub-tenant organization and all its users at the same time.

UI Configuration

When providing access to Tenant and Sub-Tenant users, access the Share popup for the required service (Workload Manager UI > Admin > Services > MyService > Share dropdown), click the Tenants tab in the popup, and check the My Tenants & Sub-Tenants check box to provide access to the entire hierarchy.

You also have the option to select just one tenant (if you want to give just one tenant, but not their sub-tenants, and provide access to just that tenant.

  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved