prevent GH Runner registration token leakage #48
Replies: 3 comments 2 replies
-
Hi! I think the best way to go about this is to create a new API endpoint that returns a token for an instance that is in the process of being installed. Instances have access to an API endpoint where they send in status updates and the runner agent ID. We could add a new endpoint there that would return a github runner registration token, which can be called from the userdata script. Tokens would no longer be saved in userdata, and the JWT token used by instances used to fetch the token and send status updates, can be invalidated when the instance reports it's status as being This should help providers avoid saving the token somewhere else or logging it in any way. I have a draft in a branch for this, but no time yet to finish it. Hoping to have some more time next week. |
Beta Was this translation helpful? Give feedback.
-
There is now a WiP PR here: #49 Note, it is still subject to change, but the gist of it is that there is now a new API endpoint available at:
which will return a registration token. example: :~$ curl --fail -s -X GET \
-H 'Accept: application/json' \
-H "Authorization: Bearer ${BEARER_TOKEN}" \
https://garm.example.com/api/v1/metadata/runner-registration-token/
AAG4P6AJQ253TKZY3BPEAPTSDZ2TR
:~$ I am still wondering if we should attach any other kind of info to the response, like expiration time. Right now the endpoint returns just the token which makes it easier to assign it to a variable without having to pass it through |
Beta Was this translation helpful? Give feedback.
-
I merged PR #49. I also updated the OpenStack external provider to leverage the new token workflow. Have a look and let me know if it works for you. |
Beta Was this translation helpful? Give feedback.
-
GH provides a token that can be used to register a runner, see for example https://docs.github.com/en/rest/actions/self-hosted-runners#create-a-registration-token-for-an-enterprise
Garm passes these tokens to the provider of choice. Typically the token is then passed on to the newly provisioned runner to execute the configuration steps (e.g. in case of OpenStack the token is part of the userdata).
As tokens can be used multiple times and are valid for some time (1h ?) there is the risk that an malicious consumer of a runner can spy on it and use it to register own runners.
Of course, this is only a problem if runners are shared with a larger group of users. And it's more a provider problem but a garm-core thing. Nevertheless, it would be cool if garm could offer support for keeping the token hidden.
For example, garm could pass on an own token instead of the token from GitHub, which can then be exchanged exactly once by the runner installation script into the GitHub token via the callback mechanism. This would prevent the GitHub token from being persisted by Openstack or another provider.
What do you think?
(Happy to provide a PR if that's the right solution.)
Beta Was this translation helpful? Give feedback.
All reactions