Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-37581

Allow using environment variables for clientID and clientSecret

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • github-oauth-plugin
    • None
    • Dockerized Jenkins 2.7.2+ with github-oauth:0.24

      As title says, I would like to be able to use environment variables (for example ${GITHUB_OAUTH_CLIENTID}, ${GITHUB_OAUTH_CLIENTSECRET}) for configuring the GitHub OAuth application parameters. This would allow me to keep all secrets away from configuration files and instead keep them in environment variables where they can be managed more securely and effectively.

      For a bit more context, I've built a custom Dockerfile on top of the official Jenkins Docker image which includes useful configuration from a set of template files and as such, this of course includes the GitHub OAuth plugin's configuration which happens to live in config.xml's <securityRealm ... /> definition. Security wise it does not make any sense at all to bake in passwords to a Docker image and as this particular plugin does not support environment variables, I had to add a hack around the /usr/local/bin/jenkins.sh which uses sed to rewrite the config file just before Jenkins is actually started.

      As an additional note, enabling env variables would also bring the plugin closer to how eg. <workspaceDir ... /> and <buildsDir ... /> are configured. I also suspect there's a plethora of other plugins which would benefit from such unified behaviour but that would be a whole another effort to "encourage" all plugins to support password injection from environment variables.

          [JENKINS-37581] Allow using environment variables for clientID and clientSecret

          Sam Gleske added a comment -

          From what I've mostly viewed, Jenkins configuration in a Dockerfile is mounted via a Docker volume. Why bake configuration into the Docker image at all? It's something that is usually persistent.

          Sam Gleske added a comment - From what I've mostly viewed, Jenkins configuration in a Dockerfile is mounted via a Docker volume. Why bake configuration into the Docker image at all? It's something that is usually persistent.

          Esko Suomi added a comment - - edited

          We have per project[1] Jenkins clusters[2] so the base image is meant to be completely hands-off init no matter where and when its run, including localhost.

          EDIT: And yes, we have non trivial amount of team working on equally non trivial amount of things

          [1]: project meaning a single product family together forming a service, not a single Git repo or somesuch
          [2]: slaves done with JClouds family plugins

          Esko Suomi added a comment - - edited We have per project [1] Jenkins clusters [2] so the base image is meant to be completely hands-off init no matter where and when its run, including localhost. EDIT: And yes, we have non trivial amount of team working on equally non trivial amount of things [1] : project meaning a single product family together forming a service, not a single Git repo or somesuch [2] : slaves done with JClouds family plugins

          Sam Gleske added a comment -

          No worries, I was just curious. To this point I've mostly reviewed, merged, and released this plugin as people opened PRs. I would accept a change for this.

          Sam Gleske added a comment - No worries, I was just curious. To this point I've mostly reviewed, merged, and released this plugin as people opened PRs. I would accept a change for this.

          James Dumay added a comment -

          You can use GITHUB_OAUTH and GITHUB_ENDPOINT when https://github.com/jenkinsci/github-oauth-plugin/pull/63 is merged

          James Dumay added a comment - You can use GITHUB_OAUTH and GITHUB_ENDPOINT when https://github.com/jenkinsci/github-oauth-plugin/pull/63 is merged

          Sam Gleske added a comment -

          As noted in https://github.com/jenkinsci/github-oauth-plugin/pull/63 , it did not provide a fix for this issue during testing.

          Sam Gleske added a comment - As noted in https://github.com/jenkinsci/github-oauth-plugin/pull/63 , it did not provide a fix for this issue during testing.

          Sam Gleske added a comment -

          Esko, one workaround is you could bake in an $JENKINS_HOME/init.groovy.d init hook script which configures the GitHub OAuth plugin.

          You can use System.getenv('var') to get an environment variable. Then, reference the wiki because it documents how to write script console scripts.

          Essentially, rather than statically setting the XML configuration you can dynamically configure it on boot of Jenkins. I once presented on this topic.

          Sam Gleske added a comment - Esko, one workaround is you could bake in an $JENKINS_HOME/init.groovy.d init hook script which configures the GitHub OAuth plugin. You can use System.getenv('var') to get an environment variable . Then, reference the wiki because it documents how to write script console scripts. Essentially, rather than statically setting the XML configuration you can dynamically configure it on boot of Jenkins. I once presented on this topic .

            jamesdumay James Dumay
            esuomi Esko Suomi
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: