Geo: Send authorization headers to Gitlab Shell to perform Git over HTTPS to Primary
Current architecture
Currently, when a user performs a Git over SSH request to secondary node, Gitlab Shell performs requests to secondary Workhorse & Rails which performs a Git over HTTP request to primary.
sequenceDiagram
participant C as Git on client
participant S as GitLab Shell
participant I as Workhorse & Rails
participant P as Workhorse & Rails
Note left of C: git fetch
Note over S,I: Secondary site
Note over P: Primary site
C->>+S: ssh git receive-pack request
S->>I: SSH key validation (api/v4/internal/authorized_keys?key=..)
I-->>S: HTTP/1.1 300 (custom action status) with {endpoint, msg, primary_repo}
S->>I: POST /api/v4/geo/proxy_git_ssh/info_refs_receive_pack
I->>P: POST $PRIMARY/foo/bar.git/info/refs/?service=git-receive-pack
P-->>I: HTTP/1.1 200 OK
I-->>S: <response>
S-->>C: return Git response from primary
C-->>S: stream Git data to push
S->>I: POST /api/v4/geo/proxy_git_ssh/receive_pack
I->>P: POST $PRIMARY/foo/bar.git/git-receive-pack
P-->>I: HTTP/1.1 200 OK
I-->>S: <response>
S-->>-C: gitlab-shell receive-pack response
Problem
As we've agreed in Geo: Proxy Git push over SSH via Workhorse, not... (#387568 - closed) it makes sense to move the Git over HTTP requests to Primary to Gitlab Shell to avoid proxying large blobs of data via Gitlab Rails. To be able to perform this request, Gitlab Shell needs the requests to be authorized.
Proposal
Let's extend Geo payload with the Authorization headers (similar to this) that will allow us to perform that request from Gitlab Shell.
It probably makes sense to add a feature flag and pass its value in the payload as well. We'll be able to switch the behavior then.