Lock down path to production
Problem to solve
Companies need to enforce a compliant path to production.
Release Managers and Security compliance analysts
Enterprises have various compliance needs, and some compliance can be handled through proper auditing and a standardized, prescriptive deployment pipeline, but some compliance targets need to enforce certain aspects of the path to production. e.g. that certain security tests have run and passed, that qualified people trigger deployment to production, that build images are created in a certain fashion, etc.
Lock down each of:
- CI/CD code
- CI/CD code execution
- CI/CD data
- Build execution
e.g. Enforce code+runner+data+binauthz
.gitlab-ci.ymlso only admins can modify it. There are actually a number of ways to do this; these are related and you can imagine more:
- Lock runners so code+data can't be misused. There are probably also more ways to secure the runners here as well.
Lock attestation signature token so only available to locked code, and use it for signing during CI pipeline or release creation (https://gitlab.com/gitlab-org/gitlab-ee/issues/7268). Optionally, enforce various kinds of attestations (security test ran, compliance checks, etc., possibly using https://gitlab.com/gitlab-org/gitlab-ce/issues/56030)
Lock cluster so only compliant builds are executed (e.g.
includeing a local YML so devs can customize part of the pipeline, but compliant YML is parsed after, so overrides.
- Tie project or group variables to certain named jobs, which you ensure are unmodified by virtue of above.
e.g. environment-specific variables are insufficient if someone can create a new job that also deploys to
production which then steals attestation signature token and spoofs a payload.
These should be summarized in a blog post (gitlab-com/www-gitlab-com#3678) detailing how to secure your pipelines and delivery.
What does success look like, and how can we measure that?
Enterprise companies adopt GitLab for compliant deployment to production.