we are currently prototyping the usage of the Jenkins CLI especially to get an automated overview of our CI/CD infrastructure.
By doing this we figured out, that the “list-plugins” call of the Jenkins CLI does not only need the “Plugin Usage View > Plugin View” permission but also the “Administer” permission.
In my opinion needing the “Administer” permission just for listing installed plugins is kinda overkill especially regarding principles like “defence in depth” or “need to know”.
Is there any chance to change the need of “Administer” permissions for the “list-plugins” call? Or is there a workaround for this?
The Jenkins core should not take a hard dependency on the plugin. But some of the following approaches could work:
In core, look up the PluginUsageView.PLUGIN_VIEW permission by its ID. If not found, then use Jenkins.ADMINISTER as before. But making the core special-case this one plugin would be ugly.
Define a “list plugins” permission in the Jenkins core just for this command, and use that. I think this permission could be disabled (not directly grantable to users) but implied by both PluginUsageView.PLUGIN_VIEW and Jenkins.MANAGE (javadoc).
Instead of a new permission, just make the list-plugins command use Jenkins.MANAGE.
Define a separate CLI command “list-plugins-looser” in plugin-usage-plugin. In that, check PluginUsageView.PLUGIN_VIEW rather than Jenkins.ADMINISTER. The CLI appears to be already based on an extension point so that plug-ins can provide additional commands. The resulting duplication of code would be ugly though.
Define an extension point in core, just for relaxing the permission check; and implement that in plugin-usage-plugin. Seems worse than defining a new permission for this.
Of those, I feel using Jenkins.MANAGE would be cleanest.