You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The runner token is stored in the SSM Parameter store but the registration token is just there in plain text.
It would make sense to get it dynamically from another parameter. That parameter can possibly be managed externally.
Describe alternatives you've considered
Suggest a solution
(option 1). Create an SSM parameter with provided registration token. Get the token dynamically from it.
(option 2). Point user-data to the ssm parameter to get the token from it. This way the SSM parameter can be managed externally and the token doesn't end up in the terraform state.
Additional context
Not sure if it's worth creating another issue. The provided IAM policy allows reading all SSM parameters. It doesn't seem like it's required and access should be scoped down to one resource (or 2 if the registration token is placed in there as well).
The text was updated successfully, but these errors were encountered:
)
## Description
Adds the ability to read the Gitlab registration token from SSM. If no
registration token is passed in, it will look in SSM to find the token
to use. This prevents the token from being leaked as part of the
user_data.
```hcl
module "gitlab_runner" {
# ...
gitlab_runner_registration_config = {
registration_token = "" # this is the default value too
# ...
}
secure_parameter_store_gitlab_runner_registration_token_name = "name-of-ssm-parameter-holding-the-registration-token"
```
Closes#776
Precondition for #186 to get rid of pre-registered runners.
## Migrations required
NO
## Verification
I modified the runner-default example to not pass in a registration
token and added the token to SSM instead. Then I started up the runner
and confirmed that it successfully registered with Gitlab.
---------
Co-authored-by: Matthias Kay <github-public@matthiaskay.de>
Co-authored-by: Matthias Kay <matthias.kay@hlag.com>
Describe the solution you'd like
The runner token is stored in the SSM Parameter store but the registration token is just there in plain text.
It would make sense to get it dynamically from another parameter. That parameter can possibly be managed externally.
Describe alternatives you've considered
Suggest a solution
Additional context
Not sure if it's worth creating another issue. The provided IAM policy allows reading all SSM parameters. It doesn't seem like it's required and access should be scoped down to one resource (or 2 if the registration token is placed in there as well).
The text was updated successfully, but these errors were encountered: