13. Permissions

• Overview
  • Owner property
    • How to change an owner
  • Admin role
• Permission settings
  • Permissions granted to a user

Overview

Security Policies Scheme is organized by 2 principal tools: groups (user groups and system roles) and Access Control List defined for each CP's object.
Note: About groups and system roles you can read more here.
Object's Access Control List specifies who can work with the object and what he can do with it. It is defined as a pair of attributes:

• a User or User Group ID
• Permissions

The permission settings are divided into the following options which can be combined for the object:

• Read
• Write
• Execute

Below is a mapping of the objects' possible actions to permissions which demonstrates what actions will be allowed or denied to a user or user group.
Note: according to Security Policies Scheme WRITE permission is not enough to add/delete any Cloud Pipeline object. A specific *_MANAGER role is required also (about roles see here).

Object	User Action	Permission
Folder	View folder	Read
	List folder contents
	Create object (e.g folder, pipeline, etc.)	Write
	Delete folder
	Rename folder
	Change parent
	Upload metadata
Pipeline *Permissions for a pipeline version are inherited from the pipeline	View pipeline	Read
	List pipeline attributes
	Delete a pipeline	Write
	Edit pipeline attributes
	Change parent
	Run a pipeline	Execute
DataStorage *Permissions for files in data storage are inherited from the data storage	View datastorage	Read
	List datastorage contents
	Delete a datastorage	Write
	Edit datastorage attributes/contents
	Change parent
Pipeline run	View runs	Inherited from a run pipeline
	View run logs
	Launch a pipeline
	Stop a run
	Rerun
Tool run	View runs	Admin and Owner only
	View run logs
	Launch a pipeline
	Stop a run
	Rerun
Cluster node	View a cluster	Inherited from a currently assigned run
	View node details
	Terminate a node
Docker Registry	View registry	Read
	Add registry	Write
	Delete registry
	Edit registry attributes
	Run a child tool	Execute
Tool group	View tool group	Read
	Create tool group	Write
	Edit tool group
	Delete tool group
	Run a child tool	Execute
Tool	View enabled tool	Read
	View disabled tools list
	Edit tool attributes	Write
	Run tool without a pipeline	Execute
	Instance management	Admin and Owner only
Run configuration	View run configuration	Read
	Delete a run configuration	Write
	Edit run configuration attributes
	Change parent
	Run a run configuration	Execute

Note: also you can manage permissions on the Cloud Pipeline objects via CLI. See 14.7. View and manage Permissions via CLI.

Owner property

Each object has an additional "Owner" property. The owner of the object can manage its Access Control List. Owner property is assigned to a user that created an object.

How to change an owner

The Owner of an object can be changed easily for:

• Folders;
• Pipelines and pipelines versions;
• Data storages;
• Run configurations;
• Docker registries, Tool Groups and Tools.

Note: you shall have Owner or Admin role.

To change an owner of an object:

1. Select an object.
2. Click "Gear" icon in the top-right corner of the screen.
   
3. Navigate to Permissions tab.
   Note: To edit permissions:
   • for a Folder - click the "Gear" icon → Edit folder
   • for a Docker registry - click the "Gear" icon → Registry → Edit.
   • for a Tool group - click the "Gear" icon → Group → Edit
   • for a Tool - click the "Gear" icon → Permissions.
4. Click owner's name. Now you can edit it:
   
5. Start to enter a desired username and system will suggest you the existing users.
   
   Click the desired username.
6. Click "Apply" control and the changes will be saved.
   

Also you can change an owner of an object via pipe CLI - see here.

Admin role

Admin property can be given by assigning ROLE_ADMIN to a user (about roles see here). The user gets Read/Write/Execute/Owner permissions to all objects in the system.
Initially, a user with ROLE_ADMIN shall be an authenticated domain account (SAML/OAuth/OpenID) defined during a system deployment (in some properties file or database).

Storage reader role

Read-only access to all data storages can be given by assigning ROLE_STORAGE_READER to a user. The user gets READ permission to every data storage in the Platform - even if the storage permission settings deny READ to that user or to their groups - and so is able to browse storages, download their data (via GUI or pipe CLI), view storage attributes and tags, and view the storage permission settings.

The role grants nothing but READ:

• WRITE, EXECUTE and OWNER permissions are still resolved from the storage permission settings - so if the user was granted WRITE to some storage, they keep it
• listing of object versions is not covered by the role - it still requires the OWNER permission to the storage
• archived objects are not covered by the role either - they still require the OWNER permission to the storage or one of the ROLE_STORAGE_ARCHIVE_MANAGER/ROLE_STORAGE_ARCHIVE_READER roles (see Storage lifecycle). As these roles take effect wherever the user has READ, a user having both ROLE_STORAGE_READER and ROLE_STORAGE_ARCHIVE_READER is able to view archived objects of every storage
• the global search results are not extended by the role - they still include only the storages the user has READ permission to by the storage permission settings
• the mount command inside a run is not allowed by the role - it is still available only for the users with the ROLE_ADMIN or ROLE_STORAGE_ADMIN role
• the runs, launched by the user, mount all the storages of the Platform - as for the users with the ROLE_STORAGE_ADMIN role - but in a read-only mode. A storage is mounted with the write access only if the user was granted WRITE to it and nothing else makes it read-only (e.g. a read-only mode of the storage quota or a sensitive run)

Pipeline reader and executor roles

Access to all pipelines can be given by assigning one or both of the following roles to a user. Both roles cover every pipeline in the Platform, versioned storages included:

