Say I set up a HashiCorp Vault, on dedicated hardware, with an AKV seal stanza like the following:

seal "azurekeyvault" {
  tenant_id      = "46646709-b63e-4747-be42-516edeaf1e14"
  client_id      = "03dc33fc-16d9-4b77-8152-3ec568f8af6e"
  client_secret  = "DUJDS3..."
  vault_name     = "hc-vault"
  key_name       = "vault_key"

I'm putting privileged Azure information in plaintext configuration parameters in the HashiCorp Vault configuration file (/etc/vault.d/vault.hcl).

For Linux OS nodes on dedicated hardware, that are not deployed in Azure, how do I reduce or ameliorate this specific source of vulnerability?


1 Answer 1


Reading your post, I think I understand your ask. You've already taken a great step of securing your credentials within a vault, but now you're concerned that the API credentials that allow you to secure your vault may be at risk since they are stored in clear text within a configuration file. The reality is that you will never likely get a solution that really eliminates some single point of failure that needs to be protected. The best you can do in situations like this is make it difficult for the attacker and go from there.

So the vulnerability that you are trying to manage assumes the following.

  • Your attacker has direct access to your file system
  • Your attacker has credentials to change file permissions
  • Your attacker is smart enough to know about Hashi Vault
  • Your attacker wants your credentials

The first assumption is probably the first major flag that you should notice in a secure environment. If someone is accessing your server files, that's a pretty major issue that needs to be looked at. There are also many ways you can control what people see through CHMOD, CHROOT, etc.

Now, the second assumption takes the first and says they not only have access to the server, but they have root/sudo priveleges. This is a major step of compromise and it means any native tools you could build into the server can be overwritten or reverse engineered. At this point you can't remediate the vulnerability because you've really lost the keys to your house already.

Steps three and four, once assumption two are complete are fairly straight forward. They can start to write application and API calls to glean credentials and harvest what they need. But, what's more likely is they'll go after any data they can fetch and then move onto their next target.

So, is it a potential vulnerability. Yes. Is it the highest priority vulnerability? No. Configure the best you can to the community best practices and keep your system safe from attackers and you should be golden. This is a last defense type vulnerability that's more like sending one or two guys in front of the hordes of Mordor and not having the hope of Frodo and Sam coming to save the day. It's pretty dismal.

  • // , Thanks for putting the vulnerability into context, and going above and beyond to define assumptions about the vulnerability for me Connor. A lot of what you've mentioned jives with the learn.hashicorp.com/vault/operations/production-hardening. I'm hoping to go beyond those recommendations, though. One idea I'm toying with is stashing the *_id values into locked memory protected by something like anjuna.io. Commented Jan 11, 2019 at 2:12
  • // , "sending one or two guys in front of the hordes of Mordor", eh? I'm going to have to use that one in my next arch meeting Commented Jan 11, 2019 at 2:14
  • // , BTW, wrt "securing your credentials within a vault," these are actually credentials used by the Vault, as part of how it uses AKV as a mechanism for securing its own Master Encryption Key. Do you mind if I edit your answer a bit? Commented Jan 11, 2019 at 2:15
  • 1
    It is not copyrighted, so have a blast! And if you can figure out how to prevent Root from performing attacks that would be awesome. One thing that comes to mind is actually from macOS. Apple has created a layer of security at the kernel layer that cannot be tampered with from Root. You must first get into the boot configuration settings and disable System Integrity Protection. To my knowledge, Linux does not have this natively, but would be the answer. Commented Jan 11, 2019 at 2:17
  • 1
    Yeah, editing my answer is fine. I realize the seal is a way to retrieve the KEK from a KMS to unencrypt the master key for Hashi. But this could definitely be more clearly defined for other readers. Commented Jan 11, 2019 at 2:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .