We're excited to release GitLab 14.7 with audit event broadcasting, GitLab Runner FIPS 140-2 compliance, wildcard access tokens, and more!

These are just a few highlights of over 25 improvements in this release. Read on to find out all about these cool updates. To find out what's coming next month, visit the upcoming releases page and watch the 14.8 release video.

As well as...

We invite you to our meetings

Learn@GitLab (Online Learning Center)

This month's MVP is Fabio Huser

Fabio has added support for generic access tokens in both the UI and REST API. The scale of this contribution shows the scope of the work put into it: an epic, three tickets and over 250 community votes for this feature!

Previously, access tokens were only available at the project level. There was a workaround that allowed admins of self-hosted GitLab instances to generate a generic access token through the Rails console, but that left our SaaS customers with nothing.

Fabio's contribution allows any user with the appropriate privileges to generate access tokens at the group level. Tokens can be generated with a predefined role, expiration date, and scope.

Thank you Fabio for this amazing contribution!

GitLab 14.7 Release Highlights

GitLab Runner is FIPS 140-2 compliantFor US GitLab users, government regulations require the use of FIPS (Federal Information Processing Standards) compliant software. FIPS versions 140-2 and 140-3 define the security requirements for cryptographic modules used in computer, telecommunications, and cyber systems that protect confidential information. Job Runner (GitLab Runner) is now FIPS 140-2 compliant for AMD64 compute architectures and Red Hat Enterprise Linux distributions. In this epic, you can read discussions about GitLab FIPS compliance.

GitLab job handler documentation and original ticket.

Broadcasting Audit Events You can now broadcast audit events to the destination of your choice. This is a great way to correlate audit events from GitLab with other data sources you have, keep a backup of audit events, or create your own automation to take action when a specific event occurs.

You can specify an HTTPS endpoint using our new GraphQL API and events will be sent to it as webhooks. These messages contain the same information as in the audit event UI: what change happened, when it happened, who was involved, and additional metadata.

After receiving these messages, you can filter them by user or type, or pass this data to another third party tool. This is a great way to trigger any custom automation based on events, such as creating a new user or changing a key parameter. We can't wait to see what you'll be using this feature for! Tell us about your experience in the corresponding epic.

Documentation on broadcasting audit events and the original epic.

Group Access Tokens With group access tokens, you can use a single token to perform actions on groups, manage projects in the group, and authenticate to Git over HTTPS (in GitLab 14.2 and later).

Previously, wildcard access tokens were only available to self-managed GitLab instances and were only created through the Rails console. You can now create group access tokens through the UI and API. You can specify the token name, expiration date, and scope. You can also revoke an existing generic access token.

Thanks to Fabio Huser for this contribution!

Documentation on group access tokens and original ticket.

Other improvements in GitLab 14.7

bbabo.Net