• ROLE_PIPELINE_READER - the user gets READ permission to every pipeline - even if the pipeline permission settings deny READ to that user or to their groups. So the user is able to see all pipelines in the Library, browse their versions, code, documents and settings, view pipeline attributes and the pipeline permission settings.
  The user is also able to view all runs of all pipelines - the run details and logs, and the cluster nodes of these runs - including the runs of other users. This does not depend on the run visibility policy: neither the launch.run.visibility system preference (see 12.10. Manage system-level settings) nor the visibility setting of a pipeline restricts it.
• ROLE_PIPELINE_EXECUTOR - the user gets EXECUTE permission to every pipeline - even if the pipeline permission settings deny EXECUTE to that user or to their groups.

The roles are meant to be used together: a user with both roles is able to see and launch every pipeline. A pipeline launch requires both READ and EXECUTE permissions to the pipeline, while ROLE_PIPELINE_EXECUTOR gives only EXECUTE. So a user having only this role does not see the pipelines, and is able to launch only the ones the user was granted READ to in the pipeline permission settings.

The roles grant nothing but the permissions listed above:

• WRITE and OWNER permissions are still resolved from the pipeline permission settings - so if the user was granted WRITE to some pipeline, they keep it
• a pipeline launch still requires EXECUTE permission to the Docker image of the pipeline - it is not given by the roles
• the EXECUTE permission given by ROLE_PIPELINE_EXECUTOR is not passed on to the runs of the pipelines. Pausing, resuming, sharing or other changes of the runs of other users still require the permissions the user would need without the role - e.g. EXECUTE granted to the user in the pipeline permission settings
• the runs of other users are available to a user with ROLE_PIPELINE_READER for viewing only: SSH and the run endpoints are still available only if the run is shared with the user
• copying of a pipeline is not allowed by ROLE_PIPELINE_READER - it still requires READ permission to the pipeline by the pipeline permission settings. A copy of a pipeline, which repository is not hosted in the Platform GitLab, keeps working with the original repository, while the user who copies it becomes the owner of the copy
• detached configurations are not covered by the roles. A detached configuration, that includes a pipeline, still requires EXECUTE permission to the configuration itself
• the global search results are not extended by the roles - they still include only the pipelines the user has READ permission to by the pipeline permission settings

Permission settings

The permissions could be granted to a user in one of the following ways:

• the system has a "default" system role or user group. This type of system roles or groups assigned by default once a user is created;
• assigned user groups or system role where every member has the same permissions for specific objects;
• granted permissions for specific user.

The priority of permissions granted for specific object explicitly is higher than the group or role permissions, e.g. if a basic user is included into the group that doesn't have an access to some folder but he has permissions explicitly defined for himself that allow him to work with that folder, he will have an access to it.
To assign object's permissions to a user or user group you shall move to the object's page and click the "Gear" icon in the top-right corner of the screen and select "Permissions" tab.

Note: To edit permissions:

• for a Folder - click the "Gear" icon → Edit folder
• for a Docker registry - click the "Gear" icon → Registry → Edit.
• for a Tool group - click the "Gear" icon → Group → Edit
• for a Tool - click the "Gear" icon → Permissions.

You can explicitly define permissions for the object for a particular user or group of users (users within the same Group) in the "Permission" form by clicking on its name in the "Groups and users" list.
Note: if you couldn't find the desired user or user group, you can add it via "Add a user" and "Add a user group" controls (see the picture below, 1).

The additional section for a particular user or user group suggests you tick the desired grants. Here you can allow or deny specific permission options (see the picture above, 2).
Note: if you don't tick any possible variant, it will be inherited from the parent object (e.g. a pipeline in a folder inherits permissions from it) (see the picture above, 3).

Example 1: according to the picture above, a user will get WRITE and EXECUTE permissions for an object, and the READ permission will be inherited from the parent object.

Example 2: on the picture below we see Permission form of a run configuration. We grant a user READ and EXECUTE permissions, but deny WRITE permission. So the user is able to see the run configuration and run it, but he can not edit its parameters:

Permissions granted to a user

The "Permissions" form shows all users and groups granted permissions to a single object. The opposite view - permissions granted to a single user on all objects of a type - is available via the API method GET /permissions/user?userId=<user ID>&aclClass=<object type>. Supported object types are DATA_STORAGE and PIPELINE.

For each object, the method returns the object and the permission entries that concern the user - the ones set for the user itself, for one of the user's groups or for one of the user's roles. Each entry combines the permissions set on the object with the ones set on its parent folders: the permissions not set on the object are taken from the closest parent folder they are set on. So an entry may differ from the one shown in the "Permissions" form of the object, and an object may be returned only because of the permissions set on its parent folder. Each entry keeps both the allowed and the denied permissions. Objects without such entries are not included.

The method is available to admins, to the users with the ROLE_USER_ADMIN or ROLE_USER_READER role, and to the users that have READ permission to the specified user. Admins get the objects of all the Platform, other users - only the objects they have READ permission to themselves.

Note: the method returns only the permissions set in the permission settings of the objects. It does not show the access the user gets by ownership or by a role that gives access regardless of the permission settings (e.g. ROLE_ADMIN, ROLE_STORAGE_ADMIN, ROLE_STORAGE_READER, ROLE_PIPELINE_READER and ROLE_PIPELINE_EXECUTOR), nor the access limited by a storage quota or by the mount status of an NFS storage. So, a user may have access to an object that is missing in the result, or less access than the returned entries grant.

More about Cloud Pipeline API see here.