Set deploy key actor for Geo secondary Git requests proxied to primary
What does this MR do and why?
This MR includes the deploy_keys access actor when performing a Git command from a secondary site. When a repository is not synchronized/replicated (due to selective synchronization) in the secondary site, the request is proxied to the primary site. Currently, a secondary request can bypass the scope of deploy keys and perform the action even when deploy keys are not enabled for the project.
The cause behind this behavior is the access_actor method under the EE context, where deploy keys are not being considered, and the SSH user creator (a User instance) is used instead.
Test case
Public deploy keys created in a primary site and not enabled for a project
Scenario
Secondary sites proxy requests to the primary site due to selective synchronization. The project we will try to clone does not belong to the synchronized group, so requests are proxied to the primary site. The clone command should fail for both primary and secondary sites that try to clone the repository. Currently, the secondary site succeeds when performing the Git command.
Expectation
- Expected behavior: Both primary and secondary sites fail when trying to clone a project with disabled public deploy keys for a project
- Expected error message: "The project you were looking for could not be found, or you don't have permission to view it."
- Git command:
clone - Deploy keys: public
| Site | Before | After |
|---|---|---|
| Primary |  |
Same |
| Secondary |  |
 |
How to setup this locally?
I can provide access to my Geo test instances and share my deploy keys for faster review. The other way is to follow the steps to reproduce the issue.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #410658 (closed)