💁🏻‍♂️ Introduction

🤷🏻‍♂️ Rationale

GitLab Guard was born out of the chaos during the early days of our «GitLab journey», when we dove head first into using GitLab & GitLab CI for our «Infrastructure as Code» setup.

Managing the settings for a handful of projects was fine, but as the number of GitLab projects grew, keeping everything correctly configured became a daily struggle. A single misconfigured project could trigger compliance headaches, security risks, or a flood of those dreaded “oops” moments.

We needed a way to tame our GitLab, and thus GitLab Guard came to life. Instead of relying on every project maintainer to get settings right, GitLab Guard enforces them from a single point of control. It’s the vigilant guardian, patrolling every project, making sure nothing slips through the cracks, and enforcing internal standards like a strict but fair hall monitor.

🛡️ Compliance

As automation skyrockets, and more vital code calls GitLab its home, standards & compliance stop being optional, and become a crucial corner stone of every IT infrastructure. Triggering automated deployments via CI improves efficiency, but it also introduces risks, such as:

• Project visibility is too broad, so unauthorised users can inspect it

• Unauthorised users can retrieve sensitive information

• Critical branches are not protected

• Security-related settings, or CI jobs are not enforced

• Quality gates (e.g. testing) are not enforced, and things will go untested / unreviewed to production

GitLab offers some compliance, and governance tools out of the box, but once you dive into advanced configurations, they quickly become unmanageable. In large enterprises with countless projects and stakeholders, governing GitLab (self-hosted or SaaS) can be frustrating.

To simplify maintenance, and governance, GitLab Guard enforces your organisation’s compliance standards in a clever way. It will audit every project, and ensure they keep in line with the your defined standards.

🏗 Architecture

We made GitLab Guard as simple as possible, and thus came up with the following architectural design:

• GitLab Guard is shipped as a Docker image, so you don’t have to fiddle with the setup

• There’s no «running service», as GitLab Guard is triggered by a GitLab CI pipeline

• GitLab Guard runs in the CI pipeline itself

• GitLab Guard provides a 🧩 Default configuration out of the box

• The 🧩 Default configuration can be overridden with a site, and dedicated project configurations

• Everything is built with a convention over configuration approach