feat: add new authentication method for GitLab >= 16

[Kadeux]

Description

GitLab released a new authentication architecture for their runners since the version 16.0.0. This MR handle this new architecture while maintaining backward compatibility.

Migrations required

Highly recommended as the old GitLab Runner registration method will be removed with GitLab 17.

Migration steps:

1. create a group access token for your GitLab group (needs the owner role and the api scope). To be refreshed manually once a year.
2. store the token in a SSM parameter and set the variable runner_gitlab.access_token_secure_parameter_store_name to this SSM parameter
3. remove runner_gitlab_registration_config.registration_token. No longer needed.
4. add type = project or group, group_id = (for group runners) orproject_id = (for project runners) to therunner_gitlab_registration_config` section.

Verification

• running the old authentication method on GitLab 16: success
• running the new authentication method on GitLab 16: success

[github-actions]

Hey @Kadeux! 👋

Thank you for your contribution to the project. Please refer to the contribution rules for a quick overview of the process.

Make sure that this PR clearly explains:

• the problem being solved
• the best way a reviewer and you can test your changes

With submitting this PR you confirm that you hold the rights of the code added and agree that it will published under this LICENSE.

The following ChatOps commands are supported:

• /help: notifies a maintainer to help you out

Simply add a comment with the command in the first line. If you need to pass more information, separate it with a blank line from the command.

This message was generated automatically. You are welcome to improve it.

[kayman-mk]

Thanks for solving this issue, @Kadeux

I have some questions and suggestions which came into my mind. Especially because everyone needs to adjust his config at the moment.

Could you please also update the default example and describe how to configure the new authentication method?

[kayman-mk]

Linter still complains about an unused variable use_new_runner_authentication_gitlab_16. Is it still work in progress?

[Kadeux]

Linter still complains about an unused variable use_new_runner_authentication_gitlab_16. Is it still work in progress?

Sorry I didn't see it, I still don't know why did I put this variable here :)

[Tiduster]

@kayman-mk : Any additional remarks on this change?

Do not hesitate to ask for more changes if required.

Best regards,

[kayman-mk]

Environment for testing:
GitLab 16.0.8
GitLab Runner 16.0.2

Upgraded my runner to this version and verify that jobs are still processed without changing my configuration: success

[kayman-mk]

Tried to use the new authentication. But it didn't work.

  runner_gitlab_access_token_secure_parameter_store_name = aws_ssm_parameter.gitlab_runner_registration_token_new.name

  runner_gitlab_registration_config = {
    # registration_token = var.gitlab_runner_registration_token.value
    tag_list           = "test"
    description        = "runner for testing new version (${each.value.availability_zone})"
    locked_to_project  = "false"
    run_untagged       = "false"
    maximum_timeout    = "10800"

    type = "group"
    group_id = 123
  }

It still uses the old registration method. The new glrt- registration token wasn't used.

EDIT: I used the runner before and there was a runner token present, which is handled by the module internally. Thus we have to remove this token in order to upgrade to the new authentication method. ❗

EDIT: type = "group" is wrong. Use group_type instead. List/Validate the correct types. Script should throw an error in case the type is wrong. ❗

EDIT: fetching the token does not work. GitLab returns 401 not authorized.

EDIT: It seems that we need a personal access token now to access the user/runners API. Thus runner_gitlab_access_token_secure_parameter_store_name is not the glrt- token for the runner and there is no need to pre-register a runner manually on the UI. The registration is done by the script here. This seems to be a problem as this token becomes invalid in case the user account is disabled. Seems to be better to pre-register the runner as it is a one time effort only.

[kayman-mk]

Regarding the registration process of the runners: The module needs a PAT to access GitLab and register the runner.

I think in an enterprise environment we shouldn't give a PAT to our module. I suggest that users register the runner manually and we use the glrt- token then. What do you think @Kadeux @npalm @Tiduster

[kayman-mk]

Seems that my question is obsolete as there are access tokens on group level available. https://about.gitlab.com/blog/2023/07/06/how-to-automate-creation-of-runners/

[kayman-mk]

Nice feature you implemented! Appreciated to be able to use the module with GitLab 17+

[kayman-mk]

Looks good. Needs a final test on my side.

[kayman-mk]

Successfully tested the new authentication schema. Had some problems as I added the new variables into the wrong blocks and got no error. Guess this is one of the downsides using maps as variables.

[kayman-mk]

Tested both scenarios with success. @Kadeux Could you please have a look at my (minor) changes, please?

[kayman-mk]

Great! Let's go with the new authentication method. Thanks for your work.

EDIT: Waiting for feedback from @Kadeux I am good to go.

[Kadeux]

Great! Let's go with the new authentication method. Thanks for your work.

EDIT: Waiting for feedback from @Kadeux I am good to go.

Looks good to me ! Thanks.