Kubernetes 2 min read

GitOps Changes What Your Pipeline Is Allowed to Do

GitOps is usually sold as "declarative deploys". The real change is smaller and stricter: CI stops touching production, and that fixes a lot.

GitOps Changes What Your Pipeline Is Allowed to Do
Kubernetes · September 24, 2026

Most "GitOps" migrations change nothing: a pipeline still runs kubectl apply, only now the YAML lives in a repo. That is version control, which you already had.

The genuine shift is about who is allowed to touch the cluster.

Before: the pipeline is god

In a conventional setup, CI holds cluster credentials and pushes whatever it built. Every job, every fork, every compromised dependency inherits production write access. The blast radius of your CI system is your entire fleet.

After: the cluster pulls, CI only proposes

In real GitOps — Argo CD or Flux watching a repo — the roles invert:

  • CI builds, tests, and writes a change to Git (a new image tag, a new manifest). It has no cluster credentials at all.
  • The GitOps controller runs inside the cluster, reads Git, and reconciles reality toward it. It is the only thing with write access.
push -> CI builds & tests -> CI commits manifest change -> Git
                                  |
                                  v
                  controller reconciles cluster toward Git

The consequence is structural, not cultural: a compromised build job can no longer reach production directly. It can only propose a change that lands in Git, where review, signing and history apply.

What you actually gain

  1. A smaller credential blast radius. CI loses the keys; the controller holds them, in-cluster.
  2. Drift detection for free. The controller notices when reality diverges from Git and either heals it or alarms.
  3. Rollback is a revert. git revert plus reconciliation is your rollback path — no bespoke deploy tooling to maintain.
  4. An audit trail that is just Git history. Who changed what, when, and why, with a PR attached.

What it does not give you

GitOps does not test your manifests, does not validate that the image works, and does not stop a bad change from syncing quickly to every cluster. Your CI still has to be good; GitOps only moves the last mile.

GitOps is not a deploy tool. It is a decision about where production write access lives.

Make that decision deliberately and the rest — the controllers, the repos, the sync waves — is detail. Skip it and you have added a component without adding a property.

PB
Written by

Parul Bedi

Part of the Azure Gravy writing team.

Conversation

0 comments

No comments yet. Start the conversation below.

Leave a comment

Replying to a comment.
Be kind. Markdown is not supported in comments.
Keep reading

Related posts

All posts