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.
At a glance
What this is: This is a GitOps explainer focused on cloud-native authorization, showing how Git-based change control improves traceability, rollback, and consistency for CI/CD and Kubernetes environments.
Why it matters: It matters because IAM and IGA teams increasingly need authorization changes to be auditable, testable, and recoverable within the same workflows that deliver software and infrastructure.
Context
GitOps is a change-control model that uses Git as the system of record for configuration, deployment, and policy changes. In cloud-native environments, that matters because authorization is no longer separate from delivery pipelines, and drift between code, config, and policy can create hidden access differences.
For identity practitioners, the important shift is governance: approvals, rollback, version history, and accountability become part of the authorization lifecycle rather than external controls bolted on afterward. That affects human IAM, service identity administration, and policy management in Kubernetes and CI/CD.
Cerbos presents GitOps as a practical way to manage cloud-native authorization, but the deeper issue is not the toolchain. It is whether teams can prove who changed access logic, when it changed, and whether the running environment still matches the approved state.
Key questions
Q: What breaks when authorization policy is edited outside Git?
A: Change control breaks first, followed by traceability and consistency. Without Git, teams lose a clear review trail, policy diffs become harder to inspect, and different services can drift into inconsistent access decisions. That makes it much easier for permission changes to bypass governance or be applied unevenly.
Q: Why does GitOps make authorization governance more complex?
A: GitOps improves visibility, but it also creates a stronger dependency on the integrity of the pipeline that turns policy code into runtime enforcement. If the delivery path is weak, a correct policy in source control can still become an incorrect policy in production. Governance has to include deployment provenance, not just configuration review.
Q: How do teams detect authorization drift in Kubernetes deployments?
A: By comparing the declared policy in Git with the live state in each cluster or environment, then flagging differences as governance issues rather than treating them as harmless configuration noise. That comparison should be part of continuous delivery, not an occasional audit.
Q: What is the difference between GitOps for authorization and manual change control?
A: Manual change control depends on people remembering to document and propagate access updates, while GitOps embeds that control into the repository and deployment flow itself. The practical difference is that GitOps gives you a versioned audit trail, repeatable rollout, and a clearer rollback path for policy changes.
Technical breakdown
Git as the policy source of truth for authorization
GitOps applies Git's version control model to infrastructure and authorization policy, so the repository becomes the authoritative record for desired state. In practice, that means policy files, environment definitions, and deployment inputs are reviewed, merged, and promoted through the same controlled workflow as application code. For authorization, this removes hidden edits and creates a durable history of policy intent. It also makes policy changes testable before they reach runtime, which is especially important when cloud-native platforms combine fast delivery with fine-grained access control. Practical implication: Treat authorization policy like code and require the same review and release discipline as application changes.
Practical implication: Treat authorization policy like code and require the same review and release discipline as application changes.
Why GitOps reduces configuration drift in Kubernetes workflows
Kubernetes environments are prone to drift because clusters, namespaces, and workloads evolve independently across teams and environments. GitOps narrows that gap by continuously comparing the declared state in Git with what is actually running, then reconciling differences through repeatable deployment paths. For authorization, this matters because access rules and service permissions can diverge just as easily as infrastructure manifests. If one cluster or environment is out of sync, identity decisions can vary even when the application appears identical. Practical implication: Use reconciliation and version comparison to detect authorization drift before it becomes a production access issue.
Practical implication: Use reconciliation and version comparison to detect authorization drift before it becomes a production access issue.
Why auditability and rollback matter for cloud-native access decisions
When authorization is managed through GitOps, every change has an audit trail, a reviewer, and a rollback path. That makes it easier to answer basic governance questions such as who approved a policy update, which version is active, and what changed between releases. For IAM and IGA teams, this is valuable because access control failures are often not caused by a single bad decision but by an untracked sequence of small edits. Git-based workflows do not remove the need for policy design, but they make the control history visible and reversible. Practical implication: Build rollback and decision traceability into authorization governance, not just into deployment operations.
Practical implication: Build rollback and decision traceability into authorization governance, not just into deployment operations.
Threat narrative
Attacker objective: The objective is to gain or preserve unauthorized access paths by exploiting inconsistent, ungoverned, or drifted authorization state.
- Entry begins when teams make authorization or configuration changes outside a governed Git workflow, which creates an untracked path into the deployment and policy state.
- Escalation follows when divergent policy or environment files are promoted without consistent review, allowing access decisions to vary across clusters or releases.
- Impact appears as configuration drift, unclear accountability, and harder rollback, which can leave cloud-native authorization inconsistent across environments.
Breaches seen in the wild
- Millions of Misconfigured Git Servers Leaking Secrets: Nearly 5 million misconfigured Git servers expose sensitive secrets and credentials online.
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
GitOps turns authorization into a governed state problem, not just a deployment problem. Once access policy lives in Git, the control surface includes review, versioning, and promotion discipline. That matters because cloud-native authorization failures are often configuration failures that masquerade as runtime issues. The practical consequence is that IAM, IGA, and platform teams have to treat policy drift as a governance signal, not only as an operations defect.
Authorization traceability becomes a first-class identity control in GitOps workflows. Git history gives teams a defensible record of who changed policy, what changed, and when it was merged. That is especially relevant where multiple teams touch the same access model across Kubernetes, CI/CD, and application policy. The practitioner conclusion is that approval lineage and rollbackability now sit inside the identity control model itself.
Cloud-native authorization needs the same lifecycle thinking as NHI governance. Even when the article focuses on policy rather than credentials, the same governance pattern applies: changes must be owned, reviewed, promoted, and retired in a controlled sequence. That aligns with NHI lifecycle discipline because policy and workload identity often change together. Teams should therefore evaluate authorization changes as lifecycle events, not isolated edits.
GitOps helps expose the hidden cost of environment-specific authorization drift. Different clusters, pipelines, or service variants can end up with different access rules even when the application code is identical. That creates an identity governance blind spot because the same actor can be treated differently depending on where the request lands. The implication for practitioners is straightforward: standardise authorization policy promotion across environments or accept inconsistent access outcomes.
Named concept: authorization drift control. This article points to a governance pattern where the real risk is not just misconfiguration but unmanaged variation between declared and running access state. That concept is useful because it connects CI/CD discipline to identity assurance in a way security teams can operationalise. Practitioners should use it to frame review, reconciliation, and rollback as access controls, not only release mechanics.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: NHI Lifecycle Management Guide
What this signals
GitOps will not fix weak authorization design, but it does make hidden policy variation visible. For IAM and platform teams, that visibility is the difference between reacting to access surprises and governing access as a controlled lifecycle.
Authorization drift control: teams need to treat drift between declared policy and running policy as an identity governance defect. Once access rules are promoted through Git, the real control question becomes whether the live environment still matches the approved state.
This is where GitOps starts to intersect with NHI lifecycle discipline. When service access, deployment paths, and policy files change together, the review process has to cover the full change chain or the organization will only govern part of the access model.
For practitioners
- Standardise authorization policy in Git Keep access rules, policy files, and environment configuration in version control so reviews and merges govern every change to the desired state.
- Reconcile declared and running state Continuously compare the repository version to the live cluster or deployment target so policy drift is visible before it affects access decisions.
- Require change traceability for access updates Make every authorization change attributable to a commit, reviewer, and release path so teams can answer who approved the active policy.
- Test policy before promotion Use CI checks to validate authorization logic and configuration in the same pipeline that promotes code, rather than after deployment.
Key takeaways
- GitOps makes cloud-native authorization more governable by tying access changes to version control, review, and rollback.
- The operational risk is not just deployment inconsistency but policy drift across environments and clusters.
- IAM and IGA teams should treat authorization changes as lifecycle events that need traceability, reconciliation, and promotion control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing authorization changes and access state. |
| Recommendation — Apply PR.AA-05 to keep policy changes versioned, reviewed, and aligned to approved access. | ||
| CIS Controls v8 | CIS-5 — Account Management | GitOps for authorization affects how account and access changes are tracked across environments. |
| Recommendation — Use CIS-5 to enforce accountable access change tracking and removal of stale permissions. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Cloud-native authorization drift can leave services and workloads with broader access than intended. |
| NHI-08 — Environment Isolation | The article repeatedly discusses different environments diverging from the same declared configuration. | |
| Recommendation — Review service permissions for overprivilege and align them to the declared Git-managed policy. Separate and reconcile environment-specific policy so one cluster's access state does not leak into another. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The breach examples and governance risk both involve leaked or exposed access paths through Git artifacts. |
| Recommendation — Hunt for exposed credentials in Git-backed workflows and revoke any leaked access immediately. | ||
Key terms
- GitOps: GitOps is an operating model that uses Git as the authoritative record for infrastructure, deployment, and policy changes. Teams declare desired state in version-controlled files, then use automation to reconcile the live environment back to that state and preserve a clear change history.
- Auth drift: Auth drift is the gap between an authentication implementation and the real identity model it is supposed to enforce. It often appears when generated code, schema assumptions, and tests all agree with one another, but none of them match live users, real credentials, or production lookup paths.
- Declarative State: Declarative state is the intended end state recorded in configuration files rather than a step-by-step procedure for reaching it. For authorization, it gives teams a stable policy target that can be compared against live environments and validated before release.
- Policy Promotion: Policy promotion is the controlled movement of access rules or configuration from one environment to another through an approved workflow. It reduces the risk that authorization changes are made informally, skipped across environments, or deployed without review.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org