Key takeaway: Push-based deployment means your CI system holds production credentials. Pull-based GitOps means it never does, because the cluster reaches out to Git instead of Git reaching into the cluster.
The Credential Problem Push Creates
A conventional pipeline authenticates to the cluster and applies manifests. That means the CI system — a shared, internet-connected service running arbitrary third-party actions — holds a credential capable of modifying production.
Every plugin, every dependency, every misconfigured job in that CI system is now a potential path to a production credential. Supply chain compromises targeting CI platforms specifically exploit this, because compromising the pipeline is equivalent to compromising the cluster it deploys to.
What Changes With a Pull Model
An agent running inside the cluster — Argo CD or Flux are the common choices — polls a Git repository and reconciles cluster state to match it. The CI pipeline’s job ends at pushing a commit. It never touches the cluster directly and needs no cluster credential at all.
| Property | Push (CI deploys) | Pull (agent reconciles) |
|---|---|---|
| CI holds cluster credentials | Yes | No |
| Attack surface for cluster access | CI system + cluster | Cluster only |
| Drift detection | None built in | Continuous |
| Disaster recovery | Manual rebuild | Point agent at repo |
| Audit trail | CI logs | Git history |
Drift detection falls out of the architecture for free. Because the agent continuously compares live state to the repository, a manual change made directly against the cluster is visible immediately as a divergence, rather than being silently overwritten by the next unrelated deploy.
The Audit Trail Advantage
Every change becomes a commit with an author, a timestamp and, typically, a review approval. That is a fundamentally better record than CI system logs, which are usually retained briefly and rarely reviewed after the fact.
For regulated environments this matters concretely: demonstrating who approved a specific production change is a Git log query rather than a forensic exercise across a pipeline’s execution history.
What It Does Not Solve
GitOps secures the deployment mechanism and says nothing about what is deployed. A manifest committed to the repository with a critical vulnerability in its image still gets applied faithfully — the agent does not evaluate whether the change is wise, only whether it matches the repository.
Secrets management remains a separate problem. Committing a plaintext secret to the repository that the agent reads is worse than a push-based leak, because the secret is now in Git history rather than in a single pipeline run’s logs. Sealed secrets or an external secrets operator that resolves references at apply time is necessary alongside GitOps, not optional.
The repository itself becomes the new high-value target. Write access to the Git repository is now equivalent to write access to production, so branch protection, mandatory review and strong authentication on the repository matter as much as cluster security did under the old model.
Adopting It Incrementally
Start with a non-critical workload to validate the reconciliation behaviour and drift alerting before migrating anything load-bearing. Confirm the team understands that a manual kubectl apply for an emergency fix will be silently reverted by the next reconciliation cycle unless it is also committed to the repository — this surprises teams migrating from push-based deploys and causes exactly the kind of incident GitOps was meant to prevent.
The Bottom Line
Move to pull-based deployment so the CI system never holds a production credential, and treat the Git repository itself as the new security boundary requiring the same rigour the cluster used to demand directly. Pair it with proper secrets handling, since GitOps secures how changes are applied, not what gets committed.
