There are varying degrees to this but I'll focus on the early stage, low effort approaches I've found work.
For an easy, slightly hacky version I've used git-crypt (https://github.com/AGWA/git-crypt) with tiny teams. You'll need to share the decryption key (e.g. via 1password shared vaults).
As your need for security grows (but you're still not working with a giant team) you're better off using non-committed .env files locally (with need-to-be-shared dev keys stored in shared vaults in 1password) and prod GCP/AWS secrets managers remotely.
Once you work with a bigger team you'll need to start minting API keys limited in scope to each individual, for them to work with locally. The prod keys will only live in the remote environment, managed by some kind of secret manager offered by the platform and will need to be rotated frequently.
> You'll need to share the decryption key (e.g. via 1password shared vaults).
Not really. It also supports keeping the symmetric decryption key encrypted with the GPG key of each added user (and handles this automatically). This is the default behavior.
What you're saying also works (quoting from readme, emphasis mine: "Alternatively, you can export a symmetric secret key, which you must securely convey to collaborators."), but feels worse from a security point of view.
So what you see when you look at the repo in Github et al is the encrypted file and locally you see the file unencrypted? That's neat, a bit like ansible-vault but less of a hassle for the user.
yes, exactly right. it's an encrypted binary on github, but locally (provided you've decrypted it) it'll be unencrypted. If you edit the file locally, it automatically encrypts. It's a neat bit of tech.
so are they 2 separate files? because otherwise how will the system read it unencrypted? (such as an env file)
I ask because I'm currently using a scheme where I have a .secrets env file that is .gitignore'd from the repo but it has a corresponding .secrets.gpg file which isn't, but it's a pain to synchronize these; I suppose this is the problem `sops` solves...
For an easy, slightly hacky version I've used git-crypt (https://github.com/AGWA/git-crypt) with tiny teams. You'll need to share the decryption key (e.g. via 1password shared vaults).
As your need for security grows (but you're still not working with a giant team) you're better off using non-committed .env files locally (with need-to-be-shared dev keys stored in shared vaults in 1password) and prod GCP/AWS secrets managers remotely.
Once you work with a bigger team you'll need to start minting API keys limited in scope to each individual, for them to work with locally. The prod keys will only live in the remote environment, managed by some kind of secret manager offered by the platform and will need to be rotated frequently.