Support for glrt- tokens #1109

Closed Unibozu closed 6 months ago

Hi

This is following https://github.com/cattle-ops/terraform-aws-gitlab-runner/pull/876 which added support for auto-registering the runner with the Next GitLab Runner Token Architecture.

Personal or Group Access Tokens are impossible to securely scope with Gitlab, they grant read/write access to every repositories settings under the group or user. Not ideal.

Describe the solution you'd like

Gitlab now recommends to manually register the runners first (https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/index.html#proposal) which provides a GitLab runner token starting with glrp-. Passing this token as token in the config.toml allows the runner to properly register.

It would make sense for the module to support both methods: auto-registration with PAT for ease of use, or directly passing a GLRT for the runner to use for people who want extra security. This is ignoring registration tokens that are meant to disappear once Gitlab 17 is released in May.

It is possible to use the GLRT right now by manually setting the value of the -runner-token SSM parameter created by the module and restarting the instance. But this doesn't play well with terraform.

A simple implementation would be to seed the token to aws_ssm_parameter.runner_registration_token instead of null.

Thoughts?

I'm happy to implement, I wanted a sounding board first - we need the solution soon before Gitlab 17 releases in May.

Best

Update: The new workflow is no longer recommended, it's required. Per an email they sent out today:

"The legacy workflow that uses runner registration tokens is deprecated and will be disabled in GitLab.com with the deployment of GitLab 17, after 2024-05-22."

@kayman-mk Any thoughts here? This seems like a pretty huge problem on the horizon.

At the moment, it's nice that everything is managed by the module. But if GitLab deprecated the workflow and we have to register the Runner beforehand, we should do this. And to be honest, this would make the module simpler again, supports grouping of Runners in the UI. But you have to find a way to renew the tokens, I guess.

My proposal: We need an option to tell the module to simply use a given token without modifing it. Then we should already be fine. In case the token becomes invalid, the Runner writes a log entry.

It seems to be feasible on short notice as the coding is already in place (80% or so).

What do you think?

That makes sense to me We're already using the new workflow in use cases where we don't use this module, and it's pretty easy and straightforward. Being able to just pass that token in seems pretty reasonable and straightforward.

I don't think we need this module to be responsible for creating the runner itself. This is not the exclusive task of the module and makes the flow even more complex. The module needs to be straightforward: once the gitlab runner has been created in the UI, you pass it the parameter. This coupling doesn't make sense to me

Support for that will be removed with v8, end of 2024, see #186

The new version 7.6.0 was released with this feature. Check it out.

cattle-ops / terraform-aws-gitlab-runner

Support for glrt- tokens #1109

Describe the solution you'd like