Allow service account to have deploy keys
Release notes
Problem to solve
Sometimes Deploy Keys causes a confusion that the key doesn't work in certain condition, for example, git-push fails by protected branches/tags. This is because GitLab evaluates the creator of the deploy key if the person has permission to access to the Git-Ref and subsequent processes, such as pipeline runs.
However, the point of Deploy Keys is to treat it as an individual machine user, so that it should NOT be affected by the creator of the deploy key. For example, deploy keys should keep working even after the creator of the deploy key removed from the project.
Original bug report (later changed to feature request)
Summary
Deploy Keys has user_id
:
gitlabhq_production=# select id, user_id, title from keys where type LiKE 'DeployKey';
id | user_id | title
----+---------+-------------------------------------------
48 | | jenkins@test12 <- old key (no user_id)
57 | 73 | srv (legacy key) <- new key (has user_id)
Steps to reproduce
Create new Deploy Key for the project.
What is the current bug behavior?
We have a user name in output:
$ ssh -T git@gitlab -i ~/.ssh/srv
Welcome to GitLab, Borys Borysenko!
What is the expected correct behavior?
No user name in output:
$ ssh -T git@gitlab -i ~/.ssh/id_rsa
Welcome to GitLab, Anonymous!
Results of GitLab environment info
[root@gitlab ~]# gitlab-rake gitlab:env:info
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.3.3p222
Gem Version: 2.6.6
Bundler Version:1.13.7
Rake Version: 10.5.0
Redis Version: 3.2.5
Git Version: 2.13.0
Sidekiq Version:5.0.0
Go Version: unknown
GitLab information
Version: 9.3.9
Revision: 755bb71
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: postgresql
URL: https://gitlab.owox.com
HTTP Clone URL: https://gitlab.owox.com/some-group/some-project.git
SSH Clone URL: git@gitlab.owox.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: no
GitLab Shell
Version: 5.1.1
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks
Git: /opt/gitlab/embedded/bin/git
Results of GitLab application Check
Everything is ok (green).
Usecase
As a GitLab administrator, I want to manage GitLab users independently of deploy keys. The users are an organizational topic, while the deploy keys are an operational topic. The two should not be tied together.
Proposal
GitLab now has the first-class service account feature, but it can only create PAT today.
We should allow SA to have Deploy Keys as well.