3 ms·

this is mostly about not using .env files

diggan 2y ago
I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?
- stackskipton 2y ago
  SRE here, most of time when that happens, it's people leaving .env in git where it's not ignored and build process just does COPY * * to runtime environment. EDIT: Or it's just small time developers who don't care about security and ship whatever works.
  - deleted 2y ago
    [deleted]
  - hinkley 2y ago
    Hidden files get checked/built in all the time. Too many people don’t think to look for them.
    - cwbriscoe 2y ago
      That is why I like "Allow Listing" in my .gitignore file. Much harder to add stuff by accident. # Ignore everything * # But not these files... !/.gitignore !*.go !go.sum !go.mod
      - hinkley 2y ago
        I do the same. But as I do it my mental image of myself is of someone holding their nose and typing one handed. It’s the least shit solution, but it’s definitely a shit solution. Npm has another way to default exclude but I don’t think git does, and if docker got one I don’t recall what it is.
  - diggan 2y ago
    > it's people leaving .env in git Ah, makes sense it could get exposed then. The pattern I've always followed is having `.env.template`, `.env.dev` or similar in SCM, then require the development setup to manually/automatically copy it to `.env`, which is .gitignore'd. Seems that pattern might not have been as widespread as I thought :)
- 0cf8612b2e1e 2y ago
  I bet many .envs have been mistakenly shipped to production. I will continue to use .envs. The alternatives invoke much more friction.
- vinnymac 2y ago
  Encrypting dotenv files is a thing, I would even say it has become popular! https://dotenvx.com https://dotenvx.com https://github.com/getsops/sops https://github.com/getsops/sops
  - theozero 2y ago
    also check out https://dmno.dev/docs/plugins/encrypted-vault/ https://dmno.dev/docs/plugins/encrypted-vault/
  - nunez 2y ago
    And it's super easy to do. I used GPG with a passphrase before I adopted sops and PGP keypairs. Just make sure that you gitignore the plain-text dotenv. That's the hard part (on a team)
jonathanlydall 2y ago
Yes, not so much about environment variables which can be injected by your hosting environment which as far as I know shouldn’t really be an issue (assuming your hosting environment sources them securely).
xp84 2y ago
Yes! And they make an okayish point that especially on an infinite timescale, some noob developer (or a genius but fallible experienced engineer) will commit a .env file to source control, creating an inadvertent data disclosure that nobody wants. The thing is, in a properly run engineering organization, zero developers should have any production secrets to put into .env files in the first place. Development secrets should always be either dummy values created for this purpose (e.g. one's local development database password should be nothing or 1234 or something because you need no 'security' on a local DB that listens on 127.0.0.1 only), or the keys to entirely separate testing environments, developer sandboxes, and free-tier accounts on your 3rd party dependencies (e.g. an identity provider, Salesforce, etc.) I'd be uncomfortable with any .env files anywhere having creds in them that I would be upset about someone accidentaly posting even in our public repositories. Sure I'd rotate them just because I don't want someone poking around our local developer Auth0 account or local developer OpenAI account, but there should be zero or close to zero of value that's possible to exploit using those secrets. At my company we've settled on dotenvx to manage these .env files, which has the neat feature of asymmetric encryption so that 99.9% of the time devs don't even need the private key for the production one because adding a new value for a new thing can be done with the public key. Values that are actually secret are encrypted in the env file, and the correct private key for the environment is passed to the app as an env var, which it uses to decrypt any encrypted values. As others have pointed out, many claims in the article about how anyone can access any application's environment are inaccurate.

I'm not sure if I understood something wrong, but .env files are for development, not production. It never crossed my mind to use .env files for production deployments, but skimming the blog post, it seems like people do ship a .env file to their production environment?

stackskipton 2y ago
SRE here, most of time when that happens, it's people leaving .env in git where it's not ignored and build process just does COPY * * to runtime environment. EDIT: Or it's just small time developers who don't care about security and ship whatever works.
- deleted 2y ago
  [deleted]
- hinkley 2y ago
  Hidden files get checked/built in all the time. Too many people don’t think to look for them.
  - cwbriscoe 2y ago
    That is why I like "Allow Listing" in my .gitignore file. Much harder to add stuff by accident. # Ignore everything * # But not these files... !/.gitignore !*.go !go.sum !go.mod
    - hinkley 2y ago
      I do the same. But as I do it my mental image of myself is of someone holding their nose and typing one handed. It’s the least shit solution, but it’s definitely a shit solution. Npm has another way to default exclude but I don’t think git does, and if docker got one I don’t recall what it is.
- diggan 2y ago
  > it's people leaving .env in git Ah, makes sense it could get exposed then. The pattern I've always followed is having `.env.template`, `.env.dev` or similar in SCM, then require the development setup to manually/automatically copy it to `.env`, which is .gitignore'd. Seems that pattern might not have been as widespread as I thought :)
0cf8612b2e1e 2y ago
I bet many .envs have been mistakenly shipped to production. I will continue to use .envs. The alternatives invoke much more friction.
vinnymac 2y ago
Encrypting dotenv files is a thing, I would even say it has become popular! https://dotenvx.com https://dotenvx.com https://github.com/getsops/sops https://github.com/getsops/sops
- theozero 2y ago
  also check out https://dmno.dev/docs/plugins/encrypted-vault/ https://dmno.dev/docs/plugins/encrypted-vault/
- nunez 2y ago
  And it's super easy to do. I used GPG with a passphrase before I adopted sops and PGP keypairs. Just make sure that you gitignore the plain-text dotenv. That's the hard part (on a team)

jonathanlydall 2y ago

Yes, not so much about environment variables which can be injected by your hosting environment which as far as I know shouldn’t really be an issue (assuming your hosting environment sources them securely).

xp84 2y ago

Yes! And they make an okayish point that especially on an infinite timescale, some noob developer (or a genius but fallible experienced engineer) will commit a .env file to source control, creating an inadvertent data disclosure that nobody wants. The thing is, in a properly run engineering organization, zero developers should have any production secrets to put into .env files in the first place. Development secrets should always be either dummy values created for this purpose (e.g. one's local development database password should be nothing or 1234 or something because you need no 'security' on a local DB that listens on 127.0.0.1 only), or the keys to entirely separate testing environments, developer sandboxes, and free-tier accounts on your 3rd party dependencies (e.g. an identity provider, Salesforce, etc.) I'd be uncomfortable with any .env files anywhere having creds in them that I would be upset about someone accidentaly posting even in our public repositories. Sure I'd rotate them just because I don't want someone poking around our local developer Auth0 account or local developer OpenAI account, but there should be zero or close to zero of value that's possible to exploit using those secrets. At my company we've settled on dotenvx to manage these .env files, which has the neat feature of asymmetric encryption so that 99.9% of the time devs don't even need the private key for the production one because adding a new value for a new thing can be done with the public key. Values that are actually secret are encrypted in the env file, and the correct private key for the environment is passed to the app as an env var, which it uses to decrypt any encrypted values. As others have pointed out, many claims in the article about how anyone can access any application's environment are inaccurate.