Allow to add deploy keys with write-access

Having deploy keys with write-access might be handy for atomatic mirrroring of repositories to GitLab while still restricting the access to a single project.

The working alternative to this would be adding a new user and adding him only to this one project.

The idea behind a deploy key is another one, though: You can clone into and pull a repository from a testing / production machine (e.g. as root / special user), whereas development happens on other machines or with other users. e.g. you "deploy" the code do the place where it is needed.

I think it was very useful in order to build packages like releases, because in this kind of process, we expect that ci-builder makes the tag and prepare the next release, and of course push both of them commits to git repository.

Customer also requests this in https://gitlab.zendesk.com/agent/tickets/15669

Added ~113220 label

Added feature proposal label

@JobV What do you think?

I'd rather not confuse the notion of a deploy key: it clearly denotes read-only access.

Is there any reason why wouldn't adding a new user suffice? I could see EE users perhaps not liking that this counts against the user totals, but are there other reasons (e.g. API access is still enabled for this user?)?

@stanhu I think having an additional user is the main problem. Also, both GitHub and BitBucket have write deploy keys so users expect it.

@dblessing Ah, I did not realize that GitHub offers write-access:

It looks like Bitbucket only has read-only access:

That begs the question: if a deploy key pushes to a repo, what user/e-mail should show up since git requires an author?

@stanhu Hmm, a customer mentioned it was possible on BB.

That begs the question: if a deploy key pushes to a repo, what user/e-mail should show up since git requires an author?

Yep, great question.

@dblessing I think we should do it.

Milestone changed to 8.8

I'm glad to hear this is getting added. This would allow me to host my etckeeper repos (a system that keeps /etc files for Unix hosts in git and can push to a remote repo on commit) in Gitlab.

I agree with the arguments over the past couple years saying CI systems shouldn't have write access, but CI/outgoing-deploy is not the only use case for this. In fact my use case is the reverse of a deploy (incoming-deploy) where actions on a remote system can trigger automated pushes on various hook actions and in this case need to push a git repo back to a central location as part of the host backup/auditing procedure.

@dblessing how is the anonymity of a key to push related to the author of a commit? nothing in git mandates an author for a push...

mentioned in issue #13986 (closed)

@umlaeute When the person said 'push' I presumed there to be a new commit, tag, etc. You're right, a push does not require an author, but a tag/commit does. In that case, the question stands.

@dblessing That seems like an irrelevant question. In Git the "author" of commits and tags is set arbitrarily by the git client (usually using an name ad email address from the local git config). Gitlab doesn't care about this value and doesn't validate them except to match up email addresses with registered users for convenience links in the UI. You can push commits made by users other than yourself (even bogus ones) and Gitlab doesn't care. Whatever software generates the commit or tag will be responsible for setting this value inside the commit. It has no bearing on this feature of Gitlab.

@alerque It's not that GitLab cares. But we want a useful author for historical purposes. Some users enable the git hook check ensuring the author is a GitLab user, too.

i still don't understand the problem here:

• if the postreceive hook accepts unknown authors, it will do so for both real humans and automated pushers.

• if a real human pushes to the repository, and the commits contain an unknown email, then a postreceive hook might reject the push.

• if a fake user pushes to the repository (by means of a r/w deploy key), and the commits contain an unknown email, the system might reject the push.

fine (or not) - but why is this important when we talk about write-enabled deploy keys?

(there are a number of other cases a push might fail: the branches might have diverged, an ssh-key might have been retracted, the client might be offline or the server just died; but none of them are related to deploy keys)

@dblessing The point is that whatever user gets set is completely out of scope for this issue: it will be set by whatever software the user makes a commit with. The content and commit meta data that a user chooses to make to be pushed back to Gitlab using a deploy key is their business and has nothing to do with write enabling the deploy keys. Whether they use a git hook to verify commits before accepting them is likewise irrelevant.

I see what you're saying. You're right. Thanks

Milestone changed to 8.9

Removed ~113220 feature proposal labels

Milestone changed to %8.10

Added ~307502 label

Added ~113220 feature proposal labels

Milestone changed to %8.11

Note that while Git doesn't require a user for a push, GitLab itself does, since we show pushes in the activity feed. For now, let's just use the user who created the deploy key. It looks like that's what GitHub does as well.

One problem with that though: What do we do if the user who initially created the deploy key is removed from the project, or if their account is deleted entirely? In a later iteration, we should probably get a special "Deploy Key XYZ pushed to this repo" event. Same for mirroring, which currently uses the mirror_user (that's an EE-only feature).

Added ~480950 label

Added ~164274 label

mentioned in merge request !5807 (closed)

Milestone changed to %8.12

Milestone changed to %8.13

Milestone changed to %8.14

Mentioned in issue #22689 (closed)

Reassigned to @godfat

Mentioned in merge request !7383 (merged)

I have a question if anyone could answer me:

We check if users could push to a protected branch and also tags. Do we also want such check for deploy key? Or I guess the deploy key should have the same privilege as the creator?

@DouweM Let me know if you have an answer for https://gitlab.com/gitlab-org/gitlab-ce/issues/1376#note_18141017 :) Before I got an answer, I'll assume the deploy key would have the same privilege as its owner for that particular project. That means it might not be able to touch protected branches.

some thoughts

• i think it would be nice if the deploy key could be more restricted than its owner.
• its owner must not be able to escalate permissions beyond their own (that is: if they cannot push to a protected branch, then they must not be able to push to that branch via the deploy key either)
• having said that, it probably makes sense to only allow the repo masters (or even owners) to add new deploy keys

@umlaeute Thank you for the input! I think having fine-grained access options for deploy key would be nice, but that would certainly be much more complex than just having a write access checkbox. So I guess in the first iteration we'll just do it simple. However we could still make it more restricted than its owner, for example, making the deploy key only have developers access, and never master therefore never being able to push to protected branches.

Umm... Did I miss something? A deploy key might not have a corresponding user?

Umm, so I guess deploy keys created by an admin would not have a corresponding user (not sure what they are), but we'll fix regular deploy key to have a corresponding user in !7383 (merged)

isn't an admin a user as well? probably I am missing something

Yes, it is, but the deploy key created by an admin is not associated with a project, and it's also set with a public attribute and I am not sure what it means.

Milestone changed to %8.15

@godfat It would be nice if we could enable or disable write access for the public keys for each project individually. For example, we have read-only public key with some projects granted to it and we're want to grant write access to some project for that key. And vice-versa

@akhnin I could see that would be useful, but I am not very sure if it's worth the complexity. Maybe in the next iteration. Would you mind create an issue for that?

changed milestone to %8.16

mentioned in issue #26116 (moved)

closed via merge request !7383 (merged)

FYI docs are outdated, https://docs.gitlab.com/ce/ssh/README.html#deploy-keys:

Deploy keys allow read-only access to multiple projects with a single SSH key.

It's true it would be very convenient to create a group, bind to the keys, for deployment, to link the project to the group. And easily do push/pull.

But now you can only bind keys to special user for deploy for each project. Very uncomfortable.

mentioned in issue #5910 (closed)

I'm clearly missing the option to disallow force push. My master branch ist protected and a deploy key with enabled push access can just force push. I think this is not good as an attacker gaining access to the server with the deploy key could erase my repository, now.

mentioned in issue gitlab#7582

mentioned in merge request !14785