If you have read through the entire series up to here, welcome! If you have not, please consider reading the whole series:

• Part 1: Encryption Everywhere
• Part 2: A Primer On Public-Key Cryptography
• Part 3: Certificates
• Part 4: Certificate Authorities & Chains Of Trust
• Part 5: Bootstrapping Trust

It isn't easy to talk about bootstrapping trust without covering the basics of public-key cryptography. The reader may skip this article if the concepts of encryption, signing, and public/private keys are familiar. However, if not, I implore that you bear the brunt of this article as later parts will heavily rely on it.

Whether you are an encryption expert or a newcomer, welcome! This series is for you! It assumes you know nothing and takes you from soup to nuts on how to bootstrap trust with the intent to power a Zero Trust security model. The process and thinking described in this series are the direct output of developing the same system for the Ziti open source project. Ziti can be found on the GitHub project page for OpenZiti. The series starts with the basics and dovetails into Ziti's Enrollment system.

The parts are as follows.

• Part 1: Encryption Everywhere
• Part 2: A Primer On Public-Key Cryptography
• Part 3: Certificates
• Part 4: Certificate Authorities & Chains Of Trust
• Part 5: Bootstrapping Trust

This is part two of a three-part article. This article provides the technical deep dive into the steps necessary to implement the vision outlined in part one. This article will be heavy on OpenZiti CLI commands, explaining what we are doing to configure the overlay network, and why. In the final article, we will explore what we have just created and understand what was just created

Goals​

• Incredibly easy to deploy Prometheus servers

• No ports exposed to the internet

• Prometheus servers can be deployed listening on the overlay, not on the underlay

• Private Kubernetes API

This is part one of a three-part article. This article provides the necessary background and rationale for the series. The next article will be a detailed explanation of the actual steps necessary to implement the solution. In the final article, we will explore what we have just created and understand what was just created

This is part three of a three-part article. This article builds on the previous two articles. Here we will take a look at what we built and use it to explore the power of a zitified Prometheus. See part one for the necessary background about the series. See part two for detailed instructions covering how to setup the environment you're about to explore

The previous post showed how to use a zero trust overlay like Ziti for transferring files by zitifying scp. Next up in the list of zitifications is kubectl. Kubernetes is a container orchestration system. Its purpose is to deploy, scale, and manage the deployment containers. Containers are self-contained, pre-built images of software generally with a singular purpose. Developers often like using containers for various reasons. One major reason developers like containers is because it simplifies the deployment of the solutions they are developing. This is where Kubernetes starts to come into focus.

In the previous post we talked about how we could take a well-known application and improve its security by zitifying it, producing zssh. The logical next step after zitifying ssh would be to extend the functionality of zssh to cover moving files securely as well, enter zscp. A zitified scp effectively creates a more secure command line tool for sending and receiving files between ziti-empowered devices. Once zitified, we can use zscp using ziti identity names just like we did in zitifying ssh. I recommend reading the previous article if you haven't to learn more about the benefits of zitifying tools like ssh and scp.

As we learned in the opening post, "zitifying" an application means to embed a Ziti SDK into an application and leverage the power of a Ziti Network to provide secure, truly zero-trust access to your application no matter where in the world that application goes. In this post, we will see how we have zitified ssh and why. Future posts will expand on this even further by showing how NetFoundry uses zssh to support our customers.

"Zitification" or "zitifying" is the act of taking an application and incorporating a Ziti SDK into that application. Once an
application has a Ziti SDK incorporated into it, that application can now access network resources securely from anywhere in
the world provided that the computer has internet access: NO VPN NEEDED, NO ADDITIONAL SOFTWARE NEEDED.

Mobile Point of Sale (mPOS) app – embed zero trust networking​

Written with Sagarkumar S of Enlume Technologies

Point of sale application developers and solution providers need to provide secure, reliable applications to retailers.  However, retailers need to create duplicate networks with extra hardware and configuration to separate their point of sale (POS) data for PCI compliance.  Now, there is a better way.  Use the simple Ziti SDKs to embed zero trust networking, inside the POS app, so that the POS app is secure on any network - micro-segmented and zero trust.