Jenkins deploys, authenticating target

[Maureen Barger]

HI all, here is an odd question. Of course we can affect permissions of Jenkins jobs so that only defined people can run them. But has anyone ever locked down the target environments so that authenticated user in Jenkins is tested to see if they have rights to target env. Does that make sense?

[Michael Neale]

By target env do you mean the slave/agent where the build runs? 

[Maureen Barger]

No the environment where Jenkins will be issuing the deploy.

--
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/143879fe-ef94-4147-b3bd-fffe3e2bb0cc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stephen Connolly]

So you can do this if your deployment mechanism is integrated with the deployment-framework-plugin API - or if your deployment mechanism is integrated with the credentials plugin.

Basically you rely on the credentials to deploy being in the *User*'s credentials store and not in the SYSTEM credentials store.

Then either the deployment framework aware plugin  - or a regular job with a credentials parameter - will force the user triggering the job to select the credentials... obviously only those users that have valid credentials will be able to select them... and hence only they may deploy.

It is a tad "fun" to set up, but it works once you get it right

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAHz6asr2_NFpH-wRkuy_hz%2B4m0TJpdhvGEvRaAbxMS9o2FhjAg%40mail.gmail.com.

[Maureen Barger]

Oh thank you, I hadn't seen that plugin before!
But I am not sure it will work for what we are planning.

We have deploy jobs whose configuration rights are very restricted. The deploy jobs are used by teams who may have multiple environments. A team may be comprised of 20 people and an environment assigned to that team only used by 2 or 3 of them for a period of time. In order to protect the target environment's setup, it is the desire to limit the ability to deploy to the target to those 2-3 people rather than redo all of the teams' deploy jobs that larger groups could use.
At the same time, the team wants to document their environment name, who it is assigned to, what build is deployed there and some other details in a quick dashboard.
The plan has evolved to perhaps store the above data in a simple CRUD that the teams can use, and to query from Jenkins that backend db for the IDs who can actually deploy to that environment.
Another thought I had was perhaps implementing htaccess on the targets but the question there is how to proxy the Jenkins request to push the deploy from the Jenkins user to the authenticated user who ran the job.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMzH5C%3DLidC9rAm0ZTOJcOBBEuLw7vsqi-F-WcoEHrSFNw%40mail.gmail.com.

[Stephen Connolly]

Also have a look at the authorize project plugin. That will let you have the build job run as the user who triggered the build and then you can look to inject their username into the build environment

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAHz6asr7oD%2BHm_E8BrJnHz4bC-S_MgGpH6_AMaz7cFiCsRV%2B0g%40mail.gmail.com.

[Maureen Barger]

You just made my day. Thank you!!

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMxBU-Ap1caLdHOiUPH2Kvyg%2Bs6g4HL2QcezXpB4xO0fjA%40mail.gmail.com.