Pulled automatically — the controller reaches out to Git

The third OpenGitOps principle - pulled automatically - is the one that changes the security model. In a traditional CI/CD pipeline, the runner authenticates to the cluster and pushes state. In a GitOps model, the controller inside the cluster authenticates to Git (or to a Git proxy) and pulls state. The direction is inverted; the trust boundary moves accordingly.

The contrast in one picture:

flowchart LR
    subgraph Push["Push-based CD"]
        CI1["CI runner"] -->|"cluster credentials"| K1["Cluster API"]
    end
    subgraph Pull["Pull-based GitOps"]
        G["Git repository"]
        C["Controller in cluster"] -->|"read-only token"| G
        C -->|"in-cluster write"| K2["Cluster API"]
    end

In the push model, the CI runner holds credentials capable of writing to the cluster. An attacker who compromises the CI runner, or a malicious CI job that exfiltrates the credentials, can write directly to production. In the pull model, the CI runner does not hold cluster credentials at all; the only thing it can do is commit to Git, and the controller inside the cluster decides what to apply based on what it reads from Git.

What the pull model buys

Three operational properties:

1. Reduced blast radius for an external compromise. A compromised CI runner can push commits to Git, but it cannot push to the cluster directly. The controller must read the commit, observe the diff, and apply it - and the controller has its own admission controls, rate limits, and audit trail.
2. No long-lived cluster credentials in CI. The CI runner does not need a kubeconfig with cluster-admin. The runner may not need any kubeconfig at all. The credentials exist only in the cluster’s controller pod, which the cluster itself protects.
3. Drift correction without redeploys. The controller is always running, not just at the end of a CI pipeline. A configuration drift introduced by any actor - manual edit, bug, attacker - is corrected by the next reconciliation tick.

What the pull model requires

The controller is a long-running process in the cluster. It needs:

• Read access to the Git repository. Either a deploy key, a fine-grained personal access token, or a Git proxy (one common pattern is gitrepository-controller in Argo CD or Flux).
• Write access to the cluster API. Service account tokens, IRSA, Workload Identity, or a kubeconfig mounted into the controller pod.
• A reconciliation interval. The cadence at which the controller re-reads Git and re-applies. Three minutes is a common default; ten seconds is the lower bound.

flux get all

This is the Flux CLI command that lists every GitOps resource the controller is reconciling - GitRepositories, Kustomizations, HelmReleases, and the alerts or events each one has produced.

Where the trust boundary actually sits

In the push model, the trust boundary is between CI and the cluster. The cluster must trust CI; CI must hold cluster credentials.

In the pull model, the trust boundary is between Git and the controller. The controller must trust Git; Git must hold a deploy key. The cluster’s write API is no longer reachable from outside the cluster’s network - it is reachable only from inside the cluster, by the controller pod, on the in-cluster network.

A practical consequence: a Kubernetes cluster running GitOps can run with the API server’s internet-facing endpoint disabled, because the controller does not need to be reached from outside - it reaches out. The cluster becomes a sealed system that pulls its configuration from a known source.

How often does the controller pull?

Three patterns:

• Polling. The controller wakes every N seconds and git ls-remote against the repo. Simple, robust, works against any Git host. Default in Argo CD and Flux.
• Webhook. The Git host POSTs to the controller’s webhook endpoint when a ref is updated. Lower latency, requires the Git host to be reachable from the controller.
• Push reconciliation. Some controllers expose a CLI command to force a reconciliation; CI can call it after a merge. Useful for back-pressure on slow polling intervals.

The polling interval is the system’s reconciliation latency ceiling. A three-minute poll means a commit can take up to three minutes to be applied. A thirty-second poll means a commit is usually applied in seconds.

Production discipline

1. The controller’s credentials are cluster-scoped. The controller needs write access to the cluster API; that access must be on a dedicated service account with a tight RBAC role. Cluster-admin is a placeholder, not a production setting.
2. The repository’s deploy key is read-only. The controller never needs to write to the repository. A read-only deploy key (or a fine-grained token with read only) limits what a controller compromise can exfiltrate.
3. The reconciliation interval matches the change cadence. A polling interval of 3 minutes is fine for hourly deploys; a polling interval of 30 seconds is required for hot-fixes that need to land within the hour.

Cross-course references

• Ansible for Production Sysadmins - Part XXXIX covers the pull-mode Ansible Tower / AWX model; the trust boundary is inverted in the same way.
• Terraform for Production Sysadmins - Parts XXVIII- XXX cover the operator-pattern Terraform run, which is the pull analogue for IaC.
• Kubernetes for Production Sysadmins - Parts on controllers cover the in-cluster loop pattern the GitOps controller relies on.

Quiz