How to avoid pushing Github Enterprise code to my personal Github account by mistake if both are configured in my work computer?

Question

Setting the debatability of using personal accounts on the workplace aside.

---

Context:

The company I work for is dedicated to creating apps for other companies. Because of this we have many different clients and handle many different projects within our company's Github Enterprise organization. I'm one of the people in charge of the company's Medium blog. Since we would like to promote the company by showing the kind of people that work here, I consider it essential to be able to post articles using each of our personal accounts. In my opinion, being able to share sample code greatly increases the value of an article. And being able to do it with our own personal Github accounts would also serve as a motivator for people to contribute to the blog. (Especially those who have many personal projects on their personal Github accounts)

Current Situation:

• All engineers at our workplace have Github Enterprise accounts. These accounts allow us to pull and push from the repositories within our organization. Only admins are allowed to create new repositories though.

• Our GHE accounts connect through SSH.

• We are currently not allowed to use personal Github accounts within our work computers, but allowing them is being taken into consideration.

Issue:

Managers are afraid that if personal Github accounts are allowed on company machines, employees might end up pushing our clients' code to their personal repositories BY MISTAKE, making it a huge risk of unintentional information leak.

Allow me to clarify here that, it is not an issue of policies or trust.

The Question:

Considering the following hypothetical actions taken by an employee:

1. Clones a project from the GHE repository to work on it.
2. Modifies some code or adds some features to the project (but forgets push the changes)
3. Changes account and works on some personal project from their personal account.
4. Remembers that he has to commit changes. So he opens the work project and pushes the changes.
5. For some reason he misses the message or warning that he is pushing or creating a repository with his personal account.

Is there a way to ensure that client code won't be made public by a mistake like this? (either through some kind of configuration)

Is uploading code to their personal accounts by mistake even possible considering the repository was made on GHE? (If my understanding is correct, repositories cloned by my work account are automatically configured to push, merge, and pull from the Github Enterprise using the work account only, so even if i changed the account i'd just get an error, but maybe i'd get a prompt to create a new repository on my account? I'm not really an expert using Github...)

Answer 1

Git, on the client side, does not associate the authentication-method with the repository-address. Accidental pushes to personal repositories are thus NOT possible by simply changing the ssh-keys.

---

Cloning a repository from github requires you two things which are independent:

1. an authorization-methods which identifies you on the server-side (in your case ssh) and
2. the URL of the repository.

When cloning from a GHE repository your URL will look something like that:

[email protected]/<organization-name>/<repo-name>

To push this code to a new or empty personal repository the user will need to change the default push-url or manually specify a new URL at the moment of pushing. To achieve this it requires (in most tools I'm aware of) explicit action. I'd call that intentionally and not accidentally.

It is in the nature of Git that every git-database can be cloned and pushed everywhere where you have access to. You cannot disable this feature with Git. You can add hooks to add checks which would prevent "accidental" pushing to other repos that the original one, but that's nothing a user can't bypass.

Changing the ssh-private-key of the user to get access to other github-accounts or organizations won't change implicitly the repo's URL. A standard git-push without changing the URL will simply be denied.

Answer 2

I've participated in work environments where everything was open. I could surf wherever I wanted, install whatever I wanted on my work computer, use a private Github account, and access Facebook and private email accounts. There were no rules, other than the agreement that what happens in the company stays in the company, and what the company owns (including their intellectual property) is solely theirs. I repaid that trust by never, ever doing anything that would compromise it.

I've also participated in environments where everything was locked down in a determined policy of "implicit deny." Every usage of the internet was monitored and logged. Surfing required you to go through a Data Loss Prevention box. Half of the websites I went to didn't work at all. Many of them were banned; if they didn't know about it, you couldn't access it, and if you did need access, you had to demonstrate a work-related need for it. Thumb drives were an impossibility; if you had to move data from one computer to another, you had to do it using a CD or DVD that was finalized.

Which environment would you rather work in? Which environment do you suppose attracts the best developer talent?

In any case, I think you're probably not thinking about the whole picture. While you're debating locking down Github accounts to prevent code leakage, someone in your organization could easily walk out of your premises with your entire code base written to a DVD.

Might I suggest that it would be simpler (and far more effective) to simply hire people you can trust, in addition to implementing sensible and reasonable security precautions?

Answer 3

There are hundreds of possible scenarios where an employee can accidentally send secret information out of the company.

1. Email the wrong person
2. USB sticks left on trains
3. Stolen laptops
4. Make a public rather than private repo
5. Leave the username/pass off or default on an ftp server
6. Share a cloud drive
7. Leave the security off a s3 bucket

etc

You should add each to a 'Risk Map' evaluating each by likelihood and effect.

When it comes to evaluating the likelihood of Uploading to the wrong repo you need to go through the actual tools that you use and write down the actual steps it would take.

Remember to include all the scenarios that restricting access to personal github wont stop as well.

When you have evaluated the risk, you can then see how much of a concern it is related to other risks that perhaps you already accept.

If it's still considered too risky, you can then consider the effect of various mitigating strategies such as restricting access to personal github. Will they completely remove the risk, or only part of it. What are the costs? What are the lost opportunities etc etc

If you approach each perceived risk ad-hoc way as you are doing, then you end up banning everything that is even a tiny tiny risk and missing things which are a big risk.