OpenZiti: Deep Dive

OpenZiti’s architecture is built from modular components that together enable a programmable, zero trust overlay. Here are the key pieces and how they work in practice:

• Ziti Controller:
  Orchestrates the overlay network, managing identities, policies, and the overall network state.
  Example: When you register a new application or user, the Controller provisions a cryptographic identity and applies access policies to govern which services they can reach.
• Ziti Edge Router:
  Acts as a secure on-ramp/off-ramp bridging identities and services into the overlay. Routes encrypted traffic within the overlay network.
  Example: Deploy an Edge Router in your data center to securely connect legacy on-prem applications to cloud-native services.
• Ziti SDKs & Tunnellers:
  Client libraries and tunnellers (like ziti-tunnel or app SDKs for Go, NodeJS, C, etc.) embed overlay networking directly into applications or operating systems.
  Example: Use the Go SDK to add secure, policy-driven communications to a custom microservice without VPNs or firewall changes.
• Identities & Enrollment:
  Each user, device, service, or application is assigned a unique identity, established by cryptographically secure enrollment.
  Example: A developer enrolls a CI/CD pipeline agent, giving it a Ziti identity so it can pull build artifacts from protected infrastructure.
• Services:
  The protected applications or endpoints made accessible through the overlay based on identity and policy.
  Example: A database server is defined as a Service; only specific applications with matching Ziti identities and policies can connect—no exposed ports.
• Policies:
  Granular rules that map which identities can access which services, and under what conditions.
  Example: A policy grants the “HR” app access to payroll services but denies access to developer infrastructure.
• Management APIs & CLIs:
  REST APIs and command-line tools to automate onboarding, policy creation, and operational tasks.
  Example: Use ziti edge create identity in a GitHub Actions script to create and enroll a new cloud VM on deployment.

While OpenZiti is a leader in programmable zero trust overlays, several other platforms address similar challenges of secure application connectivity and zero trust networking. Here’s a comparison of OpenZiti with its primary competitors and what sets it apart:

• Tailscale
  A mesh VPN platform based on WireGuard, Tailscale enables simple peer-to-peer encrypted networking.
  Difference: Unlike OpenZiti, Tailscale primarily focuses on network-level mesh connectivity (VPN) and does not provide programmable SDKs for embedding secure overlay logic directly into applications or enabling identity-specific access policies at the application layer.
• ZeroTier
  An easy-to-setup mesh network solution that virtualizes global LANs and private networks.
  Difference: ZeroTier emphasizes virtual LAN connectivity and network overlays, whereas OpenZiti offers full app-layer programmability, zero open ports, and fine-grained, policy-based identity access control through SDKs and APIs.
• OpenVPN
  A popular open standard for SSL/TLS-based tunneling, commonly used for remote access and network bridging.
  Difference: OpenVPN focuses on VPN tunnels and user-based authentication but does not provide dynamic app- and service-level identities, policy-based routing, or the ability to directly embed secure logic via SDKs.
• Cloudflare Zero Trust (Access/Tunnels)
  Cloud-based Zero Trust solutions for securing SaaS and on-prem applications through access proxies, tunnels, and SSO integration.
  Difference: Cloudflare solutions are SaaS-centric and proxy-oriented. OpenZiti is open source, self-hostable, and centered on “dark”, zero trust overlays with deeply programmable SDKs and CLI for both policy and fabric automation.
• NetFoundry (Commercial)
  The commercial counterpart and managed service of OpenZiti, offering advanced orchestration and support.
  Difference: OpenZiti is entirely open source, developer-first, and community-supported. The commercial offering adds hosted features, management, and SLAs but shares core technology.
• OpenZiti’s Unique Differentiators
  • Fully Open Source with Extensive SDK Support (Go, NodeJS, .NET, Java, C) for direct app integration.
  • Policy-driven, cryptographic identity mapping at the application and service level (not just network or user).
  • Zero open ports: Applications remain entirely dark and inaccessible except via the overlay.
  • Fine-grained programmable automation via CLI and REST APIs, enabling integration into CI/CD and DevOps workflows.
  • Self-hosted as well as commercial managed options (with self-sovereignty over all security infrastructure).
  • Designed for edge, cloud, IoT, smart devices, and classic IT—supporting both legacy and modern workloads securely.

OpenZiti enables a wide range of secure networking scenarios by leveraging its zero trust overlay architecture. Here are some of the most impactful use cases, each paired with a practical example:

