Pragmatism Over Purity: Architecting Iddio Control Server v2.2

When building an infrastructure gateway, architectural purity often crashes headfirst into enterprise reality. In designing the new Control Server for Iddio v2.2, we faced a series of foundational decisions that pit ideal theoretical designs against the hostile network environments our daemon operates in.

We ship to environments we do not control. Our daemon sits behind aggressive enterprise forward proxies, runs in isolated environments without external identity providers, and guards critical infrastructure. Every decision in the v2.2 Control Server reflects a strict preference for pragmatism, resilience, and operational simplicity.

Here is a look at three major architectural decisions we made, and why we rejected the "standard" industry answers.

Transport: Connect RPC over Raw gRPC

For the device-facing API—handling enrollment, policy syncs, and telemetry—we need a typed contract. The industry default is raw gRPC, built on HTTP/2 with trailers.

We reject raw gRPC for v2.2. Instead, we use Connect, serving protobuf-defined RPCs over standard HTTP/1.1.

The Reality of Enterprise Egress

Raw gRPC makes a fatal assumption: that the network allows HTTP/2 and HTTP trailers through egress proxies. In many enterprise environments, forward proxies terminate TLS, inspect traffic, and aggressively downgrade connections to HTTP/1.1. If you bet your entire transport layer on HTTP/2, a single misconfigured middlebox completely breaks your control plane.

Connect gives us the exact developer experience of gRPC—typed protobuf contracts, code generation, and strict schemas—without the protocol fragility. Connect speaks ordinary HTTP/1.1 and looks like normal HTTPS to any proxy. It allows the daemon to degrade gracefully and ensures that our only outbound connection remains robust, regardless of the egress environment.

We trade theoretical multiplexing performance for absolute network reliability. In a control plane, reliability wins.

Identity: Enrollment Tokens over OIDC Device Flow

Establishing device identity is the hardest problem in zero-trust architecture. The modern playbook points to the OIDC Device Authorization Grant (device flow), tying a machine directly to a human identity via Single Sign-On.

We defer OIDC device flows. For v2.2, device identity relies entirely on an admin-minted enrollment token that bootstraps a signed device credential.

Bootstrapping Without the Hot Path

Relying on an external Identity Provider (IdP) introduces a massive external dependency into the critical path. If the IdP goes down, or the daemon loses reachability to the external internet, the infrastructure gateway fails.

Our flow is simple and self-contained:

1. An administrator mints a short-lived, single-use enrollment token.
2. The daemon redeems this token with the Control Server.
3. The daemon generates a keypair, and the server validates the token to sign a Mutual TLS (mTLS) client certificate.
4. Every subsequent API call authenticates via this mTLS credential.

We decouple human operator authentication (which uses an OIDC session for the admin API) from device authentication. There is no token replay, and no external IdP is required on the hot path. We optimize for isolated, air-gapped, or highly restricted environments where external SSO is not guaranteed.

Policy Enforcement: Embracing the Fail-Closed Reality

When a managed daemon loses connectivity to the Control Server, how should the policy engine behave? The standard approach often includes a "grace period" or a fallback to a permissive local configuration.

We choose a strict fail-closed posture. An enrolled daemon never silently falls back to an unmanaged, permissive local file.

The Honest Enforcement Posture

If a daemon enrolls with a Control Server, it explicitly enters a managed state. In this state, local policy edits are strictly locked. The daemon downloads the server's compiled engine, stores the raw YAML to disk as a last-known-good state, and disables the local-file watcher.

If the daemon loses connectivity:

1. It continues enforcing the last-known-good managed policy from disk.
2. It surfaces staleness warnings via the CLI and desktop UI.
3. It explicitly refuses to loosen enforcement.

A grace window or silent local fallback creates a massive security loophole: a governed user could bypass organizational policy simply by blocking egress traffic. The absence of server contact indicates a degraded state, not a reason to drop governance. The only authorized way to revert to local control is through a deliberate, server-side revocation.

(There is one narrow exception: an enrolled daemon that has never successfully synced keeps enforcing its existing local policy until the first sync succeeds, preventing a deny-by-default blackout during initial setup.)

Conclusion

Building software for hostile environments requires abandoning ideal states. Raw gRPC assumes perfect networks; OIDC assumes perfect uptime; graceful fallbacks assume benign intent. By choosing Connect over HTTP/1.1, mTLS device credentials over external IdPs, and strict fail-closed enforcement, the Iddio v2.2 Control Server acknowledges the reality of enterprise deployments.

Sometimes, the most sophisticated architectural decision is choosing the boring technology that survives contact with the real world.