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.
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 user name 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 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|
||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|
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.