We improved our organization security at Kadira - Here's the process


#1

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.

Read It: Improving Organizational Security at Kadira


#2

This is great! Really good ideas, consistent with what we’ve found for the guide.


#3

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!


#4

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.


#5

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?


#6

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.


#7

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.


#8

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.