Granular Authorization for different entities such as Environments, Config-Repos, Pipeline Groups etc.

Task Checklist

• Introduce XSLT migration to support defining policy in cruise-config.xml
• Restrict policy definition only for environments.
• Use view only policy permissions to grant a user access to environments.
• Bump up roles config API to support policy definition.
• Document Roles config API
• Allow Roles Config SPA to define policy per role.
• Show Admin tab with Environment Subtab on UI when a user has permission to view the environment.
• Allow users to access environments SPA with read-only permissions to environments.
• Policy evaluation when dealing with multiple roles. See this, this and this
• Allow policy definition for config repos.
• Document policy tag under GoCD Configuration Reference
• Document Granular auth feature on docs.gocd.org similar to pipeline as code
• (Optional) Write a blog post demonstrating granular auth feature with environments.

Issue Description

Initial discussions and conversations are documented here: https://github.com/gocd/gocd/issues/4735

Current Issues:

Today most of the global entities pipeline_group, template, SCM, package-repo, config-repo, environment, elastic agent profile, artifact store can be configured only by System Admins. In an enterprise setup with multiple teams using the same instance of GoCD, System Admins can have an annoying experience if they have to step in for things like,

1. Creating pipeline_groups
2. Creating environments

Suggested approach: Allow auth policies to be defined for roles configured in GoCD.

Policy to be inlined at a Role level

<role name="config-repo-admins">
    <policy>
        <allow action="administer" type="configRepo">*</allow>
    </policy>
    <users>
        <user>foo</user>
        <user>bar</user>
    </users>
</role>

With the above policy all users belonging to the role config-repo-admins will be able to create, view, edit and delete any ConfigRepo.

<role name="config-repo-editors">
    <policy>
        <allow action="edit" type="configRepo">*</allow>
    </policy>
    <users>
        <user>foo</user>
        <user>bar</user>
    </users>
</role>

With the above policy, all users belonging to the role config-repo-editors will be able to view and edit/update any ConfigRepo.

<role name="config-repo-viewers">
    <policy>
        <allow action="view" type="configRepo">*</allow>
    </policy>
    <users>
        <user>foo</user>
        <user>bar</user>
    </users>
</role>

With the above policy, all users belonging to the role config-repo-viewers will be able to view any ConfigRepo.

Who can define these policies?

GoCD System admins can define policies for a Role. Policies will define how the users in the role can access a GoCD entity.

Types of policy

GoCD will have two types of policy for now -

Allow

The policy will allow the access of the current entity based on configured type, action and resource

<allow type="environment" action="view">resource_identifier</allow>

Deny

The policy will deny the access of the current entity based on configured type, action and resource policy syntax

<deny type="environment" action="edit">resource_identifier</deny>

	Description	Example
type	The attribute represents the type of GoCD config entity.	wildcard * or pipeline_group, environment, template, agent, etc…
action	The attribute represents that what type of action is allowed on the current entity.	wildcard * or Action such as administer, edit, view
resource_identifier	A resource name or pattern.	wildcard(* or ?) in it pipeline_test, environment_prod or a pattern like envrionment_*

• action and type can have a wildcard(*) but it will not support pattern matching e.g. ref*

Note: type and action can be extended later on need basis to different entity types.

** Current Possible actions and there implementation

a.) Administer: This gives CRUD permissions for a resource matching the regex pattern or * matching the entity type

b.) Edit: This allows for Read and update of a resource matching the regex pattern or * of certain entity type

c.) View: This allows for a read of a resource matching the regex pattern or * of a certain entity type.

** Minimum set of permissions to allow to create and edit an environment

Create environment starting with dev_test: Admin permission on the environment for resource identifier dev_*

<role name="env_admins">
    <policy>
    <allow action="administer" type="environments">dev_*</allow>
    </policy>
    <users>
        <user>cr_admin1<user>
        <user>cr_admin1<user>
    </users>
</role>

** How does system administrator allow administration for two separate teams

Let us assume there are two teams, Platform Team A and Platform Team B. A GoCD system administrator is asked to create roles Environment Admins for both teams. The roles can be configured as

<role name="env_admins_team_A">
    <policy>
    <allow action="administer" type="environments">pt_env_a_*</allow>
    </policy>
    <users>
        <user>suraj<user>
        <user>rahul<user>
    </users>
</role>

<role name="env_admins_team_B">
    <policy>
    <allow action="administer" type="environments">pt_env_a_*</allow>
    </policy>
    <users>
        <user>sulekha<user>
        <user>raj<user>
    </users>
</role>

** Assumption: The teams follow a naming convention for environments

Policy evaluation

The policy for an entity is denied by default. This would mean the entity would either be only accessible by GoCD system admins (as is the case today) or in some cases like pipeline-group continue to honor existing authorization rules (this may change as we come to implementation of policies for Pipeline Groups).

The policy will be resolved from top to bottom.

## Example 1
<role name="environment-admins">
    <policy>
        <deny action="view" type="environments">*</deny>
        <allow action="view" type="environments">dev_*</allow> 
    </policy>
    <users>
        <user>foo</user>
    </users>
</role>

In the above example users in the role, environment-admins will be denied access to view all environments.

## Example 2
<role name="environment-admins">
    <policy>
        <allow action="view" type="environments">dev_*</allow>
        <deny action="view" type="environments">*</deny> 
    </policy>
    <users>
        <user>foo</user>
    </users>
</role>

In the above example users in the role, environment-admins will be able to view environments matching pattern dev_*.

Multiple Roles

What happens if a user belongs to more than one role?

For e.g

<role name="config-repo-admins-01">
    <policy>
        <allow action="view" type="configRepo">*</allow>
    </policy>
    <users>
        <user>foo</user>
        <user>bar</user>
    </users>
</role>

<role name="config-repo-admins-02">
    <policy>
        <deny action="view" type="configRepo">abc_*</allow>
    </policy>
    <users>
        <user>foo</user>
    </users>
</role>

For user “foo” what should we consider?

We are currently thinking of a restrictive model wherein in the above example, the user foo will not be able to view any config-repos which match the pattern abc_*

[GaneshSPatil]

@adityasood @kritika-singh3 – should we close this issue as the granular-auth implementation for environments and config-repo has been implemented in GoCD release v19.11.0 and v19.12.0 respectively?

We can create separate individual issues for granular auth support for other GoCD entities and link it to this issue.

[rajiesh]

Closing this as granular auth implemented for Environment and Config Repository. New issues to be created when add more entities into granular auth