Managing Pipeline Permissions for Multiple Pipeline Groups

[Jason Smyth]

Hi everyone,

We are working on upgrading from GoCD 19.8.0 to the current version. One of the major changes we need to account for is the default permissions on pipeline groups.

In 19.8.0, pipelines are open by default, i.e., if there are no permissions explicitly defined for a pipeline group, all users can view and operate the pipelines it contains. In current versions, pipelines are secure by default; if there are no permissions explicitly defined for a pipeline group then only system administrators can view/operate them.

Our current model is this:

• All pipelines are stored in a single config repo.
• Pipeline groups are used to represent an individual application.
• A pipeline group generally consists of a build pipeline and several deployment pipelines.
• Production pipelines are separated into their own pipeline group because they already have some requirements around restricting their operability.

This presents a couple of challenges:

1. When moving from open-by-default to secure-by-default we will need to explicitly specify the permissions for ~230 pipeline groups, all of which have essentially the same permissions requirements.
2. Post upgrade, we cannot restrict system administration privileges because anyone who has access to create a new pipeline group via the config repo will need sysadmin access to set the pipeline group permissions after the pipelines are imported.

Does GoCD have any mechanism for grouping pipeline groups for the purpose of standardizing permissions across them? Alternately, is there a way that we can define permissions in the config repo instead of having to put them into cruise-config.xml post-import?

Any thoughts or suggestions are welcome.

Regards,

Jason

[Aravind SV]

Tricky. Yes, there is no mechanism I'm aware of to set default permissions for new pipeline groups. :(

For the existing groups and your upcoming upgrade, I would suggest making the implicit permission explicit, by adding a role permission to the 230 pipeline groups, and then giving that role view and operate permissions.

Of course, there are still two issues:

1. How to make sure every user is in the role? [If you use the LDAP authorisation plugin, then you'd be able to set up a role which includes everyone in an AD group]

2. How to make sure every new pipeline group created has that default role [No great idea I can think of here, apart from having a script which uses the GoCD APIs to do that -- and only that -- and allowing everyone to run that. Maybe in a pipeline. :)]

Cheers,

Aravind

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/7a022c24-8d18-48dc-8909-2d6c5330e49bn%40googlegroups.com.

[Chad Wilson]

In a previous setup we used the GoCD APIs triggered by a simple scripted curl-oriented pipeline within GoCD itself, similar to how Aravind suggests. In that specific case the "synchronize group permissions" pipeline was manually triggered by an admin on request, but there would have been different ways to manage this (use PR to a special repo a trigger, PR has to be approved by a group of people whom may or may not be GoCD super-admins)

The pipeline could also be pre-configured with an admin's personal access token and then triggered on schedule (or commit to the config repos) to reconcile the current list of pipeline groups roles/permissions from a simple data structure in a repo; perhaps triggering every time a config repo is updated, and failing the pipeline if there is a group with no role assigned or something like that.

Perhaps you could then essentially source control the "get all pipeline groups" API response (or perhaps only the authorizations; or perhaps a cleaner YAML representation) from https://api.gocd.org/current/#get-all-pipeline-groups inside your config repo as a type of declarative "desired state". You could write some simple rules to avoid requests to assign inappropriate roles to pipeline groups if you wanted (e.g to avoid prod pipeline groups being accidentally granted operate permission to broad roles).

Essentially I guess the workflow depends on what type of control you want to give to any user who has access to a config repo, or whether you need to ensure there is some kind of review process, either mediated by only certain people being able to trigger the pipeline, or by approving code changes that feed that pipeline.

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CACxychHfBx35npprPKZwutE%3DbUWoB2U5WOVH37ygX3wGmyyftw%40mail.gmail.com.