Re: [go-cd] Managing Pipeline Permissions for Multiple Pipeline Groups

[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

On Sun, Jun 2, 2024 at 8:43 PM Aravind SV  wrote:

> 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
>
> On Fri, 31 May 2024 at 21:51, Jason Smyth  wrote:
>
>> 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
>>
>> --
>> 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+unsubscr...@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
>> 

Re: [go-cd] Managing Pipeline Permissions for Multiple Pipeline Groups

[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

On Fri, 31 May 2024 at 21:51, Jason Smyth  wrote:

> 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
>
> --
> 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+unsubscr...@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
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CACxychHfBx35npprPKZwutE%3DbUWoB2U5WOVH37ygX3wGmyyftw%40mail.gmail.com.

Re: [go-cd] Assign Administrator Permissions to Role Without Manually Modifying cruise-config.xml

[Aravind SV]

Hello!

Yes, what Chad says makes sense to me.


I don't recall discussing a UI for the  tag though. There is an
API, if that helps you,  Jason:
https://api.gocd.org/current/#update-system-admins

Cheers,
Aravind


On Sat, 1 Jun 2024 at 10:21, Chad Wilson  wrote:

> Interesting, had not noticed that limitation (didn't know you could assign
> a role to super-admin at all!). Personally I don't know a UI-driven way.
>
> Looks like it was vaguely discussed as part of
> https://github.com/gocd/gocd/issues/3712 but I cannot see that
> possibility to map that within the Role Management page, nor a specific
> open issue/feature request for that.
>
> I believe there were a number of aspects of more granular auth for global
> entities  that wasn't
> necessarily completed, but I think this work was intended to reduce the
> need for super-admins in general. Keep in mind this work was mainly
> happening in H2 2019 and Thoughtworks announced closure of studios for end
> 2020 on Nov 18 2019. I believe the focus went to open sourcing pieces in H1
> 2020 so this possibly never got to its full vision :-).
>
> Having said that, from your other post it appears you are on a very old
> GoCD version so I am not sure if what you are seeing is the same as what I
> am seeing now.
>
> In any case, you may wish to update to (or play with a trial of) a later
> version to see if a sufficient number of global entities can be directly
> delegated to roles such that the super-admin permissions are much less
> necessary than earlier, and perhaps less necessary to map to roles
> frequently. I believe it at least supports environments/cluster
> profiles/elastic profiles/pipeline groups.
>
> -Chad
>
> On Sat, Jun 1, 2024 at 4:22 AM Jason Smyth  wrote:
>
>> Hi everyone,
>>
>> We are looking to improve our GoCD permissions management by using more
>> role-based permissions.
>>
>>
>> The role-based security documentation
>> 
>>  states
>> that it is possible to add a role to the server's security node admin list
>> and that all users of the role will inherit admin permissions.
>>
>> We tested this and it seems to work as described, however I am unable to
>> find a mechanism for managing this within GoCD. I was only able to get it
>> working by manually editing the cruise-config.xml file.
>>
>> Am I missing something, or is this really the only way to manage
>> role-based administrative access to GoCD?
>>
>> Thanks in advance,
>> Jason
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/go-cd/15df8afb-fa71-4d37-aa5d-a1d01939cb5cn%40googlegroups.com
>> 
>> .
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/go-cd/CAA1RwH-oabmFNK2aPWEE8hr2dXmnoX_oX6HBHsBsX1O%2BKXPeOw%40mail.gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/go-cd/CACxychEAS%3D2558NdLBpFNjFjJUssrgzZPSwknr%3DFM2Rs36nrbQ%40mail.gmail.com.