[libvirt PATCH] ci: gitlab: Expire artifacts after 1 day

[Erik Skultety]

...
> 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#gitlab-ciyml-file
> [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