JEP-225: Folder-based access control for any credentials provider

14 views
Skip to first unread message

Chris Kilding

unread,
Feb 12, 2020, 11:29:05 AM2/12/20
to jenkin...@googlegroups.com
Hello,

This is the discussion thread for JEP-225: Folder-based access control for any credentials provider.

A brief summary...

The Cloudbees Folders Plugin has the ability to restrict access to credentials on a per-folder basis. Unfortunately this feature is only available for credentials stored in the Folders plugin's internal provider. This JEP will extend that concept, and allow users to specify folder-based access restrictions for any credential, from any provider. (For example, the AWS Secrets Manager and Kubernetes providers.)

This JEP is relevant in 2 notable cases:

- Dev / Production environment isolation. (Ensure that only jobs in the production environment can access production credentials, and vice versa.)
- Per-team isolation on a multi-tenant Jenkins. (Ensure that only a given team or teams can access their credentials.)

You can follow the pull request at https://github.com/jenkinsci/jep/pull/266.

Chris

Chris Kilding

unread,
Feb 12, 2020, 12:50:38 PM2/12/20
to jenkin...@googlegroups.com
The first thing to figure out is what role-based access control solutions are already out there for Jenkins, so we can then decide how best to fit this functionality in.

I have encountered the following solutions which seem relevant, but I know very little about them:

- Cloudbees RBAC plugin (commercial)
- Role Strategy Plugin
- Jenkins permissions system

Would someone who knows these components well be able to provide more details, and thoughts on how we might add concepts of folders and credentials to them, so that credential access constraints could be formulated as standard rules?

Chris

> On 12 Feb 2020, at 16:29, Chris Kilding <chris+...@chriskilding.com> wrote:
>
> Hello,
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.com.

Tim Jacomb

unread,
Feb 12, 2020, 1:01:45 PM2/12/20
to jenkin...@googlegroups.com
Not directly related, possibly even to this JEP, 

But wanted to add a couple of features I’ve seen in other systems,

1. Require authorisation, before allowed to use, I.e build is run and fails because the credential isn’t authorised for that job but then an administrator can authorise it and it will be allowed to use it on the next run,
2. Credentials scoped to a single build

Thanks
Tim

Chris Kilding

unread,
Feb 12, 2020, 6:36:53 PM2/12/20
to jenkin...@googlegroups.com
Point 2 (credentials scoped to a single build) could be relevant - if we’re adding a credentials concept to a general ACL, a user should be able to apply any kind of restriction that their ACL permits to the credentials objects. (Not just folder restrictions.)

I’m a bit unclear about what you meant though - could you clarify, maybe with an example?

Chris

On 12 Feb 2020, at 18:01, Tim Jacomb <timja...@gmail.com> wrote:



Tim Jacomb

unread,
Feb 13, 2020, 1:40:23 AM2/13/20
to jenkin...@googlegroups.com
Which bit were you unclear about?
Point 1?

Point 1 is a request based authorisation, nothing is allowed to use it by default, jobs request to use it and then an autrhorised person allows it

Chris Kilding

unread,
Feb 13, 2020, 6:23:28 AM2/13/20
to jenkin...@googlegroups.com
I was unclear on point 2. Is this a way to…
- scope a credential to an individual job or jobs?
- scope a credential to an individual build or builds?
- provide ephemeral credentials that are created at the start of a build, exist during the lifetime of the build, and are scrapped at the end?

Ephemeral credentials would be harder, as we would have to reconcile the long-lived nature of credentials (and the extra constraints of remote credential providers) with the short-lived nature of builds.

Chris

Tim Jacomb

unread,
Feb 13, 2020, 7:18:24 AM2/13/20
to jenkin...@googlegroups.com
Scoping to a job

Jesse Glick

unread,
Feb 13, 2020, 9:10:13 AM2/13/20
to Jenkins Dev
On Wed, Feb 12, 2020 at 12:50 PM Chris Kilding
<chris+...@chriskilding.com> wrote:
> I have encountered the following solutions which seem relevant, but I know very little about them:
>
> - Cloudbees RBAC plugin (commercial)

https://docs.cloudbees.com/docs/admin-resources/latest/plugins/rbac
a.k.a. `nectar-rbac`

> - Role Strategy Plugin

Also allows roles to be defined and then mapped to groups of users. At
a high level, the main difference in design (as I understand it) is
that `role-strategy` centralizes configuration at the system level,
using pattern matching rules to make access control decisions; whereas
`nectar-rbac` is oriented towards folder-level configuration (usually
adding, but potentially also suppressing, permissions from the parent)
and supports delegating further decisions to a folder-level
administrator.

