.gitlab-ci.yml as JSON

Problem to solve

Compliance and other topics related to CI configuration need a data structure to get started. As a Security Practitioner, I want a son full representation of a project CI configuration, so I can parse it and take decisions.

Intended users

User experience goal

We already have an API endpoint to lint .gitlab-ci.yml files: https://docs.gitlab.com/ee/api/lint.html
We already have a way to lint these files in the GitLab UI, like https://gitlab.com/gitlab-org/gitlab/-/ci/lint. Doing so will render a representation of the configuration, with all includes being expanded.

Proposal

Extend https://docs.gitlab.com/ee/api/lint.html to also return a full representation of the configuration, like what we have in the liting page.
Or we can create a new endpoint for that.

Further details

We have a way to enforce jobs in pipelines, but it's being reevaluated to something more generic.

This data could be used in many places, but a good MVC is probably a dedicated project running a pipeline to check other projects configurations (in the same group for example). I have in mind that we can check if some jobs have been included, if the script hasn't been overridden, ... This can be used to validate that security scans are running everywhere for example. I would an OPA job to achieve this, but that's just a suggestion to demonstrate the purpose.

It can also be a 2-way compliance check:

  • One job to ensure the validation job is included everywhere, and running (not overridden for example)
  • One job included in every projects pipeline to report violations to developers directly.

Permissions and Security

Everyone with access to the repo should have access to that data.

Documentation

TBD.

Availability & Testing

TBD

What does success look like, and how can we measure that?

  • Number of API calls

What is the type of buyer?

GitLab Core

Is this a cross-stage feature?

Probably lying between devopsverify and devopsmanage (/cc @mattgonzales)

Links / references

#34830 (closed)

/cc @kencjohnston following our discussion this week.