[JIRA] (JENKINS-37713) Support reading Vault Token from file on disk

[ja...@jasonantman.com (JIRA)]

Title: Message Title

Jason Antman created an issue   Jenkins / JENKINS-37713 Support reading Vault Token from file on disk Issue Type: New Feature Assignee: Peter Tierno Components: hashicorp-vault-plugin Created: 2016/Aug/26 11:44 AM Priority: Minor Reporter: Jason Antman Configuring a static Vault token in Jenkins is a relatively major violation of Vault's security model, which relies on finite-lived tokens and authentication. It also relies on the authentication process to limit token use (such as by CIDR block or timeframe). Using static tokens means that anyone who can somehow read that token from Jenkins configuration and use it outside of Jenkins. A trivial example of this is that anyone with access to the Script Console can simply run: Unable to find source-code formatter for language: groovy. Available languages are: actionscript, html, java, _javascript_, none, sql, xhtml, xml def desc = Jenkins.instance.getDescriptor("com.datapipe.jenkins.vault.VaultBuildWrapper") println(desc.authToken) And see the plaintext token. I'd like to recommend an alternative: A second configuration option for "Vault Token File", that points to a path on disk (either absolute or, easier, within JENKINS_HOME) that contains the token to use for Vault. Every time the Build Wrapper is run in a job, the contents of that file is read from disk, stripped of whitespace, and used as the token. A sidecar process (anything else running on the server) is responsible for writing that file. Since it's read as part of every build process, this makes it simple (both overall, and from the plugin's perspective, since all it needs to do is read the file) to have any other process on the system authenticate to Vault and write short-lived tokens (i.e. 1-5 minute lifetime) to that file. Especially given how Vault's authentication methods are changing, how many there already are, and how complicated some of them can be, this allows the user to manage the out-of-band token provisioning mechanism, while still maintaining the possibility of having short-lived tokens. Add Comment   This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.