More commonly used than either of these is the old `matrix-auth`,
which also got folder-level support a few years back, and has a
simpler configuration system (no concept of roles or synthetic
groups).

> - Jenkins permissions system

A pretty complicated topic, as I am sure the JEP-223 developers will
tell you! Very broadly, there is a `SecurityRealm` which defines
authenticated users (subjects); a set of `Permission`s which define
general operations (verbs); various `AccessControlled` objects such as
`Job`s; and an `AuthorizationStrategy` which is a factory for `ACL`s,
effectively granting or denying access to a given subject-verb-object
triplet.

https://jenkins.io/doc/developer/security/ gives a brief overview. We
need more depth.

> thoughts on how we might add concepts of folders and credentials to them

As noted, folders are already well integrated with access control, and
the authorization plugins can support plugin-contributed permissions.

There are a couple of permissions already defined in the `credentials`
plugin but I have never fully understood how they are intended to be
used in context and I suspect few administrators have managed to set
this up meaningfully. There is generally a lack of a clear notion in
Jenkins of how builds, as opposed to directly user-initiated actions,
should be authenticated and authorized, and in particular how this
ought to interact with stored credentials. The `authorize-project`
plugin offers one approach but it is not a good UX.

The overall goal of the JEP draft—to decouple access control decisions
about credential use from the physical storage layer—makes sense for
at least some cases. I am not convinced it is the most natural way to
consume Kubernetes credentials, since K8s has a native RBAC system and
the `kubernetes` plugin can interact with namespaces and service
accounts, though the existing `kubernetes-credentials-provider`
basically treats K8s `Secret`s as a monolithic store (it assumes the
Jenkins master process has permission to read them all) so you do no
worse by using Jenkins ACL to make finer-grained decisions.

I hope the above helped. I realize there are more questions than
answers here: design options need to be explored.

Daniel Beck

unread,
Feb 13, 2020, 9:13:32 AM2/13/20
to JenkinsCI Developers
On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding <chris+...@chriskilding.com> wrote:
I have encountered the following solutions which seem relevant, but I know very little about them:

- Cloudbees RBAC plugin (commercial)
- Role Strategy Plugin
- Jenkins permissions system

Given the way you wrote up this list, do you mean https://plugins.jenkins.io/matrix-auth with the third item?

Chris Kilding

unread,
Feb 14, 2020, 5:59:39 AM2/14/20
to jenkin...@googlegroups.com
I meant the permissions thing which is dotted all around the codebase, and looks like this:

import hudson.security.ACL;
import org.acegisecurity.Authentication;

public void doSomething(Authentication authentication) {
  if (ACL.SYSTEM.equals(authentication)) {
    // do something
  }
}

The matrix-auth component seems to have a hudson.security package, but I didn’t see the ACL class in it though.

--
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-de...@googlegroups.com.

Matt Sicker

unread,
Feb 14, 2020, 11:38:46 AM2/14/20
to jenkin...@googlegroups.com
ACL is in jenkins-core along with AccessControlled and the other
classes Jesse mentioned.

On Fri, Feb 14, 2020 at 4:59 AM Chris Kilding
<chris+...@chriskilding.com> wrote:
>
> I meant the permissions thing which is dotted all around the codebase, and looks like this:
>
> import hudson.security.ACL;
> import org.acegisecurity.Authentication;
>
> public void doSomething(Authentication authentication) {
> if (ACL.SYSTEM.equals(authentication)) {
> // do something
> }
> }
>
> The matrix-auth component seems to have a hudson.security package, but I didn’t see the ACL class in it though.
>
> On 13 Feb 2020, at 14:13, Daniel Beck <db...@cloudbees.com> wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding <chris+...@chriskilding.com> wrote:
>>
>> I have encountered the following solutions which seem relevant, but I know very little about them:
>>
>> - Cloudbees RBAC plugin (commercial)
>> - Role Strategy Plugin
>> - Jenkins permissions system
>
>
> Given the way you wrote up this list, do you mean https://plugins.jenkins.io/matrix-auth with the third item?
>
>
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7Pt%2B-NWfMV9Qvbr-kPAoBjb%3DgDFTCm4fG3tV1CeUVtHgK5g%40mail.gmail.com.
>
>
> --
> 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-de...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/242E58A5-AE65-416C-B8AD-33E9089046F5%40chriskilding.com.



--
Matt Sicker
Senior Software Engineer, CloudBees
Reply all
Reply to author
Forward
0 new messages