Why Every DevOps Engineer Should Be Using Ziti

By Mike Gutherie, Head of DevOps for NetFoundry

Velocity vs security – why can we not have both?

After working in the DevOps space for almost a decade, there are a few common traits that you’ll find among most of us:

  1. We don’t actually know what we do for a living
  2. We love to automate EVERYTHING
  3. We wire systems together and make things work
  4. We don’t like administrating systems – we build systems to administrate other systems

Over the last decade we’ve seen an explosion in technology that allows us to automate and orchestrate on a level that’s never been seen before. We develop faster, deploy faster, we innovate. But in a world that has an ever-increasing need for security, we are also the troublemakers.

In order to wire systems together, we need access to EVERYTHING. Even more than that, we can grant incredible super powers to the automation systems that we build. We create systems that are absolute goldmines for hackers to exploit. Take any of the big technology names in the DevOps space, and imagine the devastation that an exploit can bring if one of these systems becomes compromised. Salt, Kubernetes, Jenkins, Ansible, your Data Warehouse. Something they all have in common – they all have incredible access grants within systems, and they all have access to a disturbing amount of data if it falls into the wrong hands.

Since removing access to these systems is not feasible, how do we continue to build tools that allow us to move at a breakneck speed without compromising our security and creating a massive attack vector? 

Enter Ziti! 

OpenZiti (I use Ziti and OpenZiti synonymously throughout this blog) is an open-source, software-only programmable network overlay based 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 allows me to continue to move quickly makes it into my repertoire and becomes a tool that I come back to over and over again, regardless of where I’m working. OpenZiti provides a way for you to set up access controls quickly and efficiently while raising the standard for “least permissions” at the network level. Read more about Ziti here or Ziggy, our mascot for OpenZiti and his many different outfits here.

Lock Down Your Tools

To make my life easier, I use the NetFoundry platform to provide a cloud orchestrated, programmable operation of OpenZiti – spun up and down minutes based on our needs. NetFoundry is the creator of Ziti, maintains it and can provide a SaaS option for anyone.

If you’re reading this, I probably don’t need to explain the terrifying compromises that happened in the last year with Solarwinds or TravisCI, but just in case you didn’t, you should go read those articles now and then you’ll understand perfectly why this next topic is critical. A CI/CD system is a perfect example of a “system managing a system”. It typically has elevated access and is designed to deploy and execute code in all of the places you care about. Hackers know this, they target these systems and dream about deploying and executing their own code inside of your systems. Knowing that hackers are looking for endpoints just like these would often keep me up at night. We can’t afford to leave our critical systems exposed anymore, we need to make them dark. The methodology for securing any of your sensitive resources is the same whether it’s a data warehouse, a build server, or an API. 

  • Shut down your traditional ingress ports
  • Place an Edge Router (cloud orchestrated software) inside of the private network space
  • Grant service access to only the endpoints that need it 

Seamless Switchover

When I think about “locking things down”, this is typically synonymous to all kinds of breakage and end-user disruption. When doing this sort of work in the past it’s very difficult to validate success short of waiting for users to complain. However, NetFoundry’s console paired with Ziti makes this incredibly easy.  I could see if the project was going to be successful *before* making the cutover. Ziti’s traffic intercept will work whether a service is dark or not. Enroll your end-users, watch the traffic come into the Console, and verify everything ahead of time. After running two migrations with this method, switchover day was a non-event both times because users had already been accessing the services with Ziti for weeks. 

Developer, DevOps and NetOps Access

If you’re putting on your security hat, this phrase alone should make you cringe. As nice as it would be to keep access locked down once you’re in production, sometimes things go wrong, and you need to let your developers log into instances, databases, and message brokers to solve a problem. Most companies don’t like to admit it, but too many are still using shared credentials to interact with their application dependencies, so when it comes to assigning developers secure access, this creates a security nightmare. These types of resources generally live inside of a private VPC or DC, so opening them up to a developer often means exposing the entire VPC to that user. In a “least permissions” world, this is not ideal. What Ziti allows me to do is isolate that network access and separate access by application, team, or environmenti.e. account-based access-control.

Step Up Your Visibility 

Have you ever had to determine who accessed a resource based on network traffic? Just in case you haven’t, it’s terrible. Traditional network traffic monitoring is built around IPs and Ports, and from that information you can maybe extract the “who” and the “what”. As a result, in a previous role, I once spent 3 days hunting down the fact one of our employees had gone to work from a coffee shop! NetFoundry introduces a whole new generation of network visibility, where all traffic monitoring operates around trusted identities (endpoints) and services (user-defined slices of traffic). For every byte of traffic that passes over OpenZiti, we know who initiated the traffic, what service is being accessed, and what time the traffic was passed. No additional interpretation is required.

Zero trust journey

To make our journey to zero trust DevOps as seamless and non-event as possible, we decided to go through an incremental, evolutionary series of steps. We started with our data warehouses before securing our Jenkins CI/CD pipeline. Next, we moved to ‘dark bastions’ by applying OpenZiti to them and closing inbound port 22 – auditing access became so much easier and less cumbersome. To come, we will make all internal system communications dark by applying NetFoundry to our ETL jobs and database to CI/CD connections.

I don’t know what journey you will take with OpenZiti and NetFoundry; that’s your next decision

More info

Most of us in the security, tech and networking worlds are cynics, and for good reason.  Meanwhile, the marketeers have flocked to use and abuse the Zero Trust terms.  So here are links to enable you to quickly filter through the noise and judge for yourself if you want to learn a bit more before diving into the SaaS or open source:

Discuss On: