Check compliance of pipelines via YAML schema at instance level
Problem to solve
Enterprises are starting to use the force includes feature (#8429 (closed)) to bring in various jobs that need to be done, usually at the beginning or end, in order to meet compliance or security requirements. What's missing, though is an easy way to validate that the ending YAML, after all includes are parsed, is still compliant to some enterprise-specific specification.
Intended users
Automation engineers who are implementing compliance or security requirements in the pipeline.
Further details
It would be possible to implement something like this yourself using a custom runner, but then this would not be guaranteed for users using shared runners, or for teams who might deploy their own runners. Since this is about compliance and security, this should be enforced outside of the runner (via a customer executor), and outside of the .gitlab-ci.yml
itself (by adding self-check jobs) since these could be circumvented - particularly easily in the second case.
Rx (https://github.com/rjbs/rx) is one possible YAML schema syntax.
Proposal
- Add a pre-run check (before any job starts) to validate the combined YAML after all includes validates against a user-provided schema.
- The validation schema would be provided at the instance level.
- This check should occur at the same time we check for invalid YAML.
- If no schema is provided, the check always passes.
- If the resultant YAML does not validate against the schema, the pipeline fails to start with a clear error (similar to the invalid YAML error.)
Permissions and Security
Because this is an instance level configuration outside of the runner and outside of the .gitlab-ci.yml
itself, it is more immune to tampering.