Assign Administrator Permissions to Role Without Manually Modifying cruise-config.xml

[Jason Smyth]

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

[Chad Wilson]

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

--
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/15df8afb-fa71-4d37-aa5d-a1d01939cb5cn%40googlegroups.com.

[Aravind SV]

Hello!

Yes, what Chad says makes sense to me. 

I don't recall discussing a UI for the <admins> tag though. There is an API, if that helps you,  Jason: 

https://api.gocd.org/current/#update-system-admins

Cheers,

Aravind

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH-oabmFNK2aPWEE8hr2dXmnoX_oX6HBHsBsX1O%2BKXPeOw%40mail.gmail.com.

[Jason Smyth]

Hi Chad, Aravind,

Thank you for the feedback.

The primary context of this question is creating our own internal documentation for how to configure GoCD authentication and authorization. Since this (theoretically) only needs to be done once on initial setup, it's probably not worth the headache of documenting how to do it via the API. For the sake of simplicity, the following workflow should suffice:

1. Install GoCD.
2. Install the LDAP auth plugin.
3. Configure the LDAP connector.
4. Log in.
5. Configure the Admin role (and make sure you are in the group).
6. Navigate to the Users Management page (and make sure you have been assigned the Admin role).
7. Click the toggle in the SYSTEM ADMIN column to make your user the super-user.
8. Navigate to the Config XML page.
9. Locate the server/security/admins node (should be near the bottom of the XML document).
10. Replace "<user>yourUserName</user>" with "<role>AdminRoleName</role>".

Now that I type it all out, it doesn't actually seem all that "simple", but still, good enough to get the job done. Since we are using LDAP authentication, we can manage any subsequent changes to super-user privileges via the appropriate AD group.

To correct a small mistake in Chad's list of delegable permissions, the actual list is: Environments, Config Repos, Cluster Profiles, and Elastic Agent Profiles. Pipeline Groups are, sadly, not included (hence my other email thread).

Thanks again,

Jason

[Chad Wilson]

Not sure of your workflow, but in my previous setups this type of initial configuration involved bootstrapping via curls to API from source controlled, termplated config a few things such as cluster/elastic profiles, authorization config, secrets config etc.

This is essentially similar to what the helm chart does for you when configuring for elastic agents on kubernetes where it does some basic curls to some APIs to get things going.

https://github.com/gocd/helm-chart/blob/master/gocd/templates/gocd-server-configmap.yaml

When I said you can give permissions to pipeline groups what I meant in the scope of those changes is that config repos can be permissioned to only allow to feed pipelines into certain pipeline groups; to allow one team's config repo to not screw up/alter another's pipelines/pipeline groups. But it is config repo <> pipeline group adminish permissions and otherwise in the realm of "system admin", not user role <> pipeline group permissions you are probably thinking of.

Since setOf(users-who-can-commit-to-config-repo) <> setOf(users-who-otherwise-have-pipeline-group-admin-perms) this can be an important control to have, since the config repo committer identity cannot otherwise be mapped to a GoCD user/role identity to determine if the change is "allowed". Moot in your setup if you have one big massive config repo and hundreds of groups, as you have presumably decided anyone who can commit/push to that repo can be trusted to alter a pipeline in any pipeline group

-Chad

To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/2924be0d-3f38-4bb7-a97b-ec9874be55c5n%40googlegroups.com.