Make k8s runner more flexible and secure

[zachariahmiller]

Is your feature request related to a problem? Please describe.

Currently, the gitlab-runner is only able to be run as an instance type runner and only from within the same cluster as the gitlab server. It also assumes that the individual deploying the gitlab-runner has access to grab secrets from the gitlab namespace, which in a locked down cluster with specific rbac based on certain responsibilities/functions is a faulty assumption. Furthermore, the method for registering the runners that is being used in this chart is currently deprecated and as such an alternative approach or at least a plan for an alternative approach will need to be determined.

Describe the solution you'd like

• come up with plan to mitigate the deprecated approach to runner registration and document. If not feasible to address in this issue create another issue outlining the approach to be addressed before the deprecated method is removed.
• Make this package more flexible so it can not only deploy the instance level gitlab runner (for this one registration type in the same cluster i think it might be okay to assume person deploying can access gitlab namespace), but also shared, group and repo level runners. To support this a mechanism to provide a registration token will be needed as we cant rely on the token in the secret namespace. This is probably a helm value and a secret ref for existing secret.
• Make this package work outside of the same cluster and test. This could be as simple as implementing logic to allow egress (anywhere) for now (ie to gitlab.uds.dev) and update the package to allow overriding the in-cluster fqdn for the registration address in the toml embedded in the values) then test registration from an external cluster (this could be two k3d clusters or honestly whatever).

[Racer159]

We could explore the GitLab runner operator here: https://operatorhub.io/operator/gitlab-runner-operator