Notifications
Clear all
Topic starter
11/06/2026 11:45 pm
TL;DR: GitOps formalises infrastructure and authorization changes through Git as a source of truth, improving traceability, rollback, and environment consistency across CI/CD and Kubernetes workflows according to Cerbos. The governance shift matters because change control, auditability, and policy drift detection become part of the identity and access model, not just the deployment pipeline.
NHIMG editorial — based on content published by Cerbos: GitOps guidance for cloud-native authorization and deployment workflows
Questions worth separating out
Q: How should teams govern authorization policy changes in GitOps pipelines?
A: Treat policy changes like code changes.
Q: Why do GitOps workflows matter for identity and access governance?
A: They matter because many access-relevant changes now happen in configuration, not in a traditional IAM console.
Q: What breaks when deployment permissions are too broad in GitOps?
A: Broad repository or pipeline permissions let a single change affect infrastructure, application behaviour, and access policy at the same time.
Practitioner guidance
- Version authorization policy alongside application code Store access control rules in the same repository and promotion flow as application changes so policy updates are reviewed, tested, and traceable before release.
- Restrict repository and pipeline change rights Limit who can modify deployment manifests, policy files, and CI/CD workflows, then review those privileges as high-impact access because they can alter runtime behaviour.
- Add drift checks between Git and live environments Compare declared configuration with running state in Kubernetes and other deployment targets so unauthorized or accidental divergence is visible before it accumulates.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step setup examples for installing Cerbos with Docker, Homebrew, or Helm.
- API request examples for checking decisions and retrieving audit log entries.
- GitHub Actions configuration for compiling and testing policies in CI.
- Tutorial references for getting started with test applications and JWT or Auth0 integration.
👉 Read Cerbos' guide to GitOps for cloud-native authorization →
GitOps for authorization and CI/CD: what teams need to know?
Explore further
12/06/2026 8:35 am
GitOps turns configuration drift into a governance problem, not just an operations problem. When infrastructure, deployment logic, and authorization policy all live in Git, the repository becomes the control plane for change accountability. That matters to identity teams because access decisions increasingly depend on configuration that can change outside traditional IAM workflows. The practitioner conclusion is that review, approval, and rollback need to follow the same source of truth as the systems they govern.
A few things that frame the scale:
- 15% of commit authors have leaked at least one secret in their contribution history, according to The State of Secrets Sprawl 2025.
- 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
A question worth separating out:
Q: How can security teams tell whether GitOps is really improving governance?
A: Look for consistent commit-to-deployment traceability, low configuration drift, and clear rollback records tied to specific changes. If teams cannot explain who changed what, or if live systems regularly diverge from the repository, GitOps is not delivering its governance promise.
👉 Read our full editorial: GitOps changes how teams govern cloud-native authorization
