In this lesson, you will learn how to evaluate the security advantages of moving from external push-based CI/CD pipelines to internal pull-based GitOps controllers.
The Push-Based Deployment Model
In a traditional push-based model, your CI/CD pipeline server (e.g., Jenkins, GitHub Actions, or GitLab CI) acts as the initiator. Once a build completes, the pipeline triggers a command—usually kubectl apply or helm upgrade—to push changes into your Kubernetes cluster.
To make this work, the CI tool must be granted cluster-admin or write-level credentials. These secrets are stored within the CI platform, creating a "leaky" security perimeter: if your CI/CD platform is compromised, an attacker gains full access to your production infrastructure.
The Pull-Based Deployment Model
The pull-based model, central to the GitOps pattern, inverts this relationship. Instead of the CI server pushing changes, you install an agent (like Argo CD or Flux) inside your cluster. This agent acts as a controller that monitors a Git repository for configuration changes.
When you update your declarative manifests, the agent detects the drift and "pulls" the new state into the cluster.
Security Benefits
- Zero External Access: You no longer need to expose your Kubernetes API server to your CI/CD platform. The firewall only needs to allow outbound traffic from the cluster to your Git provider, significantly reducing the attack surface.
- Principle of Least Privilege: Because the agent lives inside the cluster and runs with a service account, you can restrict its permissions to specific namespaces or resources, preventing a compromised build server from gaining cluster-wide control.
- Automatic Drift Correction: If someone manually modifies a resource in the cluster, the pull-based controller detects the inconsistency with the source of truth in Git and automatically reverts the change, ensuring higher security posture through continuous reconciliation.
# Push-based logic (Pipeline triggers)
- run: kubectl apply -f deployment.yaml # Relies on external, high-privilege credentials
# Pull-based logic (Controller reconciles)
# The agent is already running inside, watching Git
# No external credentials needed for deployment operations
Key Takeaway: By shifting from push to pull, you encapsulate your deployment credentials inside the cluster perimeter, minimizing the blast radius of CI/CD platform compromises.