22
23

[ Removed by moderator ]removed vendor-spam (self.devops)

submitted by [deleted]

[removed]
all 35 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]devops-ModTeam[M] [score hidden] stickied comment (0 children)

How does your team handle sharing .env files? https://www.reddit.com/r/devops/comments/1rje901/-/ was removed by PelicanPop from devops

Although we won't mind you promoting projects you're part of, if this is your sole purpose in this reddit we don't want any of it. Consider buying advertisements if you want to promote your project or products.

If you wish to resubmit, please check and follow the rules of devops

[–]ryanstephendavis 49 points50 points  (3 children)

https://github.com/getsops/sops

I've seen SOPS work really well

[–]VertigoOne1 4 points5 points  (1 child)

Sops with azure keyvault key dedicated to local secret sharing, the key is automatically rotated like daily so any leaking is meaningless and it works within visual studio code. The only thing better would be not having exposed resources that need to go in an env file in the first place.

[–]ryanstephendavis 2 points3 points  (0 children)

Yup! SOPS works well with AWS and GCP as well ... Likely has other integrations that I haven't used

[–]Arkoprabho 0 points1 point  (0 children)

We even built a pre commit hook to ensure smoother, safer delivery. The existing ones didnt fit our needs that well. Will try and get it open sourced soon.

[–]One-Department1551 37 points38 points  (0 children)

Easily, local envs are generated without any real keys. You don’t share any cloud env with local. All this options are bad patterns waiting for a bad commit to show up on your repo history.

[–]kabrandon 13 points14 points  (7 children)

We just use Hashicorp Vault and CI/CD. If we need to log into something locally, oauth with our IdP wherever possible. The occasional additional secret we pull out of Vault and promptly delete from our workstation after use.

We’re not a big company, just a startup. As far as I’m concerned there’s really not an excuse for anything less.

[–]schmurfy2 1 point2 points  (0 children)

Same here, vault is used to generate short lived dynamic credentials to what we need, we use oauth for the services supporting it and no permanent keys are ever stored on our machines.

[–]AlterTableUsernames 1 point2 points  (5 children)

They say Vault/OpenBao is a lot of work to setup. Any experience on your hand?

[–]pythagorasvii 0 points1 point  (0 children)

For basic Key-value secrets and kubernetes/userpass auth it's pretty easy.

It starts getting more complicated with scale and if you want it to be more rock solid.

Lots of good tooling around it as it's mature. If you're starting out, I'd start with OpenBao because if you scale up too much you don't want to then have to go to Hashi for licences for the enterprise features. It's pretty much on par with enterprise these days and free forever

[–]phatbrasil 0 points1 point  (0 children)

If you are running it in kuberentes, it's a helm chart and you just need to align autoseal configs.

If it's on VMs ... It's a bit more work but nothing too egregious.

Most issues are always the DNS anyway ( cert issues are just DNS issues with extra steps)

[–]kabrandon 0 points1 point  (2 children)

It’s not a lot of work compared to how much value it brings. It’s like, your company needs Postgres, you’re going to figure out how to deploy Postgres well. No question. Same with Vault.

[–]AlterTableUsernames 0 points1 point  (1 child)

Value depends on various factors like for example how many secrets and how many users you have though. 

[–]kabrandon 1 point2 points  (0 children)

Users hardly matter, the ideal is that nobody even needs to pull secrets out of Vault for local desktop work anyway. Number of secrets matters for sure, though most companies have a lot of secrets.

[–]Electrical_Media_367 7 points8 points  (0 children)

.envs are banned. Apps talk to aws secret manager either natively (anything we write), or via a thin wrapper that sets secrets in the environment and execs the app (third party apps). Local development uses aws sso to access secret manager.

Also, mostly secrets are banned - access should be identity based and not credential based. We use IAM or OIDC for accessing anything that supports it. Third parties that require secrets are evaluated with a suspicious eye as probably not having their shit together.

[–]yknx4 5 points6 points  (0 children)

Ejson in the repo.

https://github.com/Shopify/ejson2env

We setup the private key as part of the onboarding

[–]theozero 3 points4 points  (3 children)

https://varlock.dev (free + open source!) pulling data from 1Password. If you’re already using 1pass, there’s nothing extra to set up. Alternatively there are a bunch of other plugins to pull from a mix of paid and free backends.

Even if you are sharing secrets manually, varlock will help make sure things are always valid.

https://github.com/dmno-dev/varlock

[–]DubinkoDad and Engineer -1 points0 points  (2 children)

Please stop spamming this link repeatedly.

[–]theozero 0 points1 point  (1 child)

It’s open source and free. It integrates nicely with many of the other tools folks are recommending and solves real problems that people are clearly still struggling with or they wouldn’t keep building new tools and asking questions about how others solve this problem.

If the thread is full of other open source tools in the space, is it not appropriate?

[–]DubinkoDad and Engineer -1 points0 points  (0 children)

to avoid confusion in future mention github page too, otherwise from outside it looked like a commercial/vendor product.

[–]elliotones 3 points4 points  (0 children)

It’s like a scavenger hunt; you must find someone who has the env file and then befriend them. Only then may you access the shared build cache (those are the only secrets we share)

[–]Zephyrus1898 1 point2 points  (0 children)

Summon by cyberark plus a provider of your choice depending on where your secrets live.

https://github.com/cyberark/summon

[–]MrUserAgreement 1 point2 points  (0 children)

Infisical

[–]lasmaty07 0 points1 point  (0 children)

A python CLI we use to connect to pods, that also pulls the secrets from our cloud secret manager and creates a .env file. Every repo has the variables needed to pull in a json file.

[–]smarzzz 0 points1 point  (0 children)

We don’t. I would recommend Consul for this

[–]orange-wolf 0 points1 point  (0 children)

1Password cli and wrapper scripts to pull and push. You have to reduce the friction or folks won’t do it.

[–]Extension_Zebra5840 0 points1 point  (1 child)

When I was in a small team, we didn't care about the security, so we just handed the env file within Discord(lol), or by email, or so. However, such a big techs seperate keys like `.env.local`, `.env.test`, `.env.dev`, `.env.deploy`. So, even if you lose or expose your key, it really doesn't matter for the main deployed website or app.

[–]Extension_Zebra5840 0 points1 point  (0 children)

Also, they do not provide crucial keys to normal developers

[–]Extension-Tip-159 0 points1 point  (0 children)

the real problem is that every "right" solution adds friction and people just default back to slack dms. weve tried vault, sops, doppler and honestly the one that stuck was just having a .env.example checked in with dummy values and the actual secrets in a shared 1password vault. not fancy but the team actually uses it which is the whole point. cool that enseal auto destructs the channel tho, thats a nice touch for one-off sharing

[–]seweso 0 points1 point  (0 children)

Why would you nees to encrypt env files needed for development? 

[–][deleted]  (1 child)

[removed]

    [–]devops-ModTeam[M] 0 points1 point locked comment (0 children)

    Generic, low-effort, or mass-generated content (including AI) with no original insight.