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 On Tue, Jun 4, 2024 at 3:34 AM Jason Smyth <[email protected]> wrote: > 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 > > > On Sunday 2 June 2024 at 08:27:26 UTC-4 Aravind SV wrote: > >> 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 >> >> >> On Sat, 1 Jun 2024 at 10:21, Chad Wilson <[email protected]> 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 <https://github.com/gocd/gocd/issues/7222> 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 <[email protected]> wrote: >>> >>>> Hi everyone, >>>> >>>> We are looking to improve our GoCD permissions management by using more >>>> role-based permissions. >>>> >>>> >>>> The role-based security documentation >>>> <https://docs.gocd.org/19.8.0/configuration/dev_authorization.html#role-based-security> >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/go-cd/15df8afb-fa71-4d37-aa5d-a1d01939cb5cn%40googlegroups.com >>>> <https://groups.google.com/d/msgid/go-cd/15df8afb-fa71-4d37-aa5d-a1d01939cb5cn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/go-cd/CAA1RwH-oabmFNK2aPWEE8hr2dXmnoX_oX6HBHsBsX1O%2BKXPeOw%40mail.gmail.com >>> <https://groups.google.com/d/msgid/go-cd/CAA1RwH-oabmFNK2aPWEE8hr2dXmnoX_oX6HBHsBsX1O%2BKXPeOw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/go-cd/2924be0d-3f38-4bb7-a97b-ec9874be55c5n%40googlegroups.com > <https://groups.google.com/d/msgid/go-cd/2924be0d-3f38-4bb7-a97b-ec9874be55c5n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH-eJTDKszE%3DuO_hRHNrGjOJY8QcrrPOxUAt5D5QeWzzMw%40mail.gmail.com.
