Restricting Network Access for Build Agents

Configure network policies and security groups to isolate build agents and restrict their ability to communicate with sensitive internal systems.

In this lesson, you will learn how to harden your CI/CD architecture by isolating build agents at the network layer to prevent lateral movement and unauthorized access to sensitive internal services.

The Problem with Default Connectivity

By default, Kubernetes pods (your build agents) can communicate with any other pod in the cluster. If an attacker compromises a runner during a build process—perhaps via a malicious dependency or a flawed Dockerfile—they could potentially scan your internal network, pivot to your production database, or exfiltrate credentials from internal microservices. We must shift from a "default-allow" posture to a "default-deny" model specifically for our CI/CD namespace.

Implementing Network Isolation

To secure these agents, we use Kubernetes NetworkPolicies. A NetworkPolicy acts as a firewall for your pods. When you assign labels to your runner pods, you can create a policy that isolates them from everything except essential traffic (like the Kubernetes API server or your internal artifact registry).

Consider this example of a policy that isolates app=build-agent pods by denying all ingress and egress traffic by default, then explicitly allowing only what is necessary:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: isolate-build-agents
  namespace: ci-cd
spec:
  podSelector:
    matchLabels:
      app: build-agent
  policyTypes:
  - Ingress
  - Egress
  # Default Deny: ingress and egress are now blocked for these pods
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: internal-registry # Only allow talking to the registry

Strategic Security Groups

If your agents run on cloud-provisioned nodes (e.g., AWS EC2 instances managed by Karpenter or cluster autoscalers), you should complement Kubernetes policies with Cloud Security Groups. By restricting the underlying node’s Security Group to only allow outbound traffic on specific ports to known endpoints, you provide a secondary layer of defense. Even if the container runtime is bypassed, the network interface at the infrastructure level will drop unauthorized packets.

By combining granular Kubernetes NetworkPolicies with restrictive cloud-level Security Groups, you ensure that even if a build agent is compromised, the blast radius is contained within a "sandbox" that cannot reach your crown jewels.

Key Takeaway: Never assume your build agents are trusted; enforce a default-deny network policy that treats every CI/CD runner as an untrusted client within your infrastructure.