Hi,
We used to store all the credential and ssh-keys related to deploy an app inside the project’s git repo. It was easy for at the beginning since we only had a few internal services. But now, we have a dozen of services/apps and different places to deploy them. And we’ve a bigger team now.
We can’t no longer keep credentials inside the repo. So, we implemented a much better and secure environment to deploy our apps. This is a bit about it and our migration process.
This is great! Really good ideas, consistent with what we’ve found for the guide.
Here’s a link to that section: http://guide.meteor.com/security.html#api-keys
Let me know if there’s anything you think we should add!
That’s good advice to not to put keys and settings in the app repo. But, we put dev related keys(S3, auth tokens) in the repo itself. So, a developer could just come by and run the app without initializing anything.
We have a shell file called .devrun which initialize those settings and env. variables.
You mean like you have a separate S3 bucket for dev and prod, and the dev key is just in the repository? That’s a cool idea - is it possible that compromising those dev keys could somehow compromise your security?
Anyway, we need to share those Dev keys to developers. So we thought it’s a better idea to put those inside the repo.
Those keys are on our sandbox accounts on different cloud services. They never used for the production system. I think that’s safe.
Only issue is the developer might use those keys for their own benefit like sending emails via Dev mailgun account. But that’s another level of trust.
Yeah I think that makes sense. I was thinking for something like what if you had a private package server or something, and someone got the credentials for that, they could cause your developers to download malicious code onto their computers.
Yeah. That’s possible. That’s why we use those Dev keys in a seperate accounts from the production.
Actually for S3, we have a key which is only authorized for a single bucket.