161–170 of 246 posts
https://www.vaultproject.io/ We use Hashicorp's Vault product to manage SSH credentials, TLS certificates, as well as application secrets across thousands of users, tens of thousands of virtual machines, and hundreds of applications. We pay for the enterprise version, but the free version is more than capable for most needs. Avoid a password manager if you can, it leads to poor security practices and availability iss…
If you run on kubernetes it has first class support for secrets [0]. You can reference secrets in environment variables, or mount them as files in your containers. [0] https://kubernetes.io/docs/concepts/configuration/secret/
Utilized globally by individual developers, large enterprises such as JP Morgan & Chase[1], and integrated into the KMS services such as Google Cloud[2].
1. https://venturebeat.com/2019/02/27/ionic-security-raises-40-...
2. https://cloud.google.com/blog/products/identity-security/clo...
Earlier quoted context omitted.
This just pushed the problem further down the stack. You should have keys to unlock vault when it is restarted. How do you secure those keys?
I can't seem to understand how a "secrets manager" helps things. Could someone who does ELI5 why it's better than a config file with permissions locked down?
A typical deployment might involve placing the manager on a secure host that has access to generate and rotate keys, for example.
The manager can then configured to re-generate keys and vend them on-demand to instances that need require them. You can configure these keys with very limited access, and also make them expiring.
The manager then becomes effectively a keystore that can never export master keys, but only vends out some limited-scope keys to other instances.
Other instances would have to authenticate using some pre-configured host keys or even be authenticated directly though the cloud provider.
If your instances are compromised, the worst someone can do is to get access to a limited-scope key that will expire.
Hopefully you have other measures in place that would prevent and detect someone from just sitting on an instance and sucking up all your data and exporting them.
Someone at my company generated the keys. They then put them on a network share without any security restrictions. They've been there for 5 years with no rotation. At least 2 are checked into source control.
Earlier quoted context omitted.
It makes sense at scale. If you are a company of two there are probably better solutions. At scale, you can very granularly define policies for each secret. When a secret is accessed, it is done so through a user or application identity. Each access is also logged.
So then how do you manage the secret that authenticates an application's identity? And what good is the logging if after an application has the secret it can do whatever it wants with it?
you should only let the instance access the secret it requires.
https://www.vaultproject.io/ We use Hashicorp's Vault product to manage SSH credentials, TLS certificates, as well as application secrets across thousands of users, tens of thousands of virtual machines, and hundreds of applications. We pay for the enterprise version, but the free version is more than capable for most needs. Avoid a password manager if you can, it leads to poor security practices and availability iss…
"Disclosure", not "disclaimer".
I am curious how you managed to restore it if you lost the keys.
"accidental" backups
I don't know your company size but we use stackoverflow's blackbox. It's very nice because you can check in the repo into version control. You can add and remove users on the fly as well.