Policy
A policy is a set of permissions for GoCD entities such as environments, configuration repositories, etc. The policy defines the access of a GoCD entity for the users in a role. GoCD supports a restrictive model of access i.e. until access is granted, the entity can’t be accessed by anyone (except admins).
A permission consists of 3 values:
1. Type : The type of GoCD entity. Supported values are environment, config_repo, cluster_profile, elastic_agent_profile. Wildcard(*) is also permitted which means all supported values.
2. Action : The action which is controlled. Supported values are view and administer
3. Resource : The resource can be the name of entity or a pattern consisting of wildcard (*) matching one or more entities and can optionally be namespaced within parent entity using : separator.
Currently, GoCD has 2 types of permissions:
* Allow: The allow permission grants access to the specified entity for the specific action.
* Deny: The deny permission restricts the access to the specified entity for the specific action.
Note: If both the permission are specified for the same entity, the
denypermission takes precendence.
Privilege-Action Matrix
Each GoCD entity has a set of actions which grants/restricts control on a granular level. The following matrix describes the same.
Environment
- API
| Index| Get| Create| Update| Patch| Delete
---|---|---|---|---|---|---
View| ✔| ✔| ✘| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔| ✔| ✔ - UI
| List| Create| Update| Delete
---|---|---|---|---
View| ✔| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔
Config Repo
- API
| Index| Get| Create| Update| Delete
---|---|---|---|---|---
View| ✔| ✔| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔| ✔ - UI
| List| Create| Refresh| Update| Delete
---|---|---|---|---|---
View| ✔| ✘| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔| ✔
Elastic Agent Configuration
GoCD supports dynamic provisioning of agents using Elastic Agents. To Configure an elastic agent in GoCD, a user is required to configure Cluster Profiles and Elastic Agent Profiles.
In most cases, a single GoCD instance is being utilized by multiple teams. Each team can have their own build environments e.g. development, staging, production, etc. Where each build environment is mapped to a cluster profile. And the type and the configurations of the agent is specified as an elastic agent profile.
As Cluster Profiles and Elastic Agent Profiles are inter-dependent, a specific permission policy can be specified to provide granular access as per teams.
Basic Permissions
Cluster Profile
- API
| Index| Get| Create| Update| Delete
---|---|---|---|---|---
View| ✔| ✔| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔| ✔ - UI
| List| Create| Update| Delete| Cluster Status Report
---|---|---|---|---|---
View| ✔| ✘| ✘| ✘| ✔
Administer| ✔| ✔| ✔| ✔| ✔
Elastic Agent Profile
- API
| Index| Get| Create| Update| Delete
---|---|---|---|---|---
View| ✔| ✔| ✘| ✘| ✘
Administer| ✔| ✔| ✔| ✔| ✔ - UI
| List| Create| Update| Delete| Agent Status Report| Elastic Profiles Usage
---|---|---|---|---|---|---
View| ✔| ✘| ✘| ✘| ✔| ✔
Administer| ✔| ✔| ✔| ✔| ✔| ✔
Implicit Permission
- Any permission on the Cluster profile is implicitly applied to all the Elastic Agent Profiles of the same cluster.
Example :
1.
2.
3.
4.
5.Bob
6.
7.
8.frontend_team_uat_cluster
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
In the give role, The userBobhas given administrative access on thefrontend_team_uat_clustercluster. With implicit permissions, the userBobis allowed to administerfrontend_team_uat_clustercluster profile andnode6-agent,node8-agentelastic agent profiles. - Any permission on the Elastic Agent profile provides the view permission to the associated Cluster Profile.
Example :
1.
2.
3.
4.
5.Bob
6.
7.
8.node6-agent
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
In the give role, The userBobhas given administrative access on thenode6-agentelastic agent profile. With implicit permissions, the userBobis allowed to administernode6-agentelastic agent profile and is also able to viewfrontend_team_uat_clustercluster profile.
Namespaced Permission
In a distributed teams setup, along with granting permissions to create GoCD entities, we often want to restrict users from performing certain operations. Within namespaced resource permissions we can restrict user permissions to a particular entity.
Namespaced resource permissions can be specified using colon (:) separator. Example: parent_entity:child_entity. This would enforce the given user has access to operate on child_entity only within parent_entity.
While creating elastic agent configurations we often to restrict users to to their team’s cluster profiles and elastic profiles. Following is the example which demonstrates permission restrictions using namespaced resource as per teams.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
In the given example:
1. As part of role frontend_team, the user Bob has given administrative access on all the Elastic agent profiles which refers to the frontend_* cluster profile(s).
2. As part of role backend_team, the user John has given administrative access on all the Elastic agent profiles which refers to the backend_* cluster profile(s).
3. As part of role devops_team, the user Admin has given administrative access on all the Elastic agent profiles. This can also be achieved specifying * as resource.
Configure policy
- Login into your GoCD server.
- Go to Admin menu → Role Configuration.

- Click on
Addbutton.

- Enter a unique name for role configuration.
- Click on
Add Permissionbutton.

- Select permission as
Allow, type asEnvironment, action asView. Enterresourcevalue as*. This will grant view permission for all environments to the users which has this role.

- Click on
Savebutton.
Once the role has been created, go ahead and add users to the same. The access to the GoCD entities for these users will governed as per permissions configured.
