Roles and permissions
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.
- 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.
centralConfiguration/deploy-permission-service.yamlfile to define the Permission service’s database configuration if you want to have the Permissions data stored in a separate database:
- 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.
- Create a new file,
centralConfiguration/deploy-permission-service.yaml, and add the following Permissions service’s configuration properties to the
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
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
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 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 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 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:
||All rights within Deploy.|
||The right to execute control tasks on configuration items.|
||The right to perform discovery of middleware.|
||The right to log into the Deploy application. This permission does not automatically allow the user access to nodes in the repository.|
||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.|
||The right to administer principals, roles, and permissions.|
||The right to view user management information.|
||The right to assign a task to another user.|
||This permission has no effect.|
||The right to inspect scripts that will be executed for steps in an execution plan.|
||The right to skip a step in an execution plan.|
||The right to assign a task to yourself.|
||The right to view all the tasks. With this permission, you can view but not modify other tasks in the system.|
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#initialpermission to view all tasks of the type
deploy#undeploypermission to view all tasks of the type
deploy#upgradepermission to view all tasks of the type
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.
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:
||The right to execute control tasks on configuration items.||Applications, Environments, Infrastructure, and Configuration|
||The right to generate the contents of a directory as a Groovy file.||Applications, Environments, Infrastructure, and Configuration|
||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|
||The right to undeploy an application from an environment.||Environments|
||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|
||The right to import a package for an application that does not exist in the repository.||Applications|
||The right to remove an application or package.||Applications|
||The right to import a package for an application that already exists in the repository.||Applications|
||The right to see CIs in the repository.||Applications, Environments, Infrastructure, and Configuration|
||This right will give read only permission.||Applications, Environments, Infrastructure, and Configuration|
||The right to create and modify CIs in the repository.||Applications, Environments, Infrastructure, and Configuration|
||This permission has no effect.||Environments|
||The right to skip a step in an execution plan.||Environments|
||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.