Per Jenkins user Git credentials - restrict access to some git repo to some users

[Francois Marot]

Hi all,

I need your feedback to know if my Company's requirement is compatible with Jenkins:

we have many Git repositories.

Some jenkins jobs need to access some git repositories. But some repositories contain source code more sensible than others, hence the need for different credentials regarding the git (ssh) credentials.

On the jenkins side, for now, we have the git credentials globally available.

What we would like is to have only some users able to create jobs, and each user to have only acces to some git ssh credential at job creation time (so that the job can reference a git repository that the user is allowed to access).

Is it possible ? I did not saw anything like this but I may not have found the correct plugins...


Francois

[Mark Waite]

I've not seen any facility which would allow you to restrict use of a credential by user.  Credentials can be limited so that they are only visible for certain hosts and/or certain protocols, but not by which users or roles in the system can reference those credentials when defining a job.

I assume you've already checked that the role strategy plugin doesn't have the facility you need.  Its screen shots show that it can control who can tag a repository, but it doesn't seem to allow control over who can access a credential.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/90bbd255-4c85-4bed-aca9-7bb6b10c4500%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark Waite]

You might also review the webinar mentioned at https://www.cloudbees.com/products/cloudbees-jenkins-platform/team-edition/features/role-based-access-control-plugin in case the Cloudbees roles based access control plugin could meet your needs.  I'm pretty sure that plugin requires a Cloudbees Enterprise license.

Mark Waite

[Stephen Connolly]

Well the following assumes that the git plugin has implemented credentials support correctly.

You will need the following:

• https://wiki.jenkins-ci.org/display/JENKINS/Authorize+Project+plugin
  
• A willingness to document some stuff
• A bit of patience

So the way this works is that credentials are supposed to be resolved from the authentication that the build is running as.

If you have never seen the Authorize Project plugin then that means that credentials are resolved from ACL.SYSTEM's credential store... (unless you are using parameterized credentials and let the user select the credentials from a credentials parameter...)

So you would be configuring the job to run as the user who triggered the build rather than ACL.SYSTEM... as soon as you do that ASSUMING THAT THE GIT SCM IMPLEMENTED CREDENTIALS CORRECTLY then the credentials used will be searched for from the user's own credentials store rather than ACL.SYSTEM's... at which point you look and see... oh no it didn't: 

Where is my expressionsAllowed="true"

Which basically means that you have to provide the credential ID by selecting the correct one from the drop-down... so you run over to your own credentials store and create a credential with a sensible ID such as `secret-repo` then you select that and save the job configuration.

Now from then on... you can trigger the build and - because you have the credentials with ID `secret-repo` the build will work for you. If anyone else wants to trigger the build, then they will need to add their own credentials with the ID `secret-repo` into their own credentials store.

Of course there is another path...

If you set up access control on a per-folder basis, you can store credentials that are appropriate for that folder only in the ACL.SYSTEM credential store for that folder and all child items. That way you can create a folder called `secret` add in it the credentials for the secret-repo (not caring about IDs) and only jobs in that folder will have access to the credentials... but any user that can access the folder will be able to access the credentials from any job they can configure.

HTH

