0

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?

Anders
  • 64,406
  • 24
  • 178
  • 215
Nathan Basanese
  • 640
  • 1
  • 9
  • 20
  • // , I'd have gone with MSI (https://www.vaultproject.io/docs/secrets/azure/index.html#authentication), except for the whole dedicated hardware thing. Not sure if MSI can work on non-Azure resources. MSI-->VM docs: https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm – Nathan Basanese Jan 11 '19 at 01:04
  • // , https://stackoverflow.com/a/4136344/2146138 seems to suggest that, assuming only Vault's user can read the `vault.hcl` configuration file, using environment variables isn't that much more secure than putting the tenant and client IDs into the configuration file. – Nathan Basanese Jan 11 '19 at 01:08
  • 1
    What's with starting all your posts with `// ,` ? – Mike Ounsworth Jan 11 '19 at 01:22

1 Answers1

2

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.

Connor Peoples
  • 1,421
  • 5
  • 12
  • // , 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 https://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 https://www.anjuna.io. – Nathan Basanese Jan 11 '19 at 02: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 – Nathan Basanese Jan 11 '19 at 02: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? – Nathan Basanese Jan 11 '19 at 02: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. – Connor Peoples Jan 11 '19 at 02: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. – Connor Peoples Jan 11 '19 at 02:19
  • Nitpick: under the now widely implemented Bern convention your answer is automatically coprighted, but under Stack's mandatory licensing (CC-BY-SA) it is editable and reusable :-) – dave_thompson_085 Jan 18 '19 at 04:38