Input Needed: Credentials in DSL Scripts

[Daniel Spilker]

Currently there are 3 ways to store credentials in Jenkins and in the Job DSL:

• By using the Credentials Plugin [1]. The plugin stores the credentials in a secure way and jobs reference the credentials by ID. Newer versions of the credentials plugin allow to use user-defined IDs, so they became human readable and portable across Jenkins instances. This is IMHO the best way to store credentials. Unfortunately only a few plugin use the Credentials plugin, but at least the important ones like the Git plugin and the Subversion plugin do. And support for the Credentials plugin is growing. The Job DSL plugin has support for the Credentials plugin.
• By using hudson.util.Secret [2]. Jobs store a value which has been encrypted by a master key. Each Jenkins instance generates it's own master key, so job definitions containing encrypted values are not reusable on other Jenkins instances. Because of that, a DSL script containing an encrypted value can only be used on one Jenkins instance. In case of a security problem it might be necessary to change the master key [3] and in that case DSL scripts containing encrypted values must be changed. While this is a safe way to store the credentials, it's not supported by the Job DSL. Users can use a configure block to generate XML with encrypted secrets.
• By storing secrets in plain text. This is the worst option, but unfortunately quite a few plugins do that. I tried to enforce a policy to not support those plugins in the DSL, but some support has been added before I tried to enforce the policy (e.g. for the Perforce plugin [4]) and some support slipped through the review process (e.g. the API tokens for the HipChat [6], Slack [7] and Flowdock [8] publishers). Users can use a configure block to generate XML with plain text secrets.

So, what do think of the current approach to avoid plain text credentials and the hudson.util.Secret class in the DSL? Shall I continue to reject support for that? And shall I deprecate support for all plugins which violate this policy? Or, to put it the other way around, shall the DSL support only credentials managed by the Credentials Plugin?

There are several pending pull requests, which add support for plugins that either use the hudson.util.Secret [9] or store the credentials in plain text [10][11][12][13][14]. I will delay to reject or merge them until I get some feedback.

Daniel

[1]: https://wiki.jenkins-ci.org/display/JENKINS/Credentials+Plugin
[2]: http://javadoc.jenkins-ci.org/hudson/util/Secret.html
[3]: https://wiki.jenkins-ci.org/display/SECURITY/Re-keying
[4]: https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference#perforce
[5]: https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference#irc
[6]: https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference#hipchat-publisher
[7]: https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference#slack-publisher
[8]: https://github.com/jenkinsci/job-dsl-plugin/wiki/Job-reference#flowdock-publisher
[9]: https://github.com/jenkinsci/job-dsl-plugin/pull/525
[10]: https://github.com/jenkinsci/job-dsl-plugin/pull/358
[11]: https://github.com/jenkinsci/job-dsl-plugin/pull/526
[12]: https://github.com/jenkinsci/job-dsl-plugin/pull/541
[13]: https://github.com/jenkinsci/job-dsl-plugin/pull/545
[14]: https://github.com/jenkinsci/job-dsl-plugin/pull/557

[Daniel Spilker]

And another pull request for this category:
https://github.com/jenkinsci/job-dsl-plugin/pull/567

Daniel

[Matt Sheehan]

IMO a prominent warning would suffice. Maybe add an annotation that will show up as a security warning in the docs.

Is it possible to expose the build's env vars to the DSL? Then we could inject global passwords to the env and reference them that way, keeping them out of source control.

--
You received this message because you are subscribed to the Google Groups "job-dsl-plugin" group.
To unsubscribe from this group and stop receiving emails from it, send an email to job-dsl-plugi...@googlegroups.com.
To post to this group, send email to job-dsl...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32C69TQGLsdz1hpAVXEjuFpbhdEns9YQb3Rwh256gCJWbA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Spilker]

OK, how about this: https://github.com/jenkinsci/job-dsl-plugin/pull/580

It adds a wiki page listing the options and adds pointer to that page from the job reference where necessary.

We can add an annotation after merging the API Viewer.

Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/CAKZH%3Dda%2BZBDOtHQ1X3YLvMwvXF5%3DZPfu-nf_H442V72OAGzkuQ%40mail.gmail.com.

[Matt Sheehan]

Sounds good to me.

To view this discussion on the web visit https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32BLhmNNC9iCnSaiHEGF4XGeGM5TYMjw-57Gxkk5f53qxA%40mail.gmail.com.