Support for glrt- tokens #1109
Comments
|
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 |
## Description GitLab announced then [Next GitLab Runner Token Architecture](https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/index.html#proposal). Runners have to be registered manually. This PR adds a new import parameter `runner_gitlab.preregistered_runner_token_ssm_parameter_name` holding the name of a SSM parameter (type: `SecuredString`). This parameter contains the GitLab Runner token obtained from GitLab. All other registration methods will still work, but have been marked as deprecated and will be removed with [v8.0.0](https://github.com/cattle-ops/terraform-aws-gitlab-runner/milestone/4) end of the year. This also solves the problems with Runners removed from GitLab at shutdown, resulting in new Runners not able to start. Closes #1074 and #1109 ## Verification - [x] deployed the module using the new registration version. Runner is online. - [x] deployed the module using the old authentication schema. Runner is online.
|
The new version 7.6.0 was released with this feature. Check it out. |
Hi
This is following #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 astokenin theconfig.tomlallows 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-tokenSSM 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_tokeninstead ofnull.Thoughts?
I'm happy to implement, I wanted a sounding board first - we need the solution soon before Gitlab 17 releases in May.
Best
The text was updated successfully, but these errors were encountered: