Which is your favorite strategy for sharing secrets? e.g. meteor settings files with secret info such as API keys, etc. Do you use any specific service e.g torus.sh or technology git-secrets.io? Or you just share the secrets manually with your team?
create a separate repo for production settings and referenced those files from your main repo as such:
meteor deploy --settings ../../myapp-production-settings/myapp-production.json myapp.com
Now multiple contractors can have access to the source code (and dev settings) but your production settings are secure and under version control. Just remember to pull them before you deploy, in case they’ve been updated!
3 Likes
I like to have them outside of VCS (.gitignore) and have the credentials in a Wiki (like Confluence). Mainly so that it’s harder for someone to accidentally give access to unauthorized people.
Having an “{credential-file}.example” file with dummy data is also very helpful. That example file is versioned though.
1 Like
why not a separate repo? then you gain the benefits of version control.
.I never really thought deeply about the advantages of using a repo, but the disadvantages are clear to me:
- Removing credentials that previously had been committed is hard and impossible if someone already has it locally
- It’s really easy to accidentally give people access to repositories that they shouldn’t have (e.g. Bitbucket IMO)
- If credentials are forgotten there should be a way to recover those without being dependent on versioning
The approach I described is very similiar to the one done by Symfony (at least in 2.*).
1 Like
I think this use case is not unique to a repo. Anyone who you’ve shared your credentials with could have them locally, and you may need to rev credentials when someone leaves the team.
I’m talking about credentials that have been committed several years ago, which everyone forgot about and already has been replaced (in the meantime) but not for every service.
It’s all hypothetical but in the end do what fits the project and its people better.
Don’t want to drag this along, but if somebody has already pulled all changes and refuses to get the latest remote version of the repo then all these steps don’t do anything because locally it all still exists.
That’s the power and weakness of git
right but I don’t see the problem. If someone should no longer have access, but you don’t cycle the password on some production system, then you have only yourself to blame. If you give a tenant the keys to an apartment, you have a responsibility to change the lock when they move out. It sounds like you’re blaming Git for your own team’s irresponsible behavior and lax security policy.