Duplicate repoName leads to race condition

[mhutter]

It is possible to configure the same repoName for multiple GitRepos, which sends lieutenant-operator into an endless deploy-key-reconciliation-loop

Steps to Reproduce the Problem

1. Create a cluster, using "gitops1" as repoName.
2. Create a second cluster, also use "gitops1" as a repoName.

Actual Behavior

{"level":"info","ts":1596810672.7987385,"logger":"controller_gitrepo","msg":"Reconciling GitRepo","Request.Namespace":"lieutenant","Request.Name":"c-dawn-lake-5378"}
{"level":"info","ts":1596810675.2224236,"logger":"controller_gitrepo","msg":"keys differed from CRD, keys re-applied to repository","Request.Namespace":"lieutenant","Request.Name":"c-dawn-lake-5378"}
{"level":"info","ts":1596810675.2419648,"logger":"controller_gitrepo","msg":"Reconciling GitRepo","Request.Namespace":"lieutenant","Request.Name":"c-nameless-river-4010"}
{"level":"info","ts":1596810676.9737165,"logger":"controller_gitrepo","msg":"forcing re-creation of key steward","Request.Namespace":"lieutenant","Request.Name":"c-nameless-river-4010"}
{"level":"info","ts":1596810677.6824875,"logger":"controller_gitrepo","msg":"removing key steward; existing on repo but not in CRDs","Request.Namespace":"lieutenant","Request.Name":"c-nameless-river-4010"}
{"level":"info","ts":1596810678.7076182,"logger":"controller_gitrepo","msg":"keys differed from CRD, keys re-applied to repository","Request.Namespace":"lieutenant","Request.Name":"c-nameless-river-4010"}

In my case this actually lead to the situation where NO deploy key was configured on Gitlab.com at all.

Expected Behavior

One of:

• Lieutenant prevents creation of GitRepos with duplicated repoNames (API? admission hook? maybe possible to configure in the CRD?)
• Lieutenant supports this configuration and does not fight itself

[srueg]

Some more thoughts:
The current behavior of adopting/fighting-for existing git repos and adding deploy keys is a security risk: If I create a GitRepo object which points to an existing repo on which the operator's token has access but I don't, the operator will configure the corresponding deploy keys and therefore give me access to the repo.

Possible solution

If a GitRepo object of type auto is created and the referenced URL already exists, an error/warning is logged and the operator switches the type to unmanaged. This would mean it's no longer possible to "adopt" an already existing git repo and manage it via the operator. This would prevent the described privilege escalation.

Possible alternatives

• Restrict the operator GitLab token to very specific groups. This might be problematic because then the operator can't create repos in some groups anymore.
• Restrict the possible git repo URLs, for example it must be a sub path of the tenant's default repo path (as implemented in Cluster catalog Git repo default path via Tenant object lieutenant-api#41)