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

[Matt Sicker]

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
 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  wrote:
>
>
>
> On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding 
>  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-dev+unsubscr...@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-dev+unsubscr...@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

-- 
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/CAEot4oyyapPMFsf4s_nUXOsVfW_p%3DvS67T_j4%3Dnf-2%3DzUT_Y6g%40mail.gmail.com.

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

[Chris Kilding]

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  wrote:
> 
> 
> 
> On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding  > 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-dev+unsubscr...@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-dev+unsubscr...@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.

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

[Daniel Beck]

On Wed, Feb 12, 2020 at 6:50 PM Chris Kilding <
chris+jenk...@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-dev+unsubscr...@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.

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

[Jesse Glick]

On Wed, Feb 12, 2020 at 12:50 PM Chris Kilding
 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.

-- 
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/CANfRfr0zj-i2xcg6X0rNit%3DzRuYQ5f7P_FFocbEPjE1Va_KNDg%40mail.gmail.com.

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

[Tim Jacomb]

Scoping to a job

On Thu, 13 Feb 2020 at 11:23, Chris Kilding 
wrote:

> 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
>
> On 13 Feb 2020, at 06:40, Tim Jacomb  wrote:
>
> 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
>
> On Wed, 12 Feb 2020 at 23:36, Chris Kilding <
> chris+jenk...@chriskilding.com> wrote:
>
>> 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  wrote:
>>
>> 
>>
>> 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
>>
>> On Wed, 12 Feb 2020 at 17:50, Chris Kilding <
>> chris+jenk...@chriskilding.com> wrote:
>>
>>> 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+jenk...@chriskilding.com> wrote:
>>> >
>>> > 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
>>> >
>>> > --
>>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-dev+unsubscr...@googlegroups.com.
>>
>> To view this discussion on the web visit
>> 

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

[Chris Kilding]

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

> On 13 Feb 2020, at 06:40, Tim Jacomb  wrote:
> 
> 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
> 
> On Wed, 12 Feb 2020 at 23:36, Chris Kilding  > wrote:
> 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 > > wrote:
>> 
>> 
> 
>> 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
>> 
>> On Wed, 12 Feb 2020 at 17:50, Chris Kilding > > wrote:
>> 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 > > > wrote:
>> > 
>> > 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
>> > 
>> > -- 
>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.com
>>  
>> .
>> 
>> -- 
>> You received this message because you are 

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

[Tim Jacomb]

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

On Wed, 12 Feb 2020 at 23:36, Chris Kilding 
wrote:

> 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  wrote:
>
> 
>
> 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
>
> On Wed, 12 Feb 2020 at 17:50, Chris Kilding <
> chris+jenk...@chriskilding.com> wrote:
>
>> 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 
>> wrote:
>> >
>> > 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
>> >
>> > --
>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-dev+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/4B4E063F-8E1A-41BC-9EE5-95EAE335A54B%40chriskilding.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group 

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

[Chris Kilding]

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  wrote:
> 
> 
> 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
> 
>> On Wed, 12 Feb 2020 at 17:50, Chris Kilding  
>> wrote:
>> 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  
>> > wrote:
>> > 
>> > 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
>> > 
>> > -- 
>> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/4B4E063F-8E1A-41BC-9EE5-95EAE335A54B%40chriskilding.com.

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

[Tim Jacomb]

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

On Wed, 12 Feb 2020 at 17:50, Chris Kilding 
wrote:

> 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 
> wrote:
> >
> > 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
> >
> > --
> > 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifzEig30bXEOmhf-rYzZ-o7aocJODJR3U5Go1_WGH6DaQ%40mail.gmail.com.

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

[Chris Kilding]

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  
> wrote:
> 
> 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
> 
> -- 
> 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/9567dfcf-b057-4616-8682-2eccf7b127b0%40www.fastmail.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-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/21F4C984-6263-4B61-811F-DF5FFBB65014%40chriskilding.com.