Backporting authorized_keys feature to CE

As part of our ~"Cloud Native" and GCP Migration work, we identified in https://gitlab.com/charts/helm.gitlab.io/issues/13 and https://gitlab.com/charts/helm.gitlab.io/issues/14 that not having to write to authorized_keys file would simplify our work.

As far as I understand, the biggest chunk is already in gitlab-shell, so accessible in both EE and CE: gitlab-shell!42 (merged)

Two required parts from EE codebase are https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/250 and https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2004.

@jramsay I think this falls under ~Platform. Are there any reasons why we should not backport this to CE?

To make it perfectly clear, this is not intended to be the new default behaviour of very installation method. We only need this option to be available in both editions to simplify the work in helm charts where this will be the default.

Links

https://docs.gitlab.com/ee/administration/operations/fast_ssh_key_lookup.html

/cc @pcarranza

@DouweM do you have any background on why there is this difference between CE and EE? /cc @mydigitalself

@marin if there's nothing preventing us back porting to CE, will %10.4 be soon enough or is this completely blocking ~"Cloud Native" ?

@jramsay The feature is EE-only because it is only relevant at large scale, with many thousands of SSH keys. See gitlab-com/operations#99 (closed) where this was originally discussed, and gitlab-com/operations#99 (comment 3941806) where it was originally suggested to make this EE-only.

There's nothing preventing us from bringing it to CE as an option.

@jramsay @DouweM is correct. This feature makes sense if you have hundreds (thousands?) of users that need to be checked against authorized_keys file. Every time that file is opened, it adds seconds of wait time for the next person in queue.

10.4 should be soon enough, it is not blocking us at the moment. I would like to hear your views on this before we schedule it though.

The feature itself is really small: one API call authorized_keys on the gitlab-rails package. The rest of the bindings are in gitlab-shell all the time.

Thanks @DouweM and @marin. I don't see any problem back porting.

changed milestone to %10.4

added GCP Migration label

mentioned in issue #4156

I've logged a related request to make it easier for us to flag this feature enabled as well during setup: https://gitlab.com/gitlab-org/gitlab-ee/issues/4156

added authentication label

added backend label

added Deliverable label

The feature being backported here is described in https://gitlab.com/gitlab-org/gitlab-ee/blob/master/doc/administration/operations/speed_up_ssh.md, which is using an AuthorizedKeysCommand instead of an authorized_keys file.

Some links of interest:

• gitlab-shell!42 (merged)
• https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/250
• gitlab-com/operations#99 (closed)
• https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/api/internal.rb#L86-93
• https://gitlab.com/gitlab-org/gitlab-ee/commit/526a05e75b22f265928db824377723fe20c023b2

assigned to @jamedjo

mentioned in issue omnibus-gitlab#3024 (closed)

Once this is back ported, perhaps we should make this the default for Omnibus installations? omnibus-gitlab#3024 (closed)

@jramsay not sure if it can be the default given that not all of the OS there support this command.

It to work needs a fairly recent openssh that I don't think REHL provides, and a specific configuration.

Thanks @pcarranza. I'll close the other issue with your notes. We can re-open if it makes sense in the future.

Reminder to whoever picks this up, we recently added some notes that this is an EES feature https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3749/diffs. Once backported to CE, those will need to change.