The trust decision — choosing the right model for your organisation

The choice between push, pull, and hybrid is not a fashion decision. It is a decision driven by the organisation: its trust in its Git repository, its cluster topology, its team’s capability, its regulatory environment, its tolerance for blast radius, and the cost of migration. This lesson lays out the factors and shows how to arrive at a choice that holds up to an auditor’s questions.

The decision factors

Six factors matter, in roughly this order of weight:

flowchart LR
    F1["1. Blast-radius tolerance"] --> F2["2. Repository trust"]
    F2 --> F3["3. Cluster topology"]
    F3 --> F4["4. Team capability"]
    F4 --> F5["5. Regulatory environment"]
    F5 --> F6["6. Migration cost"]

1. Blast-radius tolerance

The first question is the simplest: if the CI runner is compromised, what is the worst case? If the answer is “the attacker writes to production directly”, the pull model is indicated. If the answer is “the attacker pushes commits that are reviewed before they apply”, the push model with strong review may be acceptable.

Teams operating critical infrastructure - payment systems, medical records, industrial control - have a low blast-radius tolerance and a strong pull-model argument. Teams operating internal tooling have a higher tolerance and may not justify the operational cost.

2. Repository trust

The pull model trusts Git as the source of desired state. If the repository is well-protected (branch protection, required reviewers, signed commits, signed tags, audit logging, principle of least privilege on tokens), the trust is reasonable. If the repository is a free-for-all with no branch protection and personal access keys committed to pipelines, the trust is not reasonable - and the pull model would be a regression.

flowchart LR
    subgraph Trusted["Trusted repository"]
        T1["Branch protection"] --> T2["Required reviewers"]
        T2 --> T3["Signed commits / tags"]
        T3 --> T4["Audit logging"]
    end
    subgraph NotTrusted["Untrusted repository"]
        N1["Direct pushes to main"] --> N2["No required review"]
        N2 --> N3["Long-lived PATs in CI"]
    end

A team that has not invested in repository trust should invest in it before adopting the pull model. The pull model does not remove the need for trust; it concentrates trust in the repository.

3. Cluster topology

Single-cluster teams often find the pull model’s operational cost manageable. Multi-cluster fleets - especially fleets with hundreds of clusters - need either sharded controllers or a multi-cluster control plane, and the operational cost of running the controller on every cluster becomes a real consideration. For very large fleets, a hybrid with a fan-out pipeline may be the right answer.

Teams with one cluster in one cloud can pick whichever model suits the other factors. Teams with clusters in many clouds, many regions, on-prem and cloud, must weigh topology explicitly.

4. Team capability

The push model is familiar. Every engineer who has used kubectl apply understands it. The pull model requires familiarity with controllers, reconciliation loops, polling intervals, and the GitOps mental model - which is one inversion away from how most engineers were trained.

A team that does not yet have the operational muscle for controllers may choose push with disciplined credentials. A team that does have the muscle can run pull. The capability gap is real; ignoring it produces GitOps deployments that no one can debug when they break.

5. Regulatory environment

Some regulators care about the direction of change. PCI-DSS, for example, requires separation of duties between the person who can change code and the person who can deploy it; the pull model satisfies this more naturally than the push model because the deploy identity is a controller, not a human. HIPAA, SOC 2, and FedRAMP have similar expectations about auditable change control.

Other regulators care about the audit trail rather than the direction. Both models can produce an audit trail; the pull model’s is typically cleaner because Git is the source of truth.

6. Migration cost

The pull model is not free. A team running a push-based pipeline that wants to migrate to pull has to:

• Install the controller on every cluster
• Migrate existing manifests to the GitOps repository
• Rotate the existing CI credentials (they will no longer be needed)
• Train the team on the new operational model
• Run the two models in parallel during the transition

The migration cost is real. The question is whether the blast-radius reduction justifies it. For some teams the answer is clearly yes; for others it is clearly no; for most it is “yes, but only for the highest-value clusters first”.

A defensible choice

A choice is defensible when it can be stated in terms of the factors above, not in terms of fashion. Two examples:

Team W runs push-based CD for internal tooling because the blast-radius tolerance is high (the worst case is a temporary outage of an internal dashboard) and the migration cost to pull is not justified. The push credentials are scoped to a namespace-scoped Role and rotated on a schedule.

Team X runs pull-based GitOps for production payment systems because the blast-radius tolerance is low (the worst case is direct writes to payment infrastructure), the repository is well-protected with branch protection and signed commits, and the team has the operational muscle to maintain Argo CD on every cluster. The push credentials are removed from the runner.

Both choices are defensible. Neither is dogmatic. The factors that drove the choice are named; an auditor can interrogate them; the team can revisit them if the factors change.

Production discipline

1. Write the decision down. The choice of push, pull, or hybrid should be a written decision that names the factors and the trade-offs. A decision that lives in one engineer’s head is a decision that disappears when they leave.
2. Review the decision annually. The factors change: repository trust improves, team capability grows, regulatory requirements evolve, new systems appear. The decision should be revisited on a cadence.
3. Per-system, not per-organisation. Different systems have different blast-radius tolerances, different regulatory requirements, different topology. The right answer for the payment system is rarely the right answer for the internal wiki.

Cross-course references

• Kubernetes for Production Sysadmins - Parts on RBAC and controllers cover the operational side of the pull model.
• Terraform for Production Sysadmins - Parts on the operator pattern cover the pull analogue for infrastructure.
• Ansible for Production Sysadmins - Parts on AWX / Tower cover the pull analogue for configuration management.

Quiz