Redis or Not: Argo CD & GitOps from an Attacker's Perspective

The speakers start by asking why GitOps deserves security research. They point to recurring mentions at cloud-native conferences and to a CNCF survey showing heavy adoption, then select Argo CD, a Kubernetes-focused continuous delivery tool, as the target. They explain how it treats a git repository as the source of truth and syncs that state into a cluster through a Redis cache server.

Probing that cache, the researchers found that it held the full set of application manifests. Their first attempt to inject a privileged pod directly into Redis was reverted by the sync process. Reading the open-source code, they found that the cache entry hash was a non-cryptographic checksum meant only to catch data corruption. They recalculated the hash for a modified manifest, and the altered deployment was accepted. From a pod with low privileges, this gave them access to other pods' filesystems and secrets, the ability to sniff and intercept production traffic, and a route to the node's cloud identity. The flaw was rated 9.1 and fixed with the Argo CD maintainers.

The closing takeaways are to update Argo CD, run the GitOps controller in a separate cluster, enforce network policies with a CNI plugin that supports them, and grant the tool only the permissions it needs rather than default admin rights. A recorded demo showed the full path from a compromised pod to cluster control.