4 ms·

it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets. while developers can move a

by slt2021 2y ago

it might be easier to just store and checkout a single decryption key that only devops people know, vs storing hundreds of secrets. while developers can move around their .env file across systems without worrying that they left plaintext secrets somewhere. also it allows adding new secrets without knowing decryption key - I think it is important for collaboration also most importantly: plaintext decrypted secrets are never stored on disk, and only kept in memory. I think it is also an improvement towards the regular doting

cyberax 2y ago
> it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets without knowing decryption key - I think it is important for collaboration So basically, you want developers (who don't have access to prod) to add random properties that your peers can't see during the code review? Ok... Sorry, there's just no way the encrypted secrets in git are a good idea for general-purpose software.
- slt2021 2y ago
  encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea? like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that allow reading file from disk, don't exist?
  - cyberax 2y ago
    > encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk No. They are NOT. They are strictly worse than unencrypted data. Unecrypted data is at least honest. Simply encrypting it and putting the key next to the data itself creates a dangerous illusion of security. > like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? Put secrets into your environment, don't store them on the disk. If your code runs on AWS, then use AWS SSM or AWS Secrets Manager. If it's on Heroku, put secrets into the env vars. K8s has a secret manager. And so on.

cyberax 2y ago

> it might be easier to just store and checkout a single decryption key that only devops people know, "Devops people know" means that the key must be some secret property. Or you need to use the key during the deployment artifact building pipeline, and then deploy the artifacts with clear-text secrets. > vs storing hundreds of secrets. Then serialize them to JSON or whatever. > also it allows adding new secrets without knowing decryption key - I think it is important for collaboration So basically, you want developers (who don't have access to prod) to add random properties that your peers can't see during the code review? Ok... Sorry, there's just no way the encrypted secrets in git are a good idea for general-purpose software.

slt2021 2y ago
encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk - I dont understand why you make it seem like it is a bad idea? like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? as if directory traversal, path injection vulnerabilities, shell command injection, etc vulns that allow reading file from disk, don't exist?
- cyberax 2y ago
  > encrypted secrets are strictly an improvement over status quo of unencrypted secrets on disk No. They are NOT. They are strictly worse than unencrypted data. Unecrypted data is at least honest. Simply encrypting it and putting the key next to the data itself creates a dangerous illusion of security. > like what is the alternative you propose? storing plaintext secrets on disk and hope that your runtime is secure and hardened enough and free from vulnerabilities?? Put secrets into your environment, don't store them on the disk. If your code runs on AWS, then use AWS SSM or AWS Secrets Manager. If it's on Heroku, put secrets into the env vars. K8s has a secret manager. And so on.