Zero trust network access for DevOps should protect the deployment workflow as well as the applications it deploys. The practical model is to give each developer, runner, cluster, and deployment service a verifiable identity, then authorize access to a specific service for a limited purpose. That removes the need to put private build systems on the public internet or place every runner on a broad VPN.
The distinction matters because CI/CD systems are not just pipelines. They are automated actors with access to source code, artifact stores, cloud accounts, clusters, databases, and production APIs. A stolen runner token or over-permissioned service account can turn one compromised job into a path across the environment.
Why VPN access is a poor fit for CI/CD
VPNs connect networks or place users inside a network zone; CI/CD security needs to connect an identified workload to an identified service. NIST SP 800-207 defines zero trust around resources, users, and assets rather than physical or network location, and it calls for authentication and authorization before a session is established.
A traditional developer VPN often creates four problems:
- A runner receives network reachability that is wider than the job requires.
- IP-based rules become brittle as runners scale, move between clouds, or use ephemeral addresses.
- A developer laptop and an automated production deployer can look like the same network principal.
- The network path says little about which repository, workflow, branch, or environment initiated a request.
That model is especially risky for hosted runners. A job should reach the artifact registry, deployment API, or private Kubernetes endpoint it needs. It should not inherit a route to every service available from the build network.
What zero trust network access means for DevOps
For DevOps, zero trust network access means policy-controlled service reachability for people and non-human identities. The control plane evaluates identity and context before it creates the connection, while the data plane carries only the traffic that policy permits.
The identity set is broader than an employee directory:
- Developers need access to development services and controlled production diagnostics.
- CI runners need an identity tied to a repository, workflow, and environment.
- Deployment controllers need narrowly scoped access to cluster or platform APIs.
- Build services need access to source, dependencies, artifact stores, and signing systems.
- Agents and automation need a non-human identity that can be audited separately from its operator.
This is where NHI, or Non-Human Identity, becomes an operational requirement. A service account with a static secret is not a sufficient identity model for a production deployment. The policy should express who or what is connecting, which service it may reach, and under which conditions.
A reference architecture for secure developer connectivity
The strongest design separates identity, reachability, and authorization instead of asking a firewall to perform all three jobs.
1. Establish workload identity
Start with an identity that the platform can verify cryptographically. For GitHub Actions, OpenID Connect lets a workflow exchange a short-lived token directly with a supported cloud provider. GitHub documents that the token is generated for a workflow job and that the cloud provider checks claims such as the repository and workflow before issuing temporary access.
Use claims that distinguish the deployment context. A production role should trust the production environment and approved repository, not every branch in the organization. Where the platform supports it, include repository properties such as business unit or environment tier in the trust decision.
The same principle applies outside GitHub Actions. Kubernetes service accounts, cloud workload identities, SPIFFE SVIDs, and platform-issued certificates can all provide machine identity. The important point is that a runner proves what it is instead of presenting a shared password.
2. Make private services unreachable by default
A private Kubernetes API, database, or deployment endpoint should not need a public listener just because a pipeline runs outside its network. Place an outbound-only connector or identity-aware overlay component near the private service. The connector establishes the permitted path, and the service remains undiscoverable to unauthenticated traffic.
This is different from hiding a port behind a reverse proxy. The gateway still needs to enforce the identity and the service policy before the connection is useful. A reverse proxy can reduce exposure, but it does not automatically answer whether this repository’s release workflow should reach this production service.
NetFoundry describes this pattern as Identity-First Reachability™: authenticate-before-connect access to applications and workloads. The model applies to Kubernetes ingress and egress, CI/CD workflows, and service communication without requiring public exposure or VPC peering.
3. Authorize the smallest useful service set
Write policies around services, not subnets. A release workflow might need to reach a private container registry, a signing service, and a Kubernetes API. It probably does not need a route to the database behind the application.
A useful policy record includes:
| Policy field | Example decision |
|---|---|
| Identity | repo:payments/api, production deploy workflow |
| Source context | Protected branch and approved environment |
| Destination | k8s-api.prod.internal |
| Action | Deploy a signed image, read deployment status |
| Time boundary | One workflow run or short-lived session |
| Evidence | Workflow run ID, commit SHA, approver, decision |
The policy should fail closed. If a runner loses its identity, the path should disappear rather than remain open until an administrator changes a firewall rule.
How to secure a CI/CD pipeline without a VPN
Use this sequence for a new pipeline or a controlled migration.
Step 1: Map every automated connection
List the services a build and deployment job actually calls. Include source control, package registries, artifact repositories, signing systems, cloud APIs, Kubernetes endpoints, secret managers, observability systems, and rollback targets.
Do not start with IP ranges. Start with service names and job actions. This exposes unnecessary dependencies before they become network policy.
Step 2: Separate build, test, and deploy identities
A build job should not automatically receive production deployment rights. Give each stage a distinct identity and role. Make promotion a new authorization event rather than a side effect of the build succeeding.
GitHub recommends using short-lived credentials through OIDC instead of storing long-lived cloud credentials as repository secrets. It also recommends limiting workflow token permissions and reviewing third-party actions. Those controls address credential abuse inside the job. Identity-based reachability adds the network boundary around the same job.
Step 3: Protect the runner and the workflow supply chain
Treat the runner as a workload that can be compromised. Prefer ephemeral, isolated runners for sensitive deployments. Pin third-party actions to full-length commit SHAs, keep the workflow token at the minimum permission level, and avoid passing untrusted pull request content into shell scripts.
GitHub’s security hardening guidance warns that a compromised third-party action can access workflow secrets and the GITHUB_TOKEN. Network policy cannot repair unsafe code execution, but it can limit what that compromised job can reach.
Step 4: Put private endpoints behind policy
Move the deployment path to private service reachability. The runner authenticates, the policy engine evaluates its claims, and only the approved service connection is created. The private endpoint does not need an inbound internet route.
For Kubernetes, apply policy at the cluster service boundary and keep administrative access separate from application deployment access. For cloud APIs, prefer resource-scoped roles and conditions tied to the workload identity. For artifact systems, allow publish and read actions separately.
Step 5: Log the decision, not just the packet
A useful audit record answers five questions: which identity connected, which workflow created it, which service was requested, which policy allowed or denied it, and what changed afterward. Correlate the network decision with the commit SHA, workflow run, deployment ID, and cloud audit event.
This gives security teams a usable trail without forcing them to reconstruct an event from firewall logs and runner IP addresses. It also makes access reviews concrete: remove a repository or environment from a policy instead of hunting for stale address rules.
Where microsegmentation fits
Microsegmentation is the enforcement layer that keeps one permitted connection from becoming broad east-west access. It should follow the service identity model, not recreate a collection of tiny network zones that engineers must maintain by hand.
For a deployment platform, segment at least these paths:
- Build to artifact repository
- Deploy workflow to cluster control plane
- Cluster controller to required application services
- Observability agent to telemetry endpoints
- Developer workstation to approved diagnostics
The resulting model is narrower than a VPN and easier to reason about than a flat allowlist. For the broader workload implementation model, see How to Implement Zero Trust for Cloud Workloads. It also supports gradual rollout. Start in monitor-only mode, compare observed calls with intended policy, then enforce the smallest stable set.
Teams working with AI-enabled deployment tools should apply the same boundary to agents. The same workload identity and microsegmentation principles apply, but the DevOps rule stays simple: an agent gets access to a named service for a named task, not a network because it happens to run in a trusted environment.
Common implementation mistakes
The most common failure is replacing a VPN with a proxy while preserving broad trust. The address changes, but the authorization model does not.
Avoid these shortcuts:
- Trusting a runner because it has a corporate IP address
- Reusing one service account for build, release, and production operations
- Allowing a workflow to reach an entire VPC when it needs one API
- Treating a successful authentication as permission for every tool or endpoint
- Logging only source IP and destination port
- Leaving a temporary migration rule in place after the new policy works
The second failure is making the security team review every deployment as a manual exception. Good policy should encode stable facts such as repository, environment, branch protection, workload identity, and service role. Human approval still belongs at sensitive promotion boundaries, but it should not replace machine-verifiable authorization.
FAQ
What is zero trust network access in DevOps?
Zero trust network access in DevOps gives each developer and automated workload identity-based access to specific services. It verifies identity and authorization before creating the connection, instead of placing the actor on a broadly trusted network.
Can CI/CD pipelines work without a VPN?
Yes. A runner can use a short-lived workload identity and an outbound-only, policy-controlled path to reach private registries, Kubernetes APIs, and deployment services. The private service stays off the public internet and the runner receives no general network route. The same principle applies to private AI services, as explained in Do LLM Deployments Need a Zero Trust Tunnel?.
How does OIDC improve CI/CD security?
OIDC lets a workflow exchange a short-lived identity token with a supported cloud provider instead of storing a long-lived cloud credential in the repository. The provider can evaluate claims about the repository, workflow, branch, or environment before issuing temporary access.
What is the difference between ZTNA and a developer VPN?
A developer VPN typically grants network access based on membership in a tunnel or network zone. ZTNA grants access to an application or service after evaluating identity and policy, so a developer or runner can reach one approved resource without seeing the rest of the network.
How should teams secure self-hosted CI runners?
Treat self-hosted runners as privileged workloads. Isolate them, limit their network reachability, keep secrets out of the runner where possible, use short-lived credentials, and avoid running untrusted code on a machine that can reach production systems.
Does microsegmentation replace CI/CD identity?
No. Microsegmentation limits which paths are reachable, while workload identity tells the policy engine which actor is requesting the path. Secure CI/CD needs both controls, plus authorization tied to the deployment action.
Sources & References
- NIST SP 800-207: Zero Trust Architecture – zero trust principles and resource-based access
- GitHub Actions OpenID Connect – short-lived workflow identity
- GitHub Actions security hardening – runner and workflow controls
- NIST SP 800-207: Zero Trust Architecture – authentication before resource sessions
