Integrate JumpCloud’s Cloud LDAP with Hashicorp Vault

Wondering how to close the gaps between your engineers privileged IDs and countlessly secrets with ease of mind? This one is for you.

The Pain

Are you constantly riding on a rollercoaster — IAM auditing with a drastically growing engineering/business flee, where countless secrets have been created daily?

I’m with you wholeheartedly.

So just listing down a few of my pain points here, something surely we have in common :-)

• Shared service accounts, multi-purposed, and probably abused.
• Shared privileged accounts / API keys / tokens — of cause unnamed.
• Oprah API keys / tokens with blank descriptions.
• Don’t-know-when expired certs.
• Unmanaged self-issued certs.
• Etc etc etc etc…

A list I can go on for days 😂.

So How (to ease the pain)?

Well, I do have a cloud-based IdP — JumpCloud which offers LDAP as a Service, which helped me reduce the overhead of having a core directory massively.

And I came across Vault — A solution designed precisely to address the secret management pain.

So by linking these 2 together you will achieve:

• Authorising the only designated personnel with his/her hands on a managed box, drawing the keys to access the production assets with full-auditable trace logged.

In a Nut Shell

The Steps

TL;DR

You may check out my Github repo for a jump-start.

You will need:

• A JumpCloud Tenant — You can register for free.
• A Linux box for Vault server installation — I use Vagrant in this case.

On JumpCloud:

1. Create an LDAP binding account on JumpCloud.
2. Create the desired LDAP groups, add the respective users.

On Vagrant:

1. Clone my repo and run:

vagrant up && vagrant ssh

2. Run line-by-lines in vault_jc_ldap.sh. Fill in your own JumpCloud OrgID, LDAP bind account name and password.

3. You will get this message once logged in successfully via LDAP:

Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.
Key                    Value
---                    -----
token                  <>
token_accessor         <>
token_duration         768h
token_renewable        true
token_policies         ["default" "systems_rw"]
identity_policies      []
policies               ["default" "systems_rw"]
token_meta_username    vault.sys_rw

4. Now you can create your first secret and switch between different LDAP users — i.e. the read-only user should not be able to make changes to the secret, but is able to read the key value.

vault kv put secret/hello foo=world
vault kv get secret/hello

5. Now you can ride on with Vault to dynamically manage your production secrets.

Have fun!