• Securing Web Applications:
  Protect web apps by making them invisible (“dark”) to the public internet. Only authorized users and devices can access these applications through the OpenZiti overlay, eliminating exposed ports and reducing attack surface.
  Example: An internal company portal is only reachable via OpenZiti—employees authenticate using their Ziti identity, but outsiders cannot even see the app exists.
• Remote Access to Internal Resources:
  Enable employees, partners, or IT staff to access internal systems (databases, file servers, management consoles) from anywhere, without VPNs or open firewall ports. All access is authenticated and encrypted.
  Example: IT staff use Ziti Desktop Edge to connect to an on-prem SQL database from home, requiring no VPN or port forwarding.
• Multi-Cloud and Hybrid Deployments:
  Seamlessly connect applications and services across clouds or between on-premises and cloud environments. OpenZiti ensures secure, consistent connectivity regardless of infrastructure.
  Example: An e-commerce site’s microservices run in AWS and Azure—OpenZiti forms an encrypted overlay, so services communicate as if on a single secure network.
• IoT Device Security:
  Securely connect and manage IoT devices even in remote or untrusted networks. Each device receives a unique identity; communication is always encrypted and policy-controlled.
  Example: Factory sensors in a remote location use the Ziti tunneller to securely report data back to HQ, with all traffic restricted by identity and policy.
• DevOps and Automation:
  Allow automated tools (CI/CD pipelines, monitoring agents) to interact with protected resources without exposing management interfaces.
  Example: A GitHub Actions pipeline uses the ziti edge enroll CLI within the runner to access an artifact repository available only inside the OpenZiti network.
• Secure Application-to-Application Communication:
  Embed OpenZiti SDKs into apps to create secure, authenticated channels for service-to-service communication—ideal for microservices.
  Example: A Go-based payment service and a Node.js order service use OpenZiti SDKs; all traffic is encrypted and access is policy-governed.
• Self-Hosting and Home Networks:
  Make self-hosted services (home labs, media servers, personal websites) accessible from anywhere—without opening ports on your home router.
  Example: A Raspberry Pi Plex server uses Ziti Edge Tunnel; family members connect securely from outside, but there are no public IPs or open ports at home.
• Third-Party and Vendor Access:
  Grant temporary, controlled access to vendors or contractors, limiting them to only the services they require, with full audit and instant revocation.
  Example: A vendor is issued a time-limited OpenZiti identity, letting them securely reach a support portal for two days—then access auto-revokes.
• SSH and Remote Management:
  Use tools like zssh and zscp to securely manage servers, removing any need to expose SSH ports or rely on jump hosts.
  Example: A DevOps engineer uses zssh to reach production servers from anywhere, with their SSH access governed entirely by Ziti policies and identity.

OpenZiti extends zero trust overlays to mobile platforms and edge devices, enabling secure, app- and service-level connectivity regardless of location or network.

• Mobile Edge Applications:
  OpenZiti Mobile Edge apps (for Android and iOS) act as tunnelers and DNS providers, enforcing overlay-based policy and identity everywhere[9][19].
  • Example: An Android device runs the Ziti Mobile Edge app; all assigned apps/services are reachable via the secure overlay—no VPN needed.
  • Example: iOS Ziti Mobile Edge intercepts DNS queries and securely maps network requests to authorized overlay services based on dynamic device policy.
• Edge Gateway Integration:
  Deploy OpenZiti tunnelers or SDKs on IoT gateways or industrial controllers to allow secure upstream/downstream access, with endpoint-level policy enforcement.
  • Example: A Raspberry Pi at a remote site runs a Ziti tunneler, authenticates with PKI, and allows only whitelisted monitoring agents to access the local sensor network.
• Automatic Policy & Service Sync:
  Mobile and edge endpoints automatically sync policy and authorized services from the controller, supporting secure BYOD, remote troubleshooting, and rapid scaling.

OpenZiti allows organizations to leverage their existing Public Key Infrastructure (PKI) by integrating external Certificate Authorities (CAs) for enrollment and authentication. This provides flexibility for enterprises with established security standards and custom certificate issuance workflows.

• Import and Register External CAs:
  Upload your CA’s public certificate to the OpenZiti controller using the UI or REST API.
  Example: In the controller UI, add a new Certificate Authority, set isAutoCaEnrollmentEnabled to true for automatic enrollment, and upload your CA cert in PEM format[1][4].
