Hacker News new | ask | show | jobs
by manigandham 3199 days ago
All of the major clouds already have good secrets management built in. We have a simple library that uses Google's Key Management Service in a standalone project to encrypt/decrypt files held in a private storage bucket. Access to keys and files are controlled by service account roles. Seamless, efficient, no-ops model with built-in auditing and fine-grained control that works everywhere.
2 comments

This sounds way simpler and 10x better than what most organizations do (secrets in virsion control, secrets on local file system or environment variables). Do you mind doing a quick how-to? It could probably help 90% of organizations take a step towards better security.
Google actually has a technical how-to here: https://cloud.google.com/kms/docs/store-secrets and in-depth solution architecture here: https://cloud.google.com/kms/docs/secret-management

Key Management Service creates and maintains private keys for you and provides an API to easily encrypt or decrypt some data. Basically call method KMS.Decrypt("name_of_key_to_use", <bytes>) and get back decrypted content. Secrets are simple text files encrypted with KMS and stored in a private storage bucket. For example we have something like "database-secrets.dev.json.encrypted".

We have a small library that took a day to write, used in all of our projects that does the following on startup: open private storage bucket, download encrypted file, call the KMS API, decrypt the file, and parse the raw contents as json. Now the app has the secrets in-memory to be used anywhere. No infrastructure required, nothing on disk and this is universally accessible whether inside Google cloud or on local machine. Takes under 1 second when running in the cloud.

I dont think I can do better than the documentation but let me know if you have any questions.

AWS offers a similar service for anyone interested.

https://aws.amazon.com/kms/

You can limit access to the keys based on IAM instance profiles. So that only certain instances can access specific credentials.

Within a single cloud that provides every single service you need.
As stated, this works everywhere, whether on premise or inside a cloud provider. Key management and storage have public APIs, the only thing you need to access them is a service account key file which authorizes everything else.

Service accounts are necessary to run anything in GCP anyway but can be used externally (like the gcloud CLI on your desktop) or a similar setup specific to AWS or Azure if that's your primary provider.

Sorry I misread what you are saying, yes that is a nice basic setup, as the other reply mentions, better than what most orgs start with. That said, I don't think you should be so quick to poo-poo Vault as it provides a lot of very nice things in a fairly flexible package.
Didn't poo-poo Vault - just saying that there's a very good system already built in that involves wiring up just 2 API calls and integrates perfectly into the existing IAM security roles.