Roles and permissions

This topic explains the roles and permissions in Deploy.

Deploy includes a fine-grained access control scheme to ensure the security of your middleware and deployments. The security scheme is based on the concepts of principals, roles, and permissions.

Permission schema

• The Digital.ai Deploy's Permission service—by default—runs as embedded service in the Digital.ai Deploy server.

• One of the best practices is to run the Permission service with its own, separate, database schema in order to separate the connection pools from the Deploy's database schema.

• Use the centralConfiguration/deploy-permission-service.yaml file to define the Permission service's database configuration if you want to have the Permissions data stored in a separate database:

  1. Similar to preparing the databases for Deploy's operational database and reporting database, create an empty database for the Permission service, a database user and password: Keep the following Permission service's database information handy:
  • database URL (includes the database name)
  • database username
  • database password
  • database driver classname

  Note: In case you don't want to separate the schema for the Permission service, the default schema for the Permission service would be the same as the operational database and all related tables are created there. 2. Create a new file, centralConfiguration/deploy-permission-service.yaml, and add the following Permissions service's configuration properties to the centralConfiguration/deploy-permission-service.yaml file.

  Note: PostgreSQL values in the following YAML code snippet is used for illustrative purposes only. Use the right values for the database you use.

  xl:
    permission-service:
      database:
        db-driver-classname: org.postgresql.Driver
        db-password: demo
        db-url: jdbc:postgresql://localhost:5433/permissionservice
        db-username: postgres
  • Where, permissionservice in db-url—jdbc:postgresql://localhost:5433/permissionservice—is the name of the Permission service's database.
  • During the instantiation or upgrade process all permission service data will be migrated to the new database schema.

At any time you can re-initialize the Permission schema data in 10.3 or later by using the force-clean-upgrade property. This property is set in centralConfiguration/deploy-permission-service.yaml file and can be used for Permission service migration.

xl:
  permission-service:
    force-clean-upgrade: true

Important: Remove the force-clean-upgrade: true property from the centralConfiguration/deploy-permission-service.yaml file as soon as you complete the installation process as it is required only for migrating the Permissions data, which you would not want to happen every time you restart the Deploy server.

Note: There is no separate Docker image available for installing the Permissions microservice on a standalone server (BETA in 10.3).

For more information, see Permission microservice

Principals

A security principal is an entity that can be authenticated in Deploy. Out of the box, Deploy only supports users as principals; users are authenticated by means of a username and password. When using an LDAP repository, users and groups in LDAP are also treated as principals. For more information about using LDAP, refer to How to connect to your LDAP or Active Directory.

Deploy includes a built-in user called admin. This user is granted all global and local permissions.

note

In Deploy, user principals are not case-sensitive.

Roles

Roles are groups of principals that have specific permissions in Deploy. Roles are typically identified by a name that indicates the role the principals have within the organization; for example, deployers. In Deploy, permissions can only be granted to, or revoked from, a role.

When permissions are granted, all principals that have the role are allowed to perform some action or access repository entities. You can also revoke granted permissions to prevent the action in the future.

Permissions

Permissions are rights in Deploy. Permissions control the actions a user can execute in Deploy, as well as which parts of the repository the user can see and change. Deploy supports global and local permissions.

Global permissions

Global permissions apply to Deploy and all of its repository. In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission.

Deploy supports the following global permissions:

Permission	Description
admin	All rights within Deploy.
controltask#execute	The right to execute control tasks on configuration items.
discovery	The right to perform discovery of middleware.
login	The right to log into the Deploy application. This permission does not automatically allow the user access to nodes in the repository.
report#view	The right to see all reports. When granted, the UI will show the Reports tab. To be able to view the full details of an archived task, a user needs read permissions on both the environment and application.
security#edit	The right to administer principals, roles, and permissions.
security#view	The right to view user management information.
task#assign	The right to assign a task to another user.
task#move_step	This permission has no effect.
task#preview_step	The right to inspect scripts that will be executed for steps in an execution plan.
task#skip_step	The right to skip a step in an execution plan.
task#takeover	The right to assign a task to yourself.
task#view	The right to view all the tasks. With this permission, you can view but not modify other tasks in the system.

