Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to define username and password for proxy #858

Open
ruriky opened this issue Feb 22, 2018 · 1 comment
Open

Unable to define username and password for proxy #858

ruriky opened this issue Feb 22, 2018 · 1 comment

Comments

@ruriky
Copy link

ruriky commented Feb 22, 2018

Jenkins' stores its proxy configs in proxy.yaml. Currently the module can handle the tags: 'name', 'port' and 'noProxyHost' but 'username' and 'secretPassword' are missing.

Example of proxy.yaml:

<proxy>
  <name>webproxy.company.com</name>
  <port>4000</port>
  <userName>username</userName>
  <noProxyHost>something.company.com</noProxyHost>
  <secretPassword>xxxxxxx</secretPassword>
</proxy>

This would be easy to implement but the password in the config file seems to be encrypted by Jenkins. Has anybody an idea is the puppet module able to do the encryption for the password? I wonder how this enhancement could be implemented.

@esalberg
Copy link
Contributor

esalberg commented Feb 26, 2018

My guess would be that this could be implemented via a groovy script, e.g. like the one here:
geerlingguy/ansible-role-jenkins#28

However, while the password could be encrypted via Hiera eyaml, once the groovy script is local on the Jenkins server (e.g. a template for init.groovy.d), it would be unencrypted there. Could this be run via CLI, and if so, would that keep the password from being stored unencrypted on the Jenkins server?

Alternatively, how much can the init.groovy.d scripts be locked down (i.e. do they have to be world readable)?

Note: this is a similar issue when dealing with LDAP authentication or anything else that has credentials. I don't know if the types / providers process handles it better - it very well might.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants