TL;DR: Automating policy uploads from GitLab CI/CD centralises policy delivery, but it also places Cerbos Hub client credentials inside pipeline variables and runner execution paths, according to Cerbos documentation. Secret handling, branch controls, and runner trust now become part of the policy deployment model, not just DevOps plumbing.
NHIMG editorial — based on content published by Cerbos: GitLab CI/CD policy upload to Cerbos Hub
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
Questions worth separating out
Q: How should security teams govern CI/CD jobs that publish security policy?
A: Treat the publishing job as a privileged non-human identity, not a build task.
Q: Why do CI/CD pipelines create secret governance risk?
A: Because they combine stored credentials, automated execution, and broad operational access in one place.
Q: What do teams get wrong about branch protection and policy deployment?
A: They often assume branch protection also protects the downstream action.
Practitioner guidance
- Separate publishing credentials from developer workflow Use a dedicated Cerbos Hub client credential only for policy upload jobs, and do not reuse it for testing, local tooling, or other API calls.
- Harden GitLab variable handling Store the upload secret only in protected, masked variables and restrict access to the minimum projects and branches that need policy publication.
- Add approval gates for policy changes Require code review and explicit approval for changes that affect the upload job, the branch rule, or the target store ID.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Exact GitLab CI/CD YAML needed to upload policies into a Cerbos Hub store
- Step-by-step setup of protected and masked CI/CD variables for the upload credential
- The specific command used by cerbosctl to replace policy files in the target store
- The verification flow in GitLab Pipelines after the main-branch push
👉 Read Cerbos' guide to GitLab CI/CD policy uploads for Cerbos Hub →
GitLab policy uploads to Cerbos Hub: what IAM teams should check?
Explore further