• Automatic and One-Time Token (OTT) Enrollment:
  Devices or users present client certificates issued by your organization’s PKI to the controller for auto-enrollment, or use an OTT process mapping external CAs to identities.
  Example: After importing your internal CA, clients enrolled by your PKI can be authorized for network access without pre-generated JWT tokens; new identities are created on-demand with mapped role attributes[2][5].
• Separation of Private Key Custody:
  Private key generation and certificate management stay fully within your PKI—no sensitive keys are ever exported or managed by OpenZiti.
• Identity Files Reference Custom Cert Chains:
  Device configs reference files for the certificate, private key, and CA chain, ensuring correct trust relationships without controller-side signing.
  Example: An application specifies:

  {
    "ztAPI": "https://ziti-controller.example.com:8441",
    "id": {
      "key": "path/to/device.key",
      "cert": "path/to/device.crt",
      "ca": "path/to/ca-bundle.crt"
    }
  }
      

OpenZiti posture checks enforce access rules based on the current state and context of endpoints—enabling conditional, risk-based access decisions that go beyond simple identity.

• Types of Posture Checks:
  Checks can ensure presence of MFA (TOTP), operating system/version, running processes, or custom device attributes before access is allowed[7][12].
  • Example: Require users to submit a TOTP code every hour or upon device unlock:
    ziti edge create posture-check mfa MyMFA --timeoutSeconds 3600 --promptOnWake --promptOnUnlock
  • Example: Restrict a service to MacOS only:
    ziti edge create posture-check os MacOSOnlyCheck --os "macOS"
• Policy Integration:
  Link posture checks to service policies to enforce conditional access.
  • Example: Only users on MacOS can access a binding service:
    ziti edge create service-policy MacBindPolicy Bind --posture-check-roles "@MacOSOnlyCheck"
• Wide-Ranging Support:
  Posture checks apply to both dial (client) and bind (service) policies—giving administrators full control over both user access and service hosting compliance[17].

OpenZiti fits seamlessly into automated testing frameworks and CI/CD pipelines, allowing ephemeral, policy-driven zero trust overlays to be created, tested, and torn down as part of automated workflows.

• Dynamic Overlay Initialization:
  Start controller and routers as part of test containers or jobs, isolated per test run. Perfect for integration and security testing scenarios.
  • Example: Use Docker Compose/GitHub Actions to launch a Ziti network before running end-to-end tests in parallel pipelines[18].
• On-the-Fly Identity and Policy Management:
  Generate identities, enroll endpoints, and update access policies on demand through CLI or REST during pipeline execution.
  • Example: ziti edge create identity user test-runner -o test-runner.jwt and enrolling with ziti edge enroll test-runner.jwt as the first step in functional tests.
• Test Automation & Verification:
  Automated test scripts can validate end-to-end encryption, service reachability, or posture enforcement, ensuring security controls in real deployment environments.
  • Example: Run integration jobs that require overlay-protected API access, perform TOTP authentication as part of security test harness.
  • Example: Leverage tools like Selenium, JUnit, GitHub Actions, or GitLab CI to automate both Ziti network setup and teardown within the job lifecycle[8][13].

Explore the hands-on tools and developer integrations that make it possible to manage, automate, and embed OpenZiti’s secure networking capabilities. Here’s a step-by-step look at the CLI and SDKs, with real-world usage examples:

• OpenZiti CLI Overview:
  The OpenZiti CLI (ziti) is the primary administration tool for your network, providing automation for setup, management, and ongoing operations.
  • Network Initialization:
    Use commands such as ziti controller run or ziti edge router run to launch controllers and edge routers.
    Example: ziti edge router create edge-router1 --jwt edge-router1.jwt initializes and enrolls a new edge router.
  • Identity Management:
    Easily provision or manage cryptographic identities for endpoints.
    Example: ziti edge create identity user alice -o alice.jwt generates an enrollment token for the new user "alice", and ziti edge enroll alice.jwt enrolls the identity.
  • Service & Policy Configuration:
    Define resources, map access, and enforce rules entirely from the CLI.
    Example:
    • ziti edge create service internal-api --endpoint-address 127.0.0.1:8080
    • ziti edge create service-policy allow-internal-api Dial --identity-roles "#engineering" --service-roles "#internal-api"
  • Monitoring & Diagnostics:
    Check network health and troubleshoot issues using built-in commands.
    Example: ziti edge list identities to display all registered network identities or ziti edge list sessions to view active sessions.
