Why Every DevOps Engineer Should Be Using Zero Trust Security
At A Glance
- CI/CD tools like Jenkins, Kubernetes, and data warehouses need broad access to do their job — which makes them prime targets when compromised
- Zero Trust replaces open inbound ports with identity-based, outbound-only connections, so these tools are invisible to attackers by default
- OpenZiti (and NetFoundry’s managed version of it) lets DevOps teams lock this down incrementally, without a disruptive “flag day” cutover
- Real-world payoff: least-privilege developer access, full traffic attribution by identity, and a security posture that doesn’t fight your deployment velocity
Velocity vs security – why can we not have both?
After almost a decade in DevOps, I can confidently say most of us share a few key traits:
- We don’t actually know what we do for a living
- We love to automate everything
- We wire systems together and make things work
- We don’t like administrating systems; we like building systems to administrate other systems
Over the past few years, we’ve seen an explosion in tooling that lets us automate and orchestrate at a level that’s never existed before. We develop faster, we deploy faster, we innovate faster. But in a world with an ever-increasing need for security, we’re also the troublemakers. This is about how Zero Trust for DevOps — specifically OpenZiti — let us keep that speed without leaving every pipeline wide open to attack.
Why DevOps Pipelines Are a Hacker’s Dream
To wire systems together, we need access to everything. More than that, we grant genuine superpowers to the automation systems we build…and they’re goldmines for attackers. Take any major name in the DevOps space and imagine the damage if it’s compromised: Salt, Kubernetes, Jenkins, Ansible, your data warehouse. They all share the same weakness: broad access grants, and a disturbing amount of data if any of it falls into the wrong hands.
This isn’t hypothetical. In March 2025, attackers compromised a popular GitHub Action, tj-actions/changed-files, used in over 23,000 repositories — dumping CI/CD secrets like AWS keys, GitHub tokens, and private RSA keys straight into build logs (CVE-2025-30066, CVSS 8.6). More recently, researchers disclosed a workflow-automation flaw nicknamed “Cordyceps” affecting projects tied to Microsoft, Google, Apache, and others. It’s a sobering reminder that this isn’t a solved problem; it’s an ongoing category of risk.
Since removing access to these systems entirely isn’t feasible, the real question is: how do we keep moving at breakneck speed without turning our own tooling into the attack surface?
OpenZiti: A Zero Trust Overlay Built for DevOps Speed
Enter OpenZiti (note: I use “Ziti” and “OpenZiti” interchangeably throughout — most practitioners do). It’s an open-source, software-only network overlay built on Zero Trust principles.
As a DevOps engineer, I like tools that act like a Swiss Army knife: anything that solves a variety of problems and lets me keep moving becomes something I reach for again and again. OpenZiti lets you set up access controls quickly while raising the bar on least privilege at the network level. Read more about Ziti on GitHub, or meet our mascot Ziggy and his many outfits.
How to Lock Down DevOps Tools with Zero Trust Access
To make my own life easier, I use the NetFoundry platform for cloud-orchestrated, programmable operation of OpenZiti — spun up and down in minutes based on what we need. NetFoundry built and maintains Ziti, and offers a SaaS option for anyone who wants it without the operational overhead.
A CI/CD system is the textbook example of a “system managing a system.” It typically runs with elevated access and is designed to deploy and execute code everywhere that matters to you. Unfortunately, attackers know this. They target these systems specifically, hoping to get their own code running inside yours. Knowing that hackers are hunting for endpoints exactly like these used to keep me up at night. We can’t afford to leave critical systems exposed anymore — we need to make them dark.
The approach is the same, whether you’re securing a data warehouse, a build server, or an API:
- Shut down your traditional ingress ports
- Place an Edge Router (cloud-orchestrated software) inside the private network space
- Grant service access only to the endpoints that actually need it
That’s it — no ports open to the internet, no bastion host to maintain, no firewall rule sprawl to audit later.
Zero Trust Migration: How We Made Switchover a Non-Event
“Locking things down” usually means breakage and end-user disruption. In the past, validating success meant waiting for users to complain — not exactly a confidence-inspiring QA process. NetFoundry’s console paired with Ziti makes this dramatically easier: I can see whether a migration will succeed before making the cutover.
Ziti’s traffic intercept works, whether a service is dark or not yet. So you enroll your end-users, watch traffic arrive in the console, and verify everything ahead of time. After running two migrations this way, switchover day was a non-event both times; users had already been accessing services through Ziti for weeks before we officially flipped the switch.
Zero Trust Developer Access: Least Privilege Without the VPN Headache
If you’re wearing your security hat, this next part may make you wince.
Ideally, access stays locked down once you’re in production. But sometimes, things break, and developers need to get into instances, databases, or message brokers to fix it. Most companies won’t admit it, but a lot of them are still handing out shared credentials to interact with application dependencies, which turns “assign developers secure access” into a genuine security nightmare.
These resources usually live inside a private VPC or data center, so opening them to a developer often means exposing the entire VPC to that one person. In a least-privilege world, that’s not okay. What Ziti lets me you instead is isolate that access and scope it by application, team, or environment. It’s true account-based access control, not “here’s the keys to the whole building.”
Zero Trust Network Visibility: Know Who Touched What, When
Ever had to figure out who accessed a resource based on raw network traffic? If you haven’t, count yourself lucky — it’s miserable. Traditional traffic monitoring is built around IPs and ports, and from that you can maybe piece together the “who” and the “what.” In a previous role, I once burned three days hunting down the fact that an employee had simply gone to work from a coffee shop.
NetFoundry introduces a different kind of visibility; one built around trusted identities and services instead of IPs and ports. For every byte of traffic that crosses OpenZiti, we know who initiated it, what service was accessed, and when. No forensic reconstruction required.
Our Zero Trust DevOps Journey: A Real-World Rollout Timeline
To keep our own journey to Zero Trust DevOps seamless, we went incremental instead of “big bang.” We started with our data warehouses, then secured our Jenkins CI/CD pipeline. From there, we moved to “dark bastions” — applying OpenZiti and closing inbound port 22 — which made access audits dramatically less painful. Next up: making all internal system communication dark, from ETL jobs to database-to-CI/CD connections.
I don’t know what journey you’ll take with OpenZiti and NetFoundry. That part’s up to you.
Getting Started with Zero Trust for DevOps
Most of us in security, tech, and networking are cynics for good reason, especially once marketers got hold of the term “Zero Trust” and started using it to describe anything with a login screen. So judge for yourself: see how Platform9 used Ziti to secure programmable Kubernetes network overlays, or dig into our Zero Trust DevOps solution overview for the technical detail on how this applies to Jenkins, Kubernetes, GitLab, and the rest of your toolchain.
NetFoundry built and maintains OpenZiti, the open-source Zero Trust platform this entire approach runs on. When we talk about securing CI/CD pipelines, data warehouses, and developer access, it’s the same architecture we run our own DevOps org on, not just a product pitch. If you want to see what this looks like against your Jenkins setup, Kubernetes cluster, or specific access mess, schedule a working session with our DevOps team and we’ll walk through it together. Prefer to try it yourself first? OpenZiti is open source, and NetFoundry’s SaaS is free for 30 days.
FAQ
Zero Trust for DevOps means replacing implicit network trust — like open inbound ports or shared VPN access — with identity-based, outbound-only connections for every tool in the pipeline. At NetFoundry, we build this on OpenZiti, so CI/CD systems, Kubernetes clusters, and data warehouses stay invisible to unauthorized traffic by default, even though they still need broad access to do their jobs internally.
OpenZiti closes traditional ingress ports and places a software-based Edge Router inside the private network, granting access only to the specific endpoints that need it. We use this exact approach internally — it’s how we secured our own Jenkins pipeline and data warehouses without redesigning our network.
Not when it’s done incrementally. A Zero Trust rollout doesn’t require a disruptive cutover — traffic intercept can run in parallel with existing access while you validate the migration. We’ve run two internal migrations this way, and switchover day was a non-event both times because users were already accessing services through Ziti for weeks beforehand.
A VPN typically grants broad network-level access once a user or system authenticates, which often means exposing an entire VPC to reach one resource. Zero Trust scopes access down to individual services and identities instead. We use this distinction internally to isolate developer access by application, team, or environment — not by handing out access to the whole network.
The method is consistent regardless of the tool: shut down inbound ports, place an identity-aware Edge Router inside the private network, and grant service-level access only to what’s needed. We’ve applied this to our own Jenkins pipeline, Kubernetes clusters, and internal data infrastructure at NetFoundry.
