Notes for GitLab + Keycloak announcement
We should properly document how we announce the official use of GitLab + Keycloak along with any notes for our staff and what the change means to them. We should also note how NOT to use it.
Notes in no particular order:
- Do not upload secrets.
- Do not use GitLab to automatically build packages.
- Secure runners are trusted and can be used to create official artifacts (such as archiso, archboxes, etc). They can only be hand-assigned by DevOps to specific projects and projects needs will be discussed on a one-by-one basis with project owners.
- all CI variables that contain secrets like credentials must be marked as "protect variable" and "mask variable"
- DevOps must review a projects .gitlab-ci.yml and also make the project owner aware that all jobs on protected branches/tags must always have a runner tag selector "secure" declared to avoid protected branches to be run on none secure runners which would allow shared runners to access the secrets we try to separate from such runners. Also only jobs should select the secure runners that actually need to access secure credentials in the CI variables. Default jobs that do not need any secrets and don't publish any artifacts must not be run on the secure runners.
- define modus operandi for secret rotation etc in case a secure runner is once assigned to unsecure jobs (f.e. failure of a .gitlab-ci.yml)
- if we need a privileged runner, we should have both, an unprivileged that is used for everything that doesn't need privileged docker and a special one with the privileged tag that only runs jobs that need privileged docker.
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information