How do I protect the Azure Client ID and Client Secret in HashiCorp Vaults with AKV Auto-Unseal?

Question

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?

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.