Global credentials' contents viewable by all

[Jeff]

I'm hoping someone can nudge me in the right direction because I have to believe we are doing something wrong. "Jenkins: The Definitive Guide" (O'Reilly) has been of no help toward solving this issue. Nothing turns up with net searching either. Your help would be greatly appreciated.

SHORT: ALL sensitive credential info is visible by any authenticated user. Non-Admin user Jimbo can see user Susie's Jenkins credentials' contents (private keys, etc!)

LONG:

Our current Jenkins instance is used by several projects with a few developers per project. Although all of the developers across all of the projects belong to the same company (ours), the Jenkins behavior we're seeing is unacceptable and we need to fix it: ALL sensitive credential info is visible by any authenticated user. Non-Admin user Jimbo can see user Susie's Jenkins credentials' contents (private keys, etc!).

We're using the Role-Based authorization plugin, but I've confirmed this same problem exists with other authorization strategy plugins. Additionally, related, we're using the SSH Credentials plugin (and ~15 other unrelated plugins).

The role "authenticated" has been granted "Credentials View", "Credentials Update", "Credentials Create", "Credentials Delete" privileges. This is obviously to allow authenticated users to see and manage only their own credentials. However, authenticated users are able to browse around and see other peoples credentials' contents.

What are we doing wrong? Is that just how Jenkins is due to its origins as a ONE-jenkins-per-project tool? Is there a way to fix this so that authenticated users have the privileges above applied to only their own credentials?

[Stephen Connolly]

Are you storing your own credentials in Jenkins' store or in the
per-user credentials store?

The credentials in Jenkins' store should be visible to all users with
Credentials/View etc

The credentials in the per-user credentials store should be visible to
only the user that they are defined in.

To access the per-user credentials store you need to go to the user's
config screen... quickest short cut is to click the user's name to the
immediate left of the `logout` button in the title bar

NOW...

Storing them in the per-user store will likely not be much use to you
without the Authorize Projects plugin that lets you run builds as a
user other than ACL.SYSTEM... so this will require some thinking for
you.

Another option is to use the per-folder credentials store and restrict
access to folders (of course you might need a auth strategy that was
designed for use with folders to be able to carve up the permissions
correctly)

> --
> 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/fa037531-e069-4b0f-8713-773f134c9e6b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Jeff]

Hi Stephen,

Thanks for the reply! I made a lot of progress on this, somehow, where I never was making progress before... since posting to the group. Figures.

It turns out that because the users could see "Credentials" as an option always at left, they were selecting that and blindly choosing the "Global" domain to add their credentials. They could see the "Credentials" item at left because I'd given authenticated users CRUD rights for that under "Manage Roles". Turns out that's a mistake for any Jenkins environment where sensitive information needs to remain protected from other users.

I've directed the ~10 people to move their credentials to their personal credential store. One everything has been moved, I'll disable the CRUD privileges related to "Credentials" for authenticated users.

The Jenkins permissions matrix in the UI is very vague, to say the least. One is left to guess at what exactly the real-world effect of those checkboxes will be. The simplistic "Credentials" column header in the permissions matrix is very misleading :(

NOW...

Storing them in the per-user store will likely not be much use to you
without the Authorize Projects plugin that lets you run builds as a
user other than ACL.SYSTEM... so this will require some thinking for
you.

Another option is to use the per-folder credentials store and restrict
access to folders (of course you might need a auth strategy that was
designed for use with folders to be able to carve up the permissions
correctly)

Ugh. I guess I'll start researching that now.

Thank you again.
Jeff