(and probably after this Mark may go running off to see what fun there is with Authorize Project plugin and what bugs may / may-not exist in Git SCM and it's use of credentials with this plugin)

-Stephen

--

[Francois Marot]

Thanks Mark and Stephen for your detailed responses.
So in the end, I think that Jenkins has a problem because a user that can create a job has access to ALL credentials. So by default, any user able to create one job may steal any source code located on a git repo whose Jenkins has the credential for.
Stephen, it would be interesting to test your solution, but I think that i'll advise our IT guys to deploy more than one number of jenkins instances, each with it's own credentials. It may be more maintainable with a small number of instances.

Regards

[Victor Martinez]

Hi there,
Have you asked Cloudbees whether they support that feature as part of the enterprise version yet?

It might help you

Cheers

[Mark Waite]

Response in-line.

On Mon, Nov 23, 2015 at 10:41 AM Francois Marot <francoi...@gmail.com> wrote:

Thanks Mark and Stephen for your detailed responses.
So in the end, I think that Jenkins has a problem because a user that can create a job has access to ALL credentials.

I'm not clear why you think that a user that can create a job has access to "All credentials".  Maybe you omitted a phrase from your sentence?

I'd say that a user that can create a job has access to all credentials that are assigned to the global credentials domain, or which are assigned to a the hostname (or hostname/protocol) for the source repository they reference, or which are assigned to the folder in which they created the job (based on the Cloudbees Folders plugin).  I suspect I've missed other cases where credentials access is limited.

If you are concerned about users creating jobs to "steal any source code", then don't place credentials in the global domain and don't assign them to a hostname known to the malicious users.  If you can prevent users from creating jobs in a particular folder, then I think you should be able to assign the credentials to specific folders, and then don't grant the malicious users permission to those folders.

 

So by default, any user able to create one job may steal any source code located on a git repo whose Jenkins has the credential for.

 

If source code theft is a concern, then you'll need to limit much more than the permission to create jobs.  Any user able to browse a Jenkins workspace is allowed to "steal any source code" by browsing that workspace.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/16200f9f-f81f-47cd-9003-2a19943b352a%40googlegroups.com.

[Stephen Connolly]

On Monday 23 November 2015, Francois Marot <francoi...@gmail.com> wrote:

Thanks Mark and Stephen for your detailed responses.
So in the end, I think that Jenkins has a problem because a user that can create a job has access to ALL credentials. So by default, any user able to create one job may steal any source code located on a git repo whose Jenkins has the credential for.

Unless you use folders and put the credentials in the folders and restrict user access per folder... Yes anyone who can create/configure a job can use any credentials "in scope" for use by that job. 

Stephen, it would be interesting to test your solution, but I think that i'll advise our IT guys to deploy more than one number of jenkins instances, each with it's own credentials. It may be more maintainable with a small number of instances.

Folders with per-folder access control and per-folder credentials stores will achieve the same result, with less overhead.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/16200f9f-f81f-47cd-9003-2a19943b352a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Sent from my phone

[Baptiste Mathus]

Le 23 nov. 2015 7:33 PM, "Mark Waite" <mark.ea...@gmail.com> a écrit :
>
> Response in-line.
>
> On Mon, Nov 23, 2015 at 10:41 AM Francois Marot <francoi...@gmail.com> wrote:
>>
>> Thanks Mark and Stephen for your detailed responses.
>> So in the end, I think that Jenkins has a problem because a user that can create a job has access to ALL credentials.
>
>
> I'm not clear why you think that a user that can create a job has access to "All credentials".  Maybe you omitted a phrase from your sentence?
>
> I'd say that a user that can create a job has access to all credentials that are assigned to the global credentials domain, or which are assigned to a the hostname (or hostname/protocol) for the source repository they reference, or which are assigned to the folder in which they created the job (based on the Cloudbees Folders plugin).  I suspect I've missed other cases where credentials access is limited.
>
> If you are concerned about users creating jobs to "steal any source code", then don't place credentials in the global domain and don't assign them to a hostname known to the malicious users.  If you can prevent users from creating jobs in a particular folder, then I think you should be able to assign the credentials to specific folders, and then don't grant the malicious users permission to those folders.
>  
>>
>> So by default, any user able to create one job may steal any source code located on a git repo whose Jenkins has the credential for.
>
>  
> If source code theft is a concern, then you'll need to limit much more than the permission to create jobs.  Any user able to browse a Jenkins workspace is allowed to "steal any source code" by browsing that workspace.

Yes, or a variant: depending on how you manage your slaves and so on it can be very easy to use say a shell step to just copy other workspaces on the node, or worse if you allow jobs running on master: you could for example crawl all the config.xml and clone+push code where you want…

Cheers