Category Archives: Git

Let’s say I have a multi-user application deployed in a customer’s data center that needs to clone/update git repositories – both “interactively” when a user is creating a new project (which consists of 1-N git repositories) and “in the background” when the app is updating those projects and running analyses on them.

The way I’m doing it right now is that admins will configure git with proper ssh key on the machine where the app is installed and the key is then used automatically by git to do all the required clone/pull operations.

However, there’s a problem with the aforementioned approach:
In some configurations, not all users of the application are supposed to have access too all projects/repositories. But (since the git ssh key is “shared”) they can clone all the repositories that are accessible using the key (assuming they know the URL of a repository) even though they wouldn’t be able to access such repositories normally.

To fix this, I’d need to make sure that users are only able to clone repositories to which they really do have access.
I can only think of two possible solutions:

1. Build a proper integration with all possible Git providers (GitHub, GitLab, Bitbucket, Team Foundation Server, etc.) and authenticate users via these providers APIs. Then store users’ access tokens and use them to perform git operations (via HTTPS-like git URLs).
2. Require each user (capable of creating a new project) upload their private ssh key which will be used to perform all git operations for all projects they create.

Option 1 sounds really complex and isn’t really compatible with the current design and existing installations. And not all git providers (including custom git servers) may give us proper authentication options via “access tokens”.

Option 2 means that we’d need to get ssh keys for all users capable of creating a new project and then store those ssh keys somewhere (possibly in a database).
This sounds bad. I’ve read two related questions (How to securely store users’ private keys? and Storing User’s Private Keys in DB) and it only confirms my worries.
Is this still a reasonable approach to follow in our case or should we avoid it by all means?
Any other options we could use or extra preventive measures we should implement? (remember the app won’t be installed on our servers so the things we can do on that level are limited)

Side note:
One other option we thought of would be to make users use “Basic” authentication with git, that is specify git clone URLs like https://user:token@github.com/org/repo. However, we don’t like this as much since it’s still difficult to manage and users have to enter credentials in plaintext (this already proved to be easy-to-leak). It’s, however, a zero-effort on our side so it’s appealing from that point of view :).

Continue reading Storing users’ private keys to clone git repositories on their behalf→