2

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 :).

Juraj Martinka
  • 121
  • 4
  • Is it necessary to use user’s keys? Could your application generate a keypair for itself and be authorized on a git server to do whatever it needs to do? – Andrew Morozko Jun 10 '19 at 13:02
  • 1
    @AndrewMorozko that's, I guess, how it's done right now - admins will generate a single ssh key which is then allowed to access all possible repositories on git server(s) that all the end users may need to access. However, I need to somehow follow the "users' permissions on the git server" model to be able to prevent end users from cloning a repository which they shouldn't be able to clone. – Juraj Martinka Jun 10 '19 at 13:08
  • I added the "Side note" with another alternative which we don't like and wouldn't want to use if possible. – Juraj Martinka Jun 10 '19 at 13:15
  • Well you ether need to somehow extract and enforce the permissions of every user on every supported backend or store the keys on your server. There’s nothing inherently wrong with storing private keys on your server, you just need to understand the threats you’re opening yourself to. In what way private keys are more vulnerable when stored on a server compared to developer’s computer? Would somebody new be able to access them now? What is the impact of an attacker accessing the key and can it be reduced? So yeah, basically model your threats. – Andrew Morozko Jun 10 '19 at 13:25
  • I agree, basic auth would probably be more dangerous than storing the keys properly. – Andrew Morozko Jun 10 '19 at 13:28

0 Answers0