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

Improve security in team-concert plugin

    Details

    • Similar Issues:

      Description

      Our use case forces us to have several RTC connections configured in a Jenkins server. This means we can't always reuse the "default RTC connection" that is configured in the Global Jenkins configuration page.

      When using the job configuration, there are two options:
      a)Put the password in jenkins.
      b)Point to a password file in the Jenkins master.

      Both have downsides.
      a) The password can be viewed by everyone that has access to the job, by looking the html (see attachment).
      b) Passwords files are, per se, unsecured. Although they are obfuscated, they can be easily obtained by just showing the contents of the file. So basically anyone that has read access (or ability to configure/run a job). It also needs to be in the master, which makes it complex in a multi-tenant jenkins.

      To solve this, I can think of:
      -Add support for using credentials set up in credentials-plugin.
      -Add support for having several "default" RTC Connections that are configured in the jenkins global page. This page is only accessed by admins and easier to ACL.

      But I'm sure there are several security measures that can be implemented.

      Thanks in advance.

        Attachments

          Activity

          Hide
          hfraserdube Heather Fraser-Dube added a comment - - edited

          Thanks for the report and the suggestions. We had figured that access to the password file would be secured. We chose to have the password file only on the master because it felt like having it on the slaves would require a lot coordination when a password had to be updated.

          Does your organization make use of the credentials plugin? Are there other plugins that you use that also retrieve the passwords from it?

          I have raised a work item for this 295009: Improve security in Jenkins Team Concert plugin

          Show
          hfraserdube Heather Fraser-Dube added a comment - - edited Thanks for the report and the suggestions. We had figured that access to the password file would be secured. We chose to have the password file only on the master because it felt like having it on the slaves would require a lot coordination when a password had to be updated. Does your organization make use of the credentials plugin? Are there other plugins that you use that also retrieve the passwords from it? I have raised a work item for this 295009: Improve security in Jenkins Team Concert plugin
          Hide
          gabriel Gabriel Lopez added a comment -

          I see. In a way, it makes sense, but it would be nice to have the option. I suppose there are much better solutions though, so I don't consider reading password files from slaves a must.

          About credentials-plugin, I think it is the one that is filling the functionality gap in jenkins for centralizing password management. Until it, all plugins implemented its own password fields in their own way. Ideally this plugin can fill this gap and allow plugins to collaborate in terms of password management, in a secured way.
          See http://blog.cloudbees.com/2012/02/open-sourcing-credentials-plugin.html
          Recently, the Git plugin added support to it: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin
          Sadly, only a bunch supports it, but I think it will get better. The most common use case is using https://wiki.jenkins-ci.org/display/JENKINS/SSH+Credentials+Plugin

          That was just an idea though. In our case, either putting the password on jobs (that are shown in the html and are duplicated across jobs) and using password files (that are not that safe and we don't have OS access to the jenkins master [think like we are using it as a service]) is inconvenient.

          Thanks for the reply.

          Show
          gabriel Gabriel Lopez added a comment - I see. In a way, it makes sense, but it would be nice to have the option. I suppose there are much better solutions though, so I don't consider reading password files from slaves a must. About credentials-plugin, I think it is the one that is filling the functionality gap in jenkins for centralizing password management. Until it, all plugins implemented its own password fields in their own way. Ideally this plugin can fill this gap and allow plugins to collaborate in terms of password management, in a secured way. See http://blog.cloudbees.com/2012/02/open-sourcing-credentials-plugin.html Recently, the Git plugin added support to it: https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin Sadly, only a bunch supports it, but I think it will get better. The most common use case is using https://wiki.jenkins-ci.org/display/JENKINS/SSH+Credentials+Plugin That was just an idea though. In our case, either putting the password on jobs (that are shown in the html and are duplicated across jobs) and using password files (that are not that safe and we don't have OS access to the jenkins master [think like we are using it as a service] ) is inconvenient. Thanks for the reply.
          Hide
          hfraserdube Heather Fraser-Dube added a comment -

          In release 1.1.2 the team concert plugin now makes use of the credentials plugin. The userid and password are maintained by the credentials plugin instead.

          There is some manual migration required. You will need to create credentials for RTC and update the jobs to reference the credentials instead of the user/password/password file entered in the scm configuration.

          Show
          hfraserdube Heather Fraser-Dube added a comment - In release 1.1.2 the team concert plugin now makes use of the credentials plugin. The userid and password are maintained by the credentials plugin instead. There is some manual migration required. You will need to create credentials for RTC and update the jobs to reference the credentials instead of the user/password/password file entered in the scm configuration.

            People

            • Assignee:
              Unassigned
              Reporter:
              gabriel Gabriel Lopez
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: