Artifactory permissions for components with CD enabled

15 views
Skip to first unread message

jn...@cloudbees.com

unread,
Feb 8, 2022, 6:01:50 AM2/8/22
to Jenkins Developers
Hi all,

A point raised in a permission update for a plugin in RPU is that we are still granting users permission to Artifactory for deployment of a plugin that they maintain even if the plugin is using CD.  https://github.com/jenkins-infra/repository-permissions-updater/pull/2265/files#r773914240

Is there any reason still to do this?

Backports for security would as far as I understand be deployed differently (the security team sets up a special repository in artifactory).

I also beleive (and may be incorrect) that we should be able to do CD on branches (however we may need to change <version>{$revision}</version> to be <version>xxx.{$revision}</version> in order to get a branched version number (in the cases where a plugin is not already using a prefix like for libraries).

Thus are we now in a place where if CD is enabled we can (and should) remove user level artifactory access for plugins (that we maintain), or even more broadly across all plugins to get some better security?

/James

Daniel Beck

unread,
Feb 8, 2022, 7:17:00 AM2/8/22
to jenkin...@googlegroups.com
We still need to have a reference as to who is the owner/maintainer of a component, and we have not yet defined an extension of the YAML that would separate deployers/uploaders from owners/maintainers. There are downstream scripts depending on these files, so yoloing a change of the key is probably not a good idea.

Jesse Glick

unread,
Feb 8, 2022, 9:22:58 AM2/8/22
to jenkin...@googlegroups.com
On Tue, Feb 8, 2022 at 6:02 AM 'jn...@cloudbees.com' via Jenkins Developers <jenkin...@googlegroups.com> wrote:
we are still granting users permission to Artifactory for deployment of a plugin that they maintain even if the plugin is using CD

Is there any reason still to do this?

The initial stance for JEP-229 was that we would continue to grant maintainers personal push permission in case CD did not work for whatever reason. As the system matures and we grow more confident that automated deployments will work reliably and cover every scenario, we could plan to tighten up security in this way.

To Daniel’s point, I guess the switch would be to not grant Artifactory permission to people in RPU for a CD-enabled repo, unless we wanted to add a new field to discriminate people who keep this permission for the time being from those who are maintainers and should have GH write permission but no more.
 
we should be able to do CD on [backport] branches

Yes. Needs to be better tested & documented, and there is probably room for some tools as well. https://gist.github.com/jglick/86a30894446ed38f918050c1180483e2#file-backport-sh-L12-L22
Reply all
Reply to author
Forward
0 new messages