The team behind repo management turned DevOps platform GitLab has pushed out version 14.7 of the project, which turns GitLab Runner into an option for users who have to comply with Federal Information Processing Standards.
Starting with this release, Runner – the component used to run CI and CD jobs – is FIPS 140-2 compliant for AMD64 compute architectures and Red Hat Enterprise Linux distributions.
While this might be a neat enhancement for those not managing their own GitLab server, teams waiting to be able to use the whole platform in a governmental context will have to exercise some more patience. A FIPS-mode is currently in development, according to an issue tracking the initiative’s progress. However, production-readiness shouldn’t be expected until GitLab 15, which is planned for May 2022.
Admins with a need for more custom automation workflows or event backups get their requests answered with this release – as long as they have an Ultimate subscription. GitLab now allows streaming audit events to whatever destination admins on the highest tier deem useful.
Once an installation has been upgraded, teams on all plans can use the Edit Label page to delete labels, get rid of artefacts in bulk via an additional API endpoint, use the UI to eliminate registered agents, and sort Docker tags in the Container Registry browser.
Looking at security-related changes, v14.7 includes some updates to the Static Analysis security analyser set, which should help get rid of Log4j vulnerabilities amongst other things. Admins are also promised an easier time spotting locked users, and better performance when using Secret Detection analyzer Gitleaks – which has seen a complete rewrite of its core detection engine.
The option to generate group tokens has been mapped to the UI and API in v14.7 and can therefore be used on all tiers now, while admins of self-managed instances have been provided with a way to disable GitLab’s personalisation questions that tended to confuse users.
On top of that, organisations on self-managed versions of GitLab get to add multiple hosts to their LDAP configuration, ensuring GitLab knows about possible alternatives should one LDAP host fail to respond. GitLab also learned to include package registry and Terraform state files in
gitlab-backup create backups to reduce the risk of data loss, though this only works if the files are stored in a file system and not in object storage.
Teams struggling with debugging pipeline jobs on Kubernetes clusters are advised to check out the new GitLab Runner Helm chart, which promises capabilities to enable an interactive terminal which could help with such endeavours.