...
Well, the worse news is that we cannot run a CI job to prune the
artifacts
automatically, because one would need a personal access token for that. Why
personal access token? Because Project/Group access tokens are apparently
unavailable on GitLab SaaS if you're not a paying customer (which is weird,
because most other features from Ultimate are enabled) [2] and in fact I don't
see the described setting under our group/project just like this guy [3].
The problem with Personal access tokens is that there are security implications
tied to them:
- linked to a specific user
- other users with high enough privileges could see the token
- wrong settings can lead to leaking of that token which could expose all
repositories of that user
One possible solution would be to create a member service account with no
repositories. The password would only be available to the maintainers. AFAIK
you don't need full API access to purge pipelines, IOW read_api permissions
should suffice which means it would not make this such an awfully ugly solution.
Forget about ^this one, I just tried and full API access permission is required
on the token which renders ^this a no-go from security POV.
Regards,
Erik
The proper solution would be to use CI/CD job tokens because these are
ephemeral by design, however they have no permission granularity settings and
so cannot be used with all of the API endpoints (purging artifacts being one of
them) :(.
The least favourable solution IMO (but 100% functional) would be for one of the
to set up a cron job on a private machine using their private access token
which nobody could see and purge them from "the outside".
[1]
https://docs.gitlab.com/ee/ci/variables/where_variables_can_be_used.html#...
[2]
https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html
[3]
https://forum.gitlab.com/t/project-access-token-isnt-visible/51701
In any case I'll put this patch on hold until we have a clear idea what the
best course of action is - we still have a monthâ„¢.
Erik