CI/CD Pipeline with Vault

[Kay A]

Hello
Can you outline the use case of vault in CI/CD Pipeline ?

How would be it useful in Dev Ops model ?

For eg : How can jenkins or bamboo use Vault ? in order to authenticate to Vault, jenkins or bamboo will need password and that need to be stored somewhere right ? then isnt it defeating the purpose ?

Thanks!

[David Adams]

Vault provides means to bootstrap authentication that are better than simply storing a password on disk. If you use AWS, the EC2 auth is an excellent tool. But even if you do do a simple stored-password authentication, Vault can still provide a lot of tools for CI workflows.

For example, the initial authentication can be handled by a privileged user that can then create and provide time/use/policy-limited tokens to each type of CI job that provides only the permissions required by that job, to ensure that secrets do not leak between job types.

Vault also provides means for dynamic secret creation for DB credentials, SSH creds, AWS creds, and more. These credentials are time-limited and Vault logs their creation and destruction for audit purposes. This is a far better solution for a CI/CD environment than static credentials, no matter where they're stored.

-dave

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/d7182e07-9846-4137-b36d-aeae21126c34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jason Antman]

The general use case is pretty clear: many people currently have secrets (passwords, API keys/tokens, etc.) hard-coded somewhere, whether it's in their actual source code repositories, build scripts/tooling, or just dumped into environment variables or build configuration in their CI system. That's bad for a number of reasons, mainly because (1) it's very likely to allow disclosure of secrets to unauthorized parties (i.e. see tools like gitrob), (2) it's pretty much impossible to audit use of the secrets, as anyone who can read the code/config can get them, (3) it's very painful to change them, as that most likely requires searching large amounts of code or config for the actual secret, and (4) those secrets are generally static or not rotated often, so disclosure of them even days, weeks or months after a job is run can yield unauthorized access.

For Jenkins, there's a Vault plugin: https://wiki.jenkins-ci.org/display/JENKINS/HashiCorp+Vault+Plugin

It currently takes a statically-configured token, which is very bad security practice from a Vault perspective; we have an issue open, apparently slated for the next release, to support reading the token from a path on disk, such as the file written by HashiCorp's (Enterprise) Vault Secure Introduction (VSI) client.

Dave's comment was right-on, as was his mention of EC2 Auth. What we're currently doing is running an EC2 Auth client on the instance that runs Jenkins, and having a Groovy script (via a Scriptler scheduled job) read the Vault token from a file on disk every few minutes, and populate it into the Vault Plugin configuration.

Authenticating Vault clients (a.k.a. the "first secret" problem) is largely dependent on the underlying platform (EC2 Instance vs Docker vs something else), but there are many solutions out there, both suggested by HashiCorp (or implemented by them, like the VSI client) or by the community on this list.

-Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAN3s8zY%3Dpys3Cz08GqiTFTKXo4rMXyvRjXYaK2Md-g%2BTaW-twQ%40mail.gmail.com.