Fail when sensitive or secret data is provided via the config
tyrannosaurus-becks opened this issue · 5 comments
Hi @issacg - first of all, thank you for writing this! It's really cool.
What do you think about adding something that would cause this application to fail if it were fed high-entropy strings that look like sensitive or secret data?
The reason I ask is - if sensitive values live in a config file outside of Vault, it breaks Vault's promises around being able to encrypt all important data, audit access, roll secrets, etc. Mainly because those secrets won't live only inside Vault anymore.
Like for instance, suppose somebody had a config file with an AWS secret key in it so it could be fed into Vault to configure the AWS auth plugins. Now that secret would live both in the config and in Vault.
However, if the application failed on high-entropy strings like that with some message like, hey, you shouldn't put these in config files, that would be really good and could save people from a costly leak via their config.
Anyways, I'm really excited about this tool! Thank you for writing it! Looking forward to hearing your thoughts!
Hey @tyrannosaurus-becks , thanks for the feedback!
On the one hand I like the idea of warning the users - it seems like a really useful feature on the surface. On the other hand, I feel even more compelled not to make the damage potential (of storing plaintext passwords) even worse (I say this thinking of edge cases like CVE-2018-19786.
Even if we don't leak the password itself, we could be putting up a neon sign for potential attackers, to find secrets knowing exactly where in the config it is. I also don't see any real scenario where an operator would be using software like this and accidentally including secrets in plaintext.
Plus, adding detection of "high-entropy" strings is iffy in it of itself. Who's to say what's high entropy. And who's to say that passwords in plaintext are necessarily even supposedly high entropy, and not default "admin/admin" style credentials.
Do you have any solid use cases to back this issue up, or is it just a wistful "Wouldn't it be cool if... ?" feature request?
Either way, thanks for the feedback - it's definitely a nice idea!
Hi Issac! Well, the Terraform Vault Provider is similar in design because it takes a Terraform config and sets up a Vault instance. It currently takes sensitive values such as an AWS key and password. We are unfortunately aware that the sunny path for users does encourage them to store these sensitive values in plain text, yet if they do so, it breaks Vault's Threat Model, which considers there to be an internal threat. Vault aims to be able to guarantee that secrets are encrypted, and to be able to produce an audit log of who viewed what secret when, and to be able to roll secrets. When secrets also live outside Vault in plain text, then Vault only gives the illusion of having these abilities.
I don't know if that makes sense. But we've been talking a lot about removing the ability for secrets to be provided in config for the Terraform Vault Provider because of how it breaks Vault's threat model. We will still support other config, just not that because we don't want users to shoot themselves in the foot.
Anyways, it's up to you what you want to do, I just wanted to share the security risk we've encountered there.
To be clear, I wasn't attacking the idea - I completely agree with what you're saying about breaking Vault's threat model. I'm just not sure that the proposed solution wouldn't make more new problems than it solves. It's hard to be totally idiot-proof and when one tries to be, it only gives a false sense of security if one doesn't do a perfect job of it.
But I've been thinking on it a bit... What may make more sense, for both projects, is rather than trying to detect secrets, maybe we can come up with a list (as a 3rd project, so it can be updated independently) of well known API points that expect a secret, and we can try to alert and/or quit if one of those points are hit.
I'd especially be enthusiastic about that idea if you could back it wearing a HashiCorp hat, and not just a personal hat... What do you think of that idea?
We're probably going to take a different route with the Terraform Vault Provider because there are additional factors. It's still under discussion internally.
Maybe we can come up with a list (as a 3rd project, so it can be updated independently) of well known API points that expect a secret.
On that, we have released support for OpenAPI and we intend to add a way to mark the returned fields as "Sensitive", which could be used for what you describe. If so, do you think you'd use it? If so I could open an issue tracking that and link it here.
Realized that I never got back to you on this. I've run out of cycles for now, but would be happy to look at this once the sensitive support is in. It sounds like what I had in mind in not second guessing user inputs.