A CI runner that deploys to all your Kubernetes environments is compromised. What does the attacker gain under push-based delivery, and what does moving to pull-based delivery not protect you from?
answer
- all environments, one host
- deploy credentials are rarely least-privilege
- attack moves upstream, not away
- the agent applies a bad commit faithfully
- mutable tags bypass Git entirely
basics
~20 sUnder push, the runner holds cluster credentials for every environment, so the attacker gets immediate admin-level access to all of them. Pull removes that credential, but not a poisoned image or a malicious commit, which the in-cluster agent will apply faithfully.
solid answer
~60 sUnder push delivery the runner is the single place where credentials for dev, staging and production all live, so compromising it yields direct API access to every cluster at once — create workloads, read every Secret, exfiltrate, and do it under the CI identity where the audit trail is thin. Moving to pull removes exactly that: no external system is authorised to call the API server, and each cluster's credential is an in-cluster ServiceAccount scoped to that cluster. What it does not remove is everything upstream of the commit. A compromised runner can still push a malicious image to a tag the manifests reference, or use its write access to the configuration repository to commit a change the agent will obediently apply — a privileged Pod, a mounted host path, an altered image reference. Pull converts "direct cluster access" into "must get a change into Git or the registry", which is only a win if branch protection, review, digest pinning and a narrowly scoped agent are actually in place.
go deeper
Recall the core point: with push, one compromised CI system holds the keys to every cluster; with pull, the credential lives inside each cluster and CI has none.
Explain the mechanics of the concentration — deploy credentials are usually broad, they sit next to untrusted build code, and actions appear in audit logs as the CI identity rather than a person.
Demonstrate the honest half: name the registry and Git paths that survive the migration, say why a mutable tag or a CI-owned repo token is still a deployment credential, and state the controls that make pull a genuine win.
Own the whole chain — provenance and signing for the artifact, merge authority as production access, agent scoping per tenant, and a plan for detection when every path is technically legitimate.
## Why this scenario is asked The pull model's headline justification is a security one, so interviewers probe whether you can reason about it concretely rather than repeat the slogan. The strong answer has two halves: what the credential concentration actually costs you under push, and the honest list of what pull leaves untouched. ## Under push: one host, every environment A push-based delivery pipeline needs, for each environment it deploys to, a principal that can write to that cluster's API server. In practice these are held together in the CI system's secret store and injected into deploy jobs. That produces several compounding problems: - **Concentration.** One compromised runner or one leaked secret-store export yields dev, staging *and* production. There is no blast-radius boundary between environments because the same system holds all of them. - **Privilege.** Deploy credentials are rarely least-privilege. "Apply anything in any namespace" is the easy configuration, and it implies reading every Secret in the cluster, creating a privileged Pod, or scheduling a workload that mounts the host filesystem. - **Co-tenancy with untrusted code.** The same runner executes build scripts, dependency installs and third-party pipeline plugins. Anything achieving code execution in a job sits next to the credential material. - **Weak attribution.** Every action arrives at the API server as the CI identity. Audit logs show that "the pipeline" applied a change; correlating that back to which run, which commit and which human is work you must have set up in advance. - **Persistence.** Long-lived kubeconfigs get copied, cached in job workspaces, and survive rotation policies that nobody enforces. Short-lived federated credentials fix the persistence problem and shrink the window materially. They do not fix concentration or co-tenancy: whatever can run in the pipeline can still request the token. ## What pull actually removes With an in-cluster agent, no external system is authorised to call the API server for deployment. Each cluster's agent authenticates with a ServiceAccount in that cluster, so a compromise of one cluster does not hand over its neighbours, and the CI system holds no cluster credentials to steal. The network posture helps too: a private cluster can refuse all inbound connections and still be deployed to. That is a real structural improvement. The attacker's path is no longer "take the credential, call the API"; it is "get a change into something the cluster trusts". ## What pull does not remove ### The registry path If CI can push images, a compromised runner can publish a malicious image. If manifests reference a mutable tag, the next sync — or the next Pod restart — pulls it, and the agent applies nothing new at all. This is why pinning by digest and, better, verifying signatures or attestations at admission matters more, not less, under GitOps. ### The Git path The hybrid split usually gives CI write access to the configuration repository so it can record image versions. That token is now a deployment credential in disguise. A commit that sets `securityContext.privileged: true`, mounts `/`, or points a workload at an attacker image will be applied faithfully — reconciliation guarantees the cluster matches Git, including when Git is wrong. Controls that matter here: branch protection with required review on the watched branch, restricting CI's token to the narrow path or file it must change, commit signing with verification, and never letting the same identity both approve and merge. ### The agent itself The agent is a privileged in-cluster component with broad apply rights and, in multi-tenant setups, credentials to several clusters. It is now the highest-value target in the cluster. Scope it: per-tenant or per-cluster instances, restrict which repositories and paths it will read, and constrain what kinds of object it may create. ### Everything before the artifact A compromised runner can also alter build output — inject code at compile time, swap a dependency — and produce an artifact that is signed, reviewed, promoted and deployed entirely through the legitimate path. No delivery model detects that; provenance attestation and reproducible builds are the countermeasures, and they are orthogonal to push versus pull. ## How to answer Be specific about the trade, not the label. Something like: push concentrates admin-equivalent credentials for every environment in the system most exposed to untrusted code, so a runner compromise is an immediate multi-environment breach; pull removes that credential entirely and localises trust to each cluster, but it relocates the attack surface onto the repository and the registry — so it is only a net win if merge rights, image provenance and the agent's own scope are treated as the production controls they have now become.
- If CI still has write access to the configuration repository, have you really reduced the blast radius?Yes, but less than the slogan suggests. That token can only propose state; it cannot read Secrets, exec into Pods or act outside what the manifests express, and every change it makes is a reviewable commit rather than an invisible API call. The reduction is real only if the watched branch requires review and CI's token is scoped to the specific paths it must edit.
- How does pinning images by digest change this analysis?It closes the registry path. With a mutable tag, an attacker who can push an image changes what runs without touching Git at all. A digest reference means the running image can only change through a commit, which puts every deployment change back under review — at the cost of needing automation to propose digest bumps.
- What would you monitor to detect abuse of the pull path?Alert on commits to the watched branch that were not produced by the expected pipeline identity or that bypassed review, on manifest diffs touching security-sensitive fields such as privileged containers, host mounts or ServiceAccount bindings, and on the agent applying a revision that no pipeline run produced. The agent's own sync history is the audit trail.
saying these in an interview costs you the question
- Claiming pull-based delivery removes the attack surface rather than moving it
- Forgetting CI's write token to the config repo is a deploy credential
- Ignoring that a mutable image tag changes what runs without any commit
- Assuming the in-cluster agent is low-privilege because it is internal
- Treating short-lived credentials as equivalent to having no credential