- Notifications
You must be signed in to change notification settings - Fork34
auto-unseal utility for Hashicorp Vault
License
lrstanley/vault-unseal
Folders and files
Name | Name | Last commit message | Last commit date | |
---|---|---|---|---|
Repository files navigation
HashiCorp Vault provides a few options for auto-unsealing clusters:
- Cloud KMS (AWS, Azure, GCP, and others) (cloud only)
- Hardware Security Modules with PKCS11 (enterprise only)
- Transit Engine via Vault (requires another vault cluster)
- Potentially others
However, depending on your deployment conditions and use-cases of Vault, some ofthe above may not be feasible (cost, network connectivity, complexity). This maylead you to want to roll your own unseal functionality, however, it's not easy todo in a relatively secure manner.
So, what do we need to solve? We want to auto-unseal a vault cluster, by providingthe necessary unseal tokens when we find vault is sealed. We also want to make surewe're sending notifications when this happens, so if vault was unsealedunintentionally (not patching, upgrades, etc), possibly related to crashing ormalicious intent, a human can investigate at a later time (not 3am in themorning).
The goal for this project is to find the best way to unseal vault in a way thatdoesn't compromise too much security (a good balance between security and ease ofuse/uptime), without the requirement of Vault Enterprise, or having to move to acloud platform.
We do this by running multiple instances of vault-unseal (you could run oneon each node in the cluster). Each instance of vault-unseal is given a subsetof the unseal tokens. You want to give each nodejust enough tokens, thatwhen paired with another vault-unseal node, they can work together to unseal thevault. What we want to avoid is giving a single vault-unseal instance enoughtokens to unseal (to prevent a compromise leading to enough tokens being exposedthat could unseal the vault). Let's use the following example:
Explained further:
cluster-1
consists of 3 nodes:node-1
node-2
node-3
cluster-1
is configured with 5 unseal tokens (tokensA
,B
,C
,D
,E
), butonly 3 are required to unseal a given vault node.- given there are 3 nodes, 3 tokens being required:
- vault-unseal on
node-1
gets tokensA
andB
. - vault-unseal on
node-2
gets tokensB
andC
. - vault-unseal on
node-3
gets tokensA
andC
.
- vault-unseal on
With the above configuration:
- Given each vault-unseal node, each node has two tokens.
- Given the tokens provided to vault-unseal, each token (
A
,B
, andC
), thereare two instances of that token across nodes in the cluster. - If
node-1
is completely hard-offline, nodesnode-2
andnode-3
should haveall three tokens, so if the other two nodes reboot, as long as vault-unseal startsup on those nodes, vault-unseal will be able to unseal both. - If
node-2
becomes compromised, and the tokens are read from the configfile (note: vault-unsealwill not start if the permissions on the file aren't600
), this will not be enough tokens to unseal the vault. - vault-unseal runs as root, with root permissions.
Check out thereleasespage for prebuilt versions.
$docker run -it --rm ghcr.io/lrstanley/vault-unseal:master$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.7.0$docker run -it --rm ghcr.io/lrstanley/vault-unseal:latest$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.6.0$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.5.1$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.5.0$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.4.1$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.4.0$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.3.0$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.2.4$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.2.3$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.2.2$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.2.1$docker run -it --rm ghcr.io/lrstanley/vault-unseal:0.2.0
Note that you must haveGo installed (latest is usually best).
git clone https://github.com/lrstanley/vault-unseal.git && cd vault-unsealmake./vault-unseal --help
The default configuration path is/etc/vault-unseal.yaml
when usingdeb
/rpm
.If you are not using these package formats, copy the example config file,example.vault-unseal.yaml
, tovault-unseal.yaml
. Note, all fields can be providedvia environment variables (vault-unseal also supports.env
files).
$ ./vault-unseal --helpUsage: vault-unseal [OPTIONS]Application Options: -v, --version Display the version of vault-unseal and exit -l, --log-path=PATH Optional path to log output to -c, --config=PATH Path to configuration file (default: ./vault-unseal.yaml)Help Options: -h, --help Show this help message
- add option to use vault token/another vault instance to obtain keys (e.g. as long the leader is online)?
- memory obfuscating/removing from memory right after unseal?
- ❤️ Please review theCode of Conduct forguidelines on ensuring everyone has the best experience interacting withthe community.
- 🙋♂️ Take a look at thesupport document onguidelines for tips on how to ask the right questions.
- 🐞 For all features/bugs/issues/questions/etc,head over here.
- ❤️ Please review theCode of Conduct for guidelineson ensuring everyone has the best experience interacting with thecommunity.
- 📋 Please review thecontributing doc for submittingissues/a guide on submitting pull requests and helping out.
- 🗝️ For anything security related, please review this repositoriessecurity policy.
MIT LicenseCopyright (c) 2018 Liam Stanley <liam@liam.sh>Permission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the "Software"), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included in allcopies or substantial portions of the Software.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THESOFTWARE.
Also locatedhere
About
auto-unseal utility for Hashicorp Vault