The biggest security breaches in history have cost companies billions of dollars. Most recently, in 2022, a security breach at T-Mobile cost them $350M in customer payouts alone. Security issues are some of the most pressing concerns in today’s ever evolving software world.
While security can be implemented in many ways, some are better than others. Earlier this year, in February of 2023, someone gained access to Reddit’s internal network through getting one employee’s credentials. That could be prevented through a zero-trust security network.
In this article, we’re going to take a look at what zero-trust networks are. Then, we’ll learn how to get started setting up an example network in Docker, one of the most popular containerization services. We cover:
- What is a Zero Trust Network?
- The Architecture of an Embedded Zero Trust Network
- Implementing Your First Zero Trust Network via Docker
- The Controller for the Zero Trust Network
- Policies for the Edge Router(s)
- The Edge Router(s)
- Summary of Zero Trust Networks
What is a Zero Trust Network?
Zero Trust is a rather new term, so let’s take a look at what it really is. The security industry has evolved a lot over the past years and the term has been appropriated to mean many things. Currently, the NIST’s standard for zero trust is outlined in SP 800-207.
A zero trust network has three necessary components: a policy engine, a policy administrator, and an enforcement point. There are three types of zero-trust as according to Phillip Griffiths, VP of Biz Dev at NetFoundry, the maintainers of OpenZiti, an open source zero-trust network. The three types of zero trust that Phillip describes are “non-magical”, “partially magical”, and “magical” using Harry Potter references.
An example of non-magical zero trust would be a VPN or firewall. The equivalent of having a guard desk, kind of like Gringotts. An example of partially magical would be a software defined perimeter, or the equivalent of gating things off to muggles by making platform 9 ¾ hard to find.
Finally, an example of magical zero-trust would be an embedded network like OpenZiti. The equivalent of using portkeys. Another way I like to think about “magical” zero trust is like waiting in the doctor’s office. The doctor has to come get you; the network only lets in users through outbound requests.
How do these examples relate to the three components of a zero trust network? With a portkey, the policy engine is the object, the admin is the person casting the spell, and the enforcement point is where/when the key is used. With the doctor’s office, the engine is the people working in the office, the admin is the system through which you set up your appointment, and the enforcement point is the waiting room.
The Architecture of an Embedded Zero Trust Network
Let’s take a technical dive into the idea of an embedded or “magical” zero trust network using the idea of the doctor’s office. In this example, your application is the doctor’s office. Anyone who needs access to your application is a patient. When a patient needs access to the doctor, they come to the office and get checked in.
Once they are checked in, they sit in the waiting room, and wait for a nurse or doctor to come get them (the outbound request from the application). Then, they are led and given access to a specific room or set of rooms. Having a zero trust network works the same way in theory. An outbound request is sent from the network to the user and the user is only given access to a specific set of resources.
In a traditional network setup, we directly expose both inbound and outbound ports to the internet at large. You can see why this could be dangerous and how so many data breaches have happened. If someone can see your network and make inbound and outbound requests, then they have a vector of attack.
Traditional security models have used firewalls or VPNs to block off inbound requests through authentication. That’s just one layer of security though. As security models have progressed we’ve seen the rise of things like software-defined-perimeters, bastions, and more. The challenge with each of these is that they still allow inbound requests to connect.
OpenZiti’s zero trust network takes a new approach. There are no inbound requests at all. By moving the network into your application, you can hide it from the rest of the web. Your application can still make outbound requests, but it is no longer discoverable; it’s hidden in the shadows, removing many vectors of attack.
Implementing Your First Zero Trust Network via Docker
You can implement your own sample zero trust network with OpenZiti via Docker. This section will cover how to start up a sample zero trust network locally. You can get the Docker container for this section using the command docker pull openziti/quickstart:latest. An OpenZiti network needs a controller, an edge router, and edge router policies. We need at least three different terminals. One for the controller, and one for each edge router.
The first thing we do is start a Docker network using:
docker network create myFirstZitiNetwork.
Next, we create a folder to store the public key infrastructure (PKI): mkdir -p ~/docker-volume/myFirstZitiNetwork, and an empty file to put environment variables: echo "#ziti.env file" > ~/docker-volume/myFirstZitiNetwork/ziti.env. Now we’re ready to create and deploy the controller.
The Controller for the Zero Trust Network
In OpenZiti, the controller is the central component of the network. It provides the configuration plane for the network and allows connection of edge routers. If you followed the steps above and kept the folder for the PKI in your home directory, you can start a controller using the following code. This code starts a controller using port 1280. The controller terminal needs to run continuously (because we’re using -it which allows for interactivity).
docker run \
--network myFirstZitiNetwork \
--network-alias ziti-controller \
--network-alias ziti-edge-controller \
-p 1280:1280 \
-it \
--rm \
-v ~/docker-volume/myFirstZitiNetwork:/persistent/pki \
-v ~/docker-volume/myFirstZitiNetwork/ziti.env:/persistent/ziti.env \
openziti/quickstart \
/var/openziti/scripts/run-controller.shPolicies for the Edge Router(s)
Zero trust networks require user authentication and authorization. OpenZiti achieves this through policies for their edge routers. Using the same image from before, we can add edge router policies with the following command. Putting up the edge router policies should run and finish within the terminal.
docker run \
--network myFirstZitiNetwork \
--network-alias ziti-controller-init-container \
-it \
--rm \
-v ~/docker-volume/myFirstZitiNetwork:/persistent/pki \
-v ~/docker-volume/myFirstZitiNetwork/ziti.env:/persistent/ziti.env \
openziti/quickstart \
/var/openziti/scripts/run-with-ziti-cli.sh /var/openziti/scripts/access-control.shThe Edge Router(s)
The last thing we need to add to our network is an edge router. Edge routers are the basic building blocks of the OpenZiti zero trust network. Edge routers are used by the network to secure and deliver traffic from a node to its destination. You can start your own edge routers using code like the snippet below.
docker run \
-e ZITI_EDGE_ROUTER_RAWNAME=ziti-edge-router-1 \
-e ZITI_EDGE_ROUTER_ROLES=public \
--network myFirstZitiNetwork \
--network-alias ziti-edge-router-1 \
-p 3022:3022 \
-it \
--rm \
-v ~/docker-volume/myFirstZitiNetwork:/persistent/pki \
-v ~/docker-volume/myFirstZitiNetwork/ziti.env:/persistent/ziti.env \
openziti/quickstart \
/var/openziti/scripts/run-router.sh edgeYou can customize the name/alias of your routers through the first lines and the ports that it works on through the line containing -p. The one we just made is on port 3022.
Summary of Zero Trust Networks
Security breaches are becoming more and more dangerous as we upload more and more data to the web. Zero trust networks are a logical evolution of our cyber security systems. In this post, we learned about zero trust networks and created our own sample using an open source repo, OpenZiti.
Zero trust networks consist of three components: the policy engine, the policy admin, and the policy enforcer. The magic of zero trust networks comes from moving the network into your application and allowing only for outbound requests. In this way, we can have an application that is connected to the network, but undiscoverable, and thus less vulnerable to attack.
More by the Author
I run this site to help you and others like you find cool projects and practice software skills. If this is helpful for you and you enjoy your ad free site, please help fund this site by donating below! If you can’t donate right now, please think of us next time.
