Re: Replace authorize-project-plugin
Hi, Thanks for comments. I expect Jenkins provides more options for build authorization as Jenkins now warns users for build authorizations as Rene pointed. Trigger restrictions look just what I expected to replace `QueueItemAuthenticator`. It's only a part of replacements of `QueueItemAuthenticator` (only Job.BUILD as pointed), and I want to know whether there are other permissions to support with the alternative of `QueueItemAuthenticator`. As far as I know: * Job.Build: replaced with Trigger restrictions. * Job.Read: CopyArtifactPermissionProperty (applicable only to copyartifact) Let me know if there are other permissions to support. Impersonation-plugin and JENKINS-15063 both would be a great step to resolve issues relating to authentication and authorization. But I'm afraid they might not resolve all issues. I believe following three issues exist: * The configuration should not belong to a specific real user. * For example, both user A and B in the same division should be able to configure the job. * Impersonate-plugin would resolve this issue. * Jenkins administrators may not be administrators of authentication server (LDAP, ActiveDirectory so on). * It means Jenkins administrators may not be able to add users and groups at their will. * JENKINS-15063 would allow administrators to add Jenkins-specific users and groups. * Authentication mechanism to restrict users to configure build authorization. * Actually it's not so easy. Authorize-project costs much to implement this. 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/308b05c7-4c3c-4c1f-b06b-0356a5012c79%40googlegroups.com.
Re: Replace authorize-project-plugin
Hi everybody, Since Jenkins LTS 2.176.1 (https://jenkins.io/doc/upgrade-guide/2.176/) which includes https://issues.jenkins-ci.org/browse/JENKINS-24513 there is an administrative monitor in place. It recommends to install the authorize-project plugin. Having a look at the usage chart at https://plugins.jenkins.io/authorize-project also shows that the usage started to increase heavily starting 2019. I guess it would be a good idea to add some information about the limitations on the plugin page. -- 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/ad500262-4391-4be2-acf7-8e0774e74c61%40googlegroups.com.
Re: Replace authorize-project-plugin
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.
Re: Replace authorize-project-plugin
First of all, thank you for thinking about what the project needs, rather than focusing narrowly on fixing problems with an existing design. On Tue, Aug 27, 2019 at 4:16 AM ikedam wrote: > 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. Right, this is a very longstanding need. It is usually tracked alongside security realm multiplexing as JENKINS-15063, though the service account concept is a more limited feature that might be better implemented directly. > I expect QueueItemAuthenticator can be replaced with other permission > mechanisms not bound to specific users, like permissions between jobs I might not phrase it as “permissions” because that might be taken to mean that such a system must be based on Jenkins’ `ACL` + `Permission` + `Authentication`. You _could_ pick a design based on service accounts configured in the `AuthorizationStrategy`, but there are alternative choices. For reference, CloudBees Core includes a different design to solve a subset of this problem (what `QueueItemAuthenticator` would let you control in the case of `Job.BUILD` permission): https://go.cloudbees.com/docs/cloudbees-core/cloud-admin-guide/trigger-restrictions/ -- 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/CANfRfr0yNdcsCa_1nxqOw-CHoSOZaUK2BA-%3DhKDV-kuMQHUobg%40mail.gmail.com.
