Pull vs Push Delivery

## Two directions of travel "Delivery" here means getting a change from a repository into a running Kubernetes cluster. Both models begin with the same thing: a commit that describes the desired state — a Deployment manifest, a chart's values, a kustomization. What separates them is which side initiates the connection. In **push-based** delivery the CI/CD pipeline is the actor. A job in the pipeline authenticates to the cluster's API server and issues imperative commands against it: `kubectl apply -f`, `kubectl set image`, `helm upgrade --install`, or a vendor CLI wrapping the same calls. The pipeline decides when the deploy happens, watches it, and reports success or failure in the same job. In **pull-based** delivery a piece of software running inside the cluster is the actor. It watches a Git repository (or an OCI artifact holding the same manifests), notices that the declared state differs from what is running, and applies the difference to its own cluster's API server. The pipeline's last deployment-related act is a commit; nothing in CI ever talks to the cluster. ## Where the credential sits This is the part interviewers are actually testing. Under push, something outside the cluster must be able to authenticate as a highly privileged principal to the Kubernetes API — a kubeconfig with a client certificate or token, or a cloud IAM identity mapped to cluster roles. That credential is stored in the CI system, injected into a job that also executes build scripts and third-party dependencies, and it exists once per environment. A team with dev, staging and production has three sets of cluster credentials concentrated in one system. ```bash # Push model: the CI job authenticates to the cluster itself echo "$KUBECONFIG_CONTENT" > "$HOME/.kube/config" kubectl set image deployment/web web=registry.example.com/web:1.4.2 kubectl rollout status deployment/web --timeout=120s ``` Under pull, the credential the agent uses is an in-cluster ServiceAccount bound to roles in that same cluster. It is created at install time and never leaves the cluster boundary — there is nothing to copy into CI, nothing to rotate across systems, and no single external account that can reach every environment. What CI needs instead is write access to the configuration repository and push access to an image registry. ```bash # Pull model: CI's last deployment act is a commit sed -i 's|tag: .*|tag: "1.4.2"|' env/prod/values.yaml git commit -am "prod: web 1.4.2" && git push # an in-cluster agent notices the change and applies it ``` Using short-lived federated credentials instead of a static kubeconfig narrows the push model's exposure, but it does not change the shape: a system outside the cluster is still able to obtain API access, and it is still reachable by whatever runs in that pipeline. ## Direction of network connections The second structural difference follows from the first. Push requires the API server to be reachable from wherever the runner executes — a hosted runner on the public internet, a runner placed inside the VPC, or a VPN/private-link path. Pull requires only outbound connections from the cluster to the Git host and the registry, both ordinary HTTPS or SSH egress. For clusters with no inbound exposure at all, that difference decides the design. ## What the pull model does not change A weak answer treats pull as "the secure one" and stops. It relocates trust rather than removing it: - **Git becomes the control surface.** Anyone who can merge to the watched branch can change production. Review, branch protection and commit signing now carry the weight the cluster credential used to. - **The agent is privileged.** It typically holds broad apply rights inside its cluster, so it is itself a target and should be scoped to the namespaces or tenants it owns. - **Images still come from a registry.** A poisoned image referenced by a legitimate tag is applied just as faithfully. - **Someone still needs cluster access for humans** — debugging, logs, incident response — so the API server does not become unreachable to everyone. ## Saying it in an interview Name the actor and the credential in one breath: push means CI reaches into the cluster with a kubeconfig it stores; pull means the cluster reaches out to Git with credentials that never leave it. Then say what that buys — a smaller and better-scoped blast radius when the CI system is compromised — and what it costs, which is that your pipeline no longer learns synchronously whether the deploy worked.