Roles

Overview

A role is a set of permissions. Regular accounts obtain feature, host and deploy permissions through their roles; administrator accounts (created with -s or marked as super administrator) are never restricted. When the permissions of a role change, its members are forced to log in again so that the change takes effect.

Feature permissions

Control which pages and buttons the role can use, organized as module / sub-module / operation:

Module	Sub-modules and operations
Dashboard	view dashboard
Hosts	hosts: view / new / edit / delete; web terminal: web terminal, file management, upload files, delete files
Batch Execution	run task; templates: view / new / edit / delete; file distribution
Deployment	applications: view / new / edit / delete / view config; build repository: view / new version / run build / delete; deploy requests: view / new / edit / delete / review / deploy
Pipelines	view / new / edit / delete / run
Scheduled Tasks	view / new / edit / delete
Config Center	environments: view / edit / delete; services and applications: view / new / edit / delete / view config / edit config
Monitoring	view / new / edit / delete
Alerts	records: view; contacts and groups: view / new / edit / delete

Note

Feature permissions only affect pages and buttons. The System menu (login log, credentials, accounts, roles, settings) is administrator only. Deploy permissions for applications are granted separately, see below.

Host permissions

Granted per host group; hosts in the selected groups (and their sub-groups) are visible to the role. Host permissions are global and apply to host management, the web terminal, batch execution, file distribution, deploy configurations, pipelines, scheduled tasks, monitoring and every other place that selects hosts. Regular users without any group see no hosts on these pages.

Deploy permissions

Granted per environment and per application; both must be set. The role can deploy to the selected environments and operate the selected applications (deploy configurations, build repository and deploy requests). The creator of an application automatically has deploy permission for it.

Members

Members in the list shows how many and which accounts belong to the role. The assignment is done under Accounts; an account can have several roles.

Best practices

• Create roles per responsibility, for example Developer (test deploys), Ops (all environments) and Read-only audit, and assign accounts to roles instead of granting permissions individually.
• Give review and deploy permissions to different roles to get a four-eyes release process.
• Group hosts by environment or business line so that developers never see production hosts.