Replace authorize-project-plugin

[ikedam]

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.
* 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

[Jesse Glick]

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 <iked...@gmail.com> 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/

[Stephen Connolly]

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)

[René Scheibe]

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.

[ikedam]

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