BuildMaster Documentation

Security and Access Controls

  • Last Modified: 2019-04-24

BuildMaster Free Edition

As of BuildMaster v6.0, BuildMaster Free edition only supports two types of authorization controls:

  • Every authenticated user in the system is authorized to perform any function, effectively making every authenticated user a System Administrator
  • All unauthenticated users have "view-only" access to the system (see Specific Guest Account Tasks for complete list of granted task attributes)

Prior to v6.0, the Enterprise Edition rules below still apply.

Enterprise Edition

Users and Group add a level of granular control and security within BuildMaster. By associating users with a group or groups, organization are able to permit and restrict access as needed.

A user directory is a collection of users and groups that BuildMaster can query. Currently, BuildMaster supports three types of user directories:

  • Built-In - The default basic user account system used by new installs of BuildMaster.
  • LDAP/Single Domain AD - Users and groups from an LDAP directory are used, such as an Active Directory domain.
  • AD Domain Forest - Users and groups from multiple domains in an Active Directory forest are used.

Directories are exclusive; meaning you can only use one at a time. For this reason, it's important to make sure you will have sufficient administer permissions in BuildMaster for the user directory you are switching to. If you do accidentally lock yourself out, don't worry; you can easily run the BuildMaster.Service.exe program, and select the reset to Built-In option.


BuildMaster allows you to create and customizes as many tasks as needed. Tasks in BuildMaster define the specific ability, access, and functions users or group are allowed to edit, create, and view. BuildMaster comes built-in with five tasks out of the box: Administer, Coordinate Releases, Deploy to Environment, Manage Application, and View Application. Built-in task can be edited and modified but it's important to note that future updates may affect these built-In tasks.

Creating a Task in BuildMaster

Administrators can assign restrictions and permissions based on a group and individual users. It's important to note that permissions are additive and restrictions override permission when they're at the same level; the more specific personnel (One user vs. Group) or a more defined scope (production vs. all environments) always override.

For Example

Tasks may be scoped at the environment and/or application level. In the example below, Karl is a member of the DevTeam and is the only user who has the permission to deploy to the Production environment for the Accounts application. The Accounts application is likely a mission critical app and therefore the enterprise has added strict restrictions, with only Karl given the permission for deployment in the Production environment.

Permission and restrictions per User

Everyone in the Release managers group are able to Coordinate Releases and Manage application because permission are additive and the scope is set at system wide level.

API Access & API Keys

API Keys are designed to grant access to other tools and integrations. You can control which functionality a key may be used for, and delete keys that are not used.

Granting access to the Native API will effectively allow for full control of the instance

API Keys in BuildMaster

To assist with debugging API usage, the request/response is logged whenever an API endpoint is accessed with a key. These logs are not retained indefinitely, but are automatically purged.

An API key may be passed to an endpoint in one of four ways, depending on the content type of the expected request:

  • Request header (X-ApiKey) - all content types
  • Querystring value (key) - all content types
  • Form value (key) - only application/x-www-form-urlencoded content type
  • JSON property (API_Key) on root object - only application/json content type

Preventing Deployment to Restricted Servers

Because a deployment plan can reference a server by name, users who have permission to edit a deployment plan could easily reference a restricted server (such as production), thus defeating any deployment restriction policies. To prevent this, you can elect to "restrict deployments" to that server.

To enable this feature, you must go to All Settings and enable server restrictions. It will then make a checkbox available on all servers to restrict deployments.

At runtime, when a restricted server is requested, if the server is not associated with the targeted environment (or, if no environment was specified on the pipeline target), then a runtime error will occur. This allows you to grant a wide array of permissions while keeping narrow restrictions, such as:

  • permission to edit plans, pipelines, and deploy
  • restriction to deploy to production

This can be unexpected and frustrating behavior, and we generally don't recommend it except for when there's a need for restricted servers.

More on this topic:

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.