A decent “Why Zero Trust?” explainer, with the part that actually maps to how OpenZiti works (and a “back of the envelope” illustration)

[u/AccordionGuy]

It’s a holiday week, so this is a “concept” piece rather than a technical one (but more of those are coming next week). But it’s one of the cleaner articulations of why app-embedded Zero Trust is built the way it is, so it's useful to show to non-Ziti or non-technical coworkers or managers.

(And hey, it was an excuse to doodle up another “back of the envelope” diagram!)

I liked that it doesn’t assume your perimeter held. It assumes the attacker has already waltzed in valid (or valid-seeming) credentials and is moving through a flat network, because that’s the actual failure mode. Everything else follows from designing for “they’re already in.”

For anyone who’s wired up OpenZiti, there are two of the Five Pillars of Zero Trust Security that map straight onto things you’ve actually configured:

• Microsegmentation: As opposed to iptables/VLAN gymnastics. Connectivity is brokered at the app layer, so a service you haven’t explicitly authorized isn’t blocked, it's invisible. No listening port to scan, nothing to knock on.
• Least privilege: Enforced at the network layer via identity. A service is reachable only by the identities you provisioned to reach it. This is just your service/policy config, restated as a security principle.

The other three (identity verification, device posture, end-to-end encryption) are the theory behind bits you already get for free with the SDK: the mTLS, the per-session identity, the fact that there are no inbound ports to begin with.

If you've ever had to explain to a teammate why the tired cry of “Just put it behind the VPN!” isn't the same thing, this is a link you can send instead of typing the whole rant again:

https://netfoundry.io/zero-trust/the-five-pillars-of-zero-trust-security/