important

The task#view permission depends on the local permissions that apply to environments. To view tasks that are assigned to other users, you must have the read permission on the environment where the task was created. You must also have local environment permissions such as:

• deploy#initial permission to view all tasks of the type Initial
• deploy#undeploy permission to view all tasks of the type Undeploy
• deploy#upgrade permission to view all tasks of the type Upgrade

caution

The security#edit permission lets you manage user accounts (including Admin user accounts) and roles in Deploy. Exercise caution while assigning this permission to non-admin roles as users assigned with a role that has the security#edit permission can edit other Admin user accounts and roles too.

Local permissions

In Deploy, you can set local security permissions on repository nodes (such as Applications or Environments) and on directories in the repository. In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission.

Deploy supports the following local permissions:

Permission	Description	Applies to...
controltask#execute	The right to execute control tasks on configuration items.	Applications, Environments, Infrastructure, and Configuration
generate#dsl	The right to generate the contents of a directory as a Groovy file.	Applications, Environments, Infrastructure, and Configuration
deploy#initial	The right to perform the specification, delta analysis, orchestration, and planning (but not execution) phases of the initial deployment of an application to an environment. See Deployment Phases for more information.	Environments
deploy#undeploy	The right to undeploy an application from an environment.	Environments
deploy#upgrade	The right to perform an update deployment phases up to the planning phase(not including the execution phase) of an application to an environment. Note that this permission does not allow the user to deploy deployables in the package to new targets. See Deployment Phases for more information.	Environments
import#initial	The right to import a package for an application that does not exist in the repository.	Applications
import#remove	The right to remove an application or package.	Applications
import#upgrade	The right to import a package for an application that already exists in the repository.	Applications
read	The right to see CIs in the repository.	Applications, Environments, Infrastructure, and Configuration
deploy_admin_read_only	This right will give read only permission.	Applications, Environments, Infrastructure, and Configuration
repo#edit	The right to create and modify CIs in the repository.	Applications, Environments, Infrastructure, and Configuration
task#move_step	This permission has no effect.	Environments
task#skip_step	The right to skip a step in an execution plan.	Environments
task#takeover	The right to assign a task to yourself.	Environments

How local permissions work in the hierarchy

In the hierarchy of the Deploy repository, the permissions configured on a lower level of the hierarchy overwrite all permissions from a higher level. There is no inheritance from higher levels; that is, Deploy does not combine settings from various directories. If there are no permissions set on a directory, the permission settings from the parent are taken recursively. This means that, if you have a deep hierarchy of nested directories and you do not set any permissions on them, Deploy will take the permissions set on the root node.

All directories higher up in a hierarchy must provide read permission for the roles defined in the lowest directory. Otherwise, the permissions themselves cannot be read. This scheme is analogous to file permissions on Unix directories.

For example, if you have read permission on the Environments root node, you will have read permissions on the directories and environments contained within that node. If the Environments/production directory has its own permissions set, then your access to the Environments/production/PROD-1 environment depends on the permissions set on the Environments/production directory CI itself.

In cases where there is a local version and a global version of a permission, the global permission takes precedence over the local permission at all levels of the hierarchy.

Note: Starting with Deploy 10.3, the security.grant () CLI method and PUT /security/permission/{permission}/{role}/{id:.*} API have been updated. These methods no longer override the permissions of a child directory if the new permission is the same as the one it has inherited from the parent. For instance, consider two directories: Environments/parent-dir and Environments/parent-dir/child-dir. If parent-dir has read permission for a role called test-role, child-dir inherits the same permissions. If you try to set the same read permission for test-role to the child-dir directory using the API call curl -k -u admin:admin "http://localhost:4516/deployit/security/permission/read/test-role/Environments/parent-dir/child-dir" -X PUT or using the security.grant("read", "test-role", ['Environments/parent-dir/child-dir']) method, it will not make any changes to the permissions or disable the Inherited from parent flag for the child directory. To override permissions on the child-dir directory, you must grant a permission that is not inherited from the parent-dir directory.