On Tuesday, 27 August 2019 09:16:40 UTC+1, ikedam wrote: > > Hi, > > I’m Ikedam, a maintainer of authorize-project-plugin. > https://plugins.jenkins.io/authorize-project > > Authorize-project-plugin doesn’t support features of modern Jenkins, such > as pipelines, multibranch and JCaC. > Making things worse, authorize-project-plugin is the only implementation > for QueueItemAuthenticator as far as I know. > > Authorize-project-plugin is originally designed for legacy Jenkins, that > is, expected to use with freestyle projects and matrix projects, and > expected to configured with web browsers. And I believe it’s fundamentally > incompatible with modern Jenkins. > > It might be possible to extend or redesign this plugin and to have it > applicable to modern Jenkins, but I’m afraid that it’s not reasonable as it > mainly costs not for new features, but rather for preserving backward > compatibilities. > > What I want to do here are: > > * Request a new plugin implementing QueueItemAuthenticator, supporting > modern Jenkins and which will replace and deprecate > authorize-project-plugin. > * Unfortunately I won’t join that development. Sorry. > > * Ask depelopers whether QueueItemAuthenticator is what we actually want, > or there can be alternate ways to control permissions of builds: > * I originally developed authorize-project-plugin for > copyartifact-plugin to control the permission to copy artifacts from other > builds. But I believe it’s easier to control that permission with > CopyArtifactPermissionProperty, which defines jobs allowed to access to > artifacts. > * I believe users want to define permissions not bound to actual > specific users such as those in LDAP, or Active Directory. But Jenkins > doesn’t provide mechanisms for authentications not bound to specific users, > like sevice accounts in Google Cloud Platform. >
So if you use the https://github.com/jenkinsci/impersonation-plugin that I wrote *but never actually got around to releasing* that will let a user impersonate any LDAP group they are a member of... then you can configure credentials and builds to run as that group... that way other users in the same group can configure etc. It's not service accounts, but it is very close... otoh it requires a security realm with groups (e.g. LDAP or ActiveDirectory) > * I expect QueueItemAuthenticator can be replaced with other > permission mechanisms not bound to specific users, like permissions between > jobs (generalizing CopyArtifactPermissionProperty) or permissions for > credentials from jobs (folder-scoped credentials might meet that). > * I don’t know actual usecases of QueueItemAuthenticatorcan and there > might be usecases that cannot be replaced with other mechanisms. > > Regards, > Ikedam > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6476f25d-197e-46e8-a2a4-02c087170497%40googlegroups.com.