• SDK Integration:
  OpenZiti offers SDKs for various languages—NodeJS, Go, C, Java, .NET—so developers can embed secure networking directly in their applications.
  • Language Support:
    Choose an SDK for your stack, available for NodeJS, Go, C, Java, and .NET.
    Example: Use the Go SDK to create secure client and server connections with policy-controlled overlays.
  • Embedding Secure Connectivity:
    Use the SDK in your application's code to join the OpenZiti overlay; all connections are encrypted and authenticated.
    Example: In NodeJS, use ziti-sdk-nodejs to connect to an overlay-protected API: const ziti = require('ziti-sdk'); ziti.connect('internal-api', ...)
  • Sample Use Cases:
    • Secure HTTP Requests:
      Use the SDK to make HTTP(S) requests over the zero trust network.
      Example: A Python script uses the Go SDK as a sidecar, ensuring all outbound REST calls are encrypted and policy-checked.
    • Microservices Communication:
      Services running in separate environments communicate securely using the embedded SDK.
      Example: A Java shopping cart microservice connects securely to a Go payment processor through the overlay, preventing exposure of payment data.
  • Developer Resources:
    Extensive documentation, guides, and code samples are available at OpenZiti’s GitHub and on the official documentation site.
• Practical Examples:
  • Prometheus Monitoring:
    Set up Prometheus to collect metrics over the encrypted overlay using OpenZiti identities. Agents and targets are registered and mapped with CLI commands and config, ensuring no monitoring endpoint is ever publicly exposed.
  • SSH and File Transfer:
    Use zssh for overlay-based SSH access, or zscp for uploading/downloading files, all without open ports on the target hosts.
    Example: zssh admin@prod-server secures SSH management over the overlay, enforcing identity checks and audit trails.

OpenZiti’s security model is built on zero trust principles and advanced cryptography, ensuring that every connection is authenticated, authorized, and encrypted. Here’s a step-by-step breakdown of how the model works in practical deployments, with examples grounded in OpenZiti CLI and SDK usage:

• Zero Trust Foundation:
  No device, user, or application is trusted by default. Every access request is authenticated and authorized, regardless of network location.
  Example: A user running ziti edge enroll must present valid credentials and be assigned access via policy before reaching any service.
• Strong Identity-Based Access:
  Each user, device, or service receives a unique cryptographic identity. Policies map these to services.
  Example: Issue an identity with ziti edge create identity user dev1 -o dev1.jwt, then restrict service access based on that identity.
• Multi-Layered Authentication:
  Supports x509 certificates, JWTs, username/password, and multi-factor authentication. MFA can be enforced at enrollment.
  Example: An admin requires TOTP for CLI enrollments: users must enter a one-time code as part of ziti edge enroll dev1.jwt workflow.
• Granular Authorization Policies:
  Access is fine-grained and fully enforced by policy.
  Example: Use ziti edge create service-policy app-access Dial --identity-roles "#developers" --service-roles "#internal-api" to map a group of users to a specific service.
• End-to-End Encryption:
  All overlay traffic is encrypted, regardless of application protocols.
  Example: An SDK-embedded NodeJS microservice transmits sensitive data; even if sent over HTTP, OpenZiti ensures it's protected in transit by libsodium-powered encryption.
• No Open Ports or Public Exposure:
  Resources are hidden ("dark") from the public internet.
  Example: A database server only accessible through the OpenZiti overlay—no inbound firewall rules or public NAT needed.
• Mutual TLS (mTLS) and Secure Routing:
  All components use mTLS 1.2+ for secure, authenticated intercommunication.
  Example: Edge Routers and controllers are auto-enrolled with their own certificates and use mTLS for all CLI-driven operations and SDK connections.
• Continuous Monitoring and Revocation:
  Active sessions are watched and can be revoked immediately via policy.
  Example: An admin issues ziti edge delete identity dev1; the user's sessions are terminated live and access is blocked instantly.
• Private DNS and Single-Port Transport:
  Service discovery and transport are obfuscated and secured.
  Example: A CLI or SDK client uses authenticated, private DNS to resolve api.ziti and connects over a single high-entropy port, making fingerprinting and unauthorized scanning extremely difficult.