4 ms·

Sorry. I'm really not sold that this is suitable for applications to use. The core problem to secrets management is service identity. Managing encrypted data i

by ejcx 9y ago

Sorry. I'm really not sold that this is suitable for applications to use. The core problem to secrets management is service identity. Managing encrypted data is not hard, it's actually really easy. It's the identity that is hard. You're just trading out all of my secrets for a new secret. This works for password managers because I remember one password, but doesn't work for applications because you still end up with this env key baked in to source code...

danenania 9y ago
No problem, I'm happy to address concerns. You're right that the ENVKEY still needs to be protected. There is no getting around the need store and protect some sort of key. You definitely should not be keeping it in source code--it should be set in a gitignored .env file (in development) or as a server environment variable (in staging/CI/production). It's true that you are essentially trading out multiple secrets for a single one, but there are a number of major benefits to doing this, both for security and ops. 1 - It's much easier/quicker to cut off access. 2 - It's much easier/quicker to rotate secrets when they need to change. 3 - It makes it trivial for developers and sys admins to get access to the latest secrets so they don't resort to sharing over email, Slack, etc. in order to get their work done. 4 - You don't have to worry about keeping secrets in sync when they're stored outside of source control. In my experience, this is a frequent cause of bugs, and it slows down development. I would also have to disagree somewhat that managing encrypted data isn't hard. Just encrypting data and sending around public keys isn't particularly hard, but unless you are implementing your own web of trust logic to verify that public keys are authentic, you are leaving yourself open to all kinds of man-in-the-middle attacks. EnvKey does the hard work on this.
- ejcx 9y ago
  You're just moving the problem around... Access isn't "cut off" by revoking an env key. The actual secret has not changed. I think, just like vault, this is missing the point wrt secrets management for services. Sorry to be the negative nancy but this is something I've spent a lot of time on and feel pretty strongly about.
  - danenania 9y ago
    I see your point, but using EnvKey also removes storing plain text copies of secrets as a default step in the workflow, so after you revoke an ENVKEY, it's a lot less likely that copies are still floating around. Of course, in the event that you're worried about this, you still need to assume that copies could have been made, so you still have to rotate any secrets that could have been exposed. EnvKey makes that process a LOT faster as well, and speed can be crucial in the case of a compromise. In short, while EnvKey doesn't solve every conceivable issue with managing secrets securely, and still requires some common sense, I think it does offer a drastically better default workflow for companies that are currently sharing secrets on email or slack, keeping them in git, etc.
  - xnxn 9y ago
    > just like vault As a happy Vault user I'm curious about your thoughts here.

by ejcx 9y ago

danenania 9y ago

No problem, I'm happy to address concerns. You're right that the ENVKEY still needs to be protected. There is no getting around the need store and protect some sort of key. You definitely should not be keeping it in source code--it should be set in a gitignored .env file (in development) or as a server environment variable (in staging/CI/production). It's true that you are essentially trading out multiple secrets for a single one, but there are a number of major benefits to doing this, both for security and ops. 1 - It's much easier/quicker to cut off access. 2 - It's much easier/quicker to rotate secrets when they need to change. 3 - It makes it trivial for developers and sys admins to get access to the latest secrets so they don't resort to sharing over email, Slack, etc. in order to get their work done. 4 - You don't have to worry about keeping secrets in sync when they're stored outside of source control. In my experience, this is a frequent cause of bugs, and it slows down development. I would also have to disagree somewhat that managing encrypted data isn't hard. Just encrypting data and sending around public keys isn't particularly hard, but unless you are implementing your own web of trust logic to verify that public keys are authentic, you are leaving yourself open to all kinds of man-in-the-middle attacks. EnvKey does the hard work on this.

ejcx 9y ago
You're just moving the problem around... Access isn't "cut off" by revoking an env key. The actual secret has not changed. I think, just like vault, this is missing the point wrt secrets management for services. Sorry to be the negative nancy but this is something I've spent a lot of time on and feel pretty strongly about.
- danenania 9y ago
  I see your point, but using EnvKey also removes storing plain text copies of secrets as a default step in the workflow, so after you revoke an ENVKEY, it's a lot less likely that copies are still floating around. Of course, in the event that you're worried about this, you still need to assume that copies could have been made, so you still have to rotate any secrets that could have been exposed. EnvKey makes that process a LOT faster as well, and speed can be crucial in the case of a compromise. In short, while EnvKey doesn't solve every conceivable issue with managing secrets securely, and still requires some common sense, I think it does offer a drastically better default workflow for companies that are currently sharing secrets on email or slack, keeping them in git, etc.
- xnxn 9y ago
  > just like vault As a happy Vault user I'm curious about your thoughts here.