Accessing Vault from Jenkins

2,443 views
Skip to first unread message

Chris

unread,
Feb 23, 2016, 7:59:11 PM2/23/16
to Vault
Hi all,

We're working on implementing Vault for pulling credentials in during build time but we're running into many conversations/debates about what is the best method for accessing Vault from Jenkins. I know the default answer for this is "use app-id" but to us it still doesn't solve the problem of having credentials stored locally to the system, that when found, would give an attacker access to Vault. Even if you salt the app-id credentials, you still have to store that salt somewhere. This is very much a philosophical question but I thought I would ask it to the community and to the Hashicorp folks that monitor this group (thank you btw).

Our current iteration is to use an LDAP service account to auth to Vault as the first step of the build and then use the token returned to pull secrets. The problem being that the service account username and password are stored on Jenkins and could be discovered.

So, how are you solving this? What method worked?

Thanks!

Jeff Mitchell

unread,
Feb 24, 2016, 11:07:11 AM2/24/16
to vault...@googlegroups.com
Hi Chris,

Secure introduction is always tough, and you're right: credentials
stored locally in Jenkins are subject to whatever protections you can
put into Jenkins.

I don't know much about what Jenkins can provide in terms of secure
storage, but you may want to think about pushing a token into Jenkins
rather than hardcoding information for Jenkins to use for
authentication. That way if the token is compromised, it can be
revoked, and it's only valid for the duration of the token anyways.

Obviously, ensure that Jenkins' token has the minimum permissions (via
policies) required!

--Jeff
> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/8f198dd6-3274-4a92-9065-31963c7c948d%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Chris

unread,
Feb 24, 2016, 4:54:56 PM2/24/16
to Vault
Hi Jeff,

Thank you for your reply. That makes sense and is something we're working to achieve. I know it can be done any number of ways, but landing on the right one is proving pretty tough. At this point I'm thinking of some cronjob that runs on a VM that generates tokens and pushes them via SSH to the Jenkins machines. That doesn't feel very elegant and adds another system to manage. Besides that, is there any other options out there?

-Chris

Jeff Mitchell

unread,
Feb 24, 2016, 8:54:34 PM2/24/16
to vault...@googlegroups.com
Hi Chris(topher H, love the email address),

There are some solutions that I know are being worked on by the
community, and a few things that we are working on internally. Secure
introduction is the hardest part of using Vault (or any other similar
system) because it's so highly dependent on your particular
combination of platforms, services, and applications. For instance,
within a couple of releases there will be support within Nomad for
serving up Vault tokens to tasks it is managing, but that doesn't help
the Mesos users out there. There is likely to be some first-class AWS
support coming soon, but that doesn't help the GCE users out there.
Etc.

The best thing I can point to right now is more a paradigm/food for
thought (https://hashicorp.com/blog/vault-cubbyhole-principles.html).
This may provide some ideas as to implementing a mechanism that works
for your internal systems. One thing I do want to point out is that
Cubbyhole is especially designed for cases where you don't really have
a secure way to transfer an initial secret (either because it's over
an unencrypted connection or because it is likely to be logged if it
is e.g. put in a Docker environment variable). Since you can use SSH
the former doesn't apply, and if the latter doesn't, you may find it
easiest to just code a tiny service that can drop a Vault token onto a
ramdisk on the Jenkins machine and have Jenkins poll for a value
there.

Best,
Jeff
> https://groups.google.com/d/msgid/vault-tool/20114c4b-743e-412b-9d4e-a435db648168%40googlegroups.com.

Chris

unread,
Mar 1, 2016, 4:54:20 PM3/1/16
to Vault
Thanks Jeff. We decided to keep things simple and go the app-id route and manually transfer over the user_id. It's cumbersome but since the app-id won't expire, it's not too bad to do it one time for each Jenkins server.

Thanks for your help!

Patrick van der Velde

unread,
May 25, 2016, 5:22:44 PM5/25/16
to Vault
Hi Chris

Just out of curiosity. Is the work you're doing to integrate Jenkins and Vault planned to be made public? I too would love to have a credential manager that integrates with Vault.

Regards

Petrik

Victor Hernandez

unread,
Jun 24, 2016, 11:02:16 AM6/24/16
to Vault
Hi Chris. Same here. There is a github repo or gists where I could see your idea. I'm looking for some vault - jenkins integration.

Thanks. 
Reply all
Reply to author
Forward
0 new messages