The "Push" Model (Traditional CI/CD)
Historically, deployment was a "push" process. Think of it like a delivery driver who has a master key to every building they deliver to — convenient, but a serious security risk if that key is ever stolen.
The push workflow looks like this:
1. A developer commits code.
2. A CI server (like Jenkins or GitHub Actions) detects the change, builds an artifact, and runs tests.
3. The CI server connects to the Kubernetes cluster using stored admin credentials and runs commands like kubectl apply -f deployment.yaml to push the changes.
The Problems:
- Your CI server holds highly privileged credentials to your production cluster. If the CI server is compromised, so is production.
- The CI server has no continuous awareness of cluster state. If someone manually changes the cluster between deployments, the CI server won't know until the next pipeline run.
- Credentials must be rotated across every CI job that deploys to every cluster — a management burden that grows with scale.
The "Pull" Model (Modern GitOps)
GitOps introduces a "pull" model using a special agent that runs inside the cluster itself — like a security guard who lives in the building and checks the official blueprint periodically, rather than letting outsiders in with a master key.
The pull workflow looks like this:
1. A developer opens a Pull Request to the Git repository with the desired change.
2. After review and merge, the GitOps agent running inside the cluster detects the change.
3. The agent pulls the new manifests from Git and applies them using its own in-cluster Kubernetes service account permissions.
The Advantages:
- No external system ever holds cluster admin credentials. The attack surface shrinks dramatically.
- The agent continuously compares Git (desired state) to the cluster (actual state), so drift is detected in near real-time.
- Rollback is a git revert — no special tooling required.