Federation Architecture — Sovereign Enclaves, Hierarchical Trust, Cross-Enclave Operation

1. Design premise

A Writ enclave is the unit of sovereignty — its own Kubernetes cluster, its own identity realm, its own key management, its own accreditation boundary. When an enclave dies, every other enclave stays up. When an enclave is compromised, the blast radius is that enclave. When a new enclave is stood up, it can be accredited as a delta against a signed baseline rather than a full review from scratch.

Real missions, however, span enclaves: CONUS + INDOPAC + tactical edge + coalition partner + IL5 NSS slice. A federation layer lets those enclaves cooperate along four dimensions — identity, network, data, model — without ever collapsing into a shared control plane.

This paper documents each dimension, the hierarchical trust root that binds them, and the no-cross-impact-level rule that preserves accreditation.

2. Trust hierarchy

2.1 Fleet root

The fleet root is a single signing key, held on an offline HSM, signed only during quorum-approved ceremonies on a scheduled rotation (default: 90-day rotation of regional roots; 18-month rotation of the fleet root itself). The fleet root uses SLH-DSA-SHA2-256s (hash-based, stateless; see WP-002 §7 for algorithm rationale).

The fleet root signs a small set of artifacts:

• Regional root keys
• Emergency revocation statements
• Baseline OSCAL component definitions
• Release provenance bundles

Nothing else.

2.2 Regional roots

A regional root is online but sparsely used. It signs:

• Enclave root bundles in its region
• Regional OSCAL tailoring overlays
• Federation-policy signing keys

A typical deployment has three to six regional roots — commonly CONUS, CONUS-NSS, EUCOM, INDOPAC, CENTCOM, and a coalition / FVEY regional root.

2.3 Enclave roots

An enclave root is online and routinely used. It issues SPIFFE service identities for workloads in the enclave and signs local policy-evaluation results. Its compromise confines blast radius to the enclave.

2.4 Service identities

Every workload gets a SPIFFE ID from SPIRE within its enclave. SPIFFE identities are scoped spiffe://{trust-domain}/ns/{namespace}/sa/{service-account}/workload/{workload-name}. The trust domain is the enclave’s identifier — typically a short code like conus-1.writsov.com.

3. Identity federation

3.1 Keycloak brokering

Every enclave runs its own Keycloak. For a coalition query, the Keycloak of the querying enclave brokers authentication to the Keycloak of the answering enclave. The external identity provider (for example, an FVEY partner IdP) is registered as a brokered identity provider on the querying enclave’s Keycloak. The token issued for the cross-enclave call carries the trust domain of the issuing enclave, the brokered IdP’s name, and the original end-user claims.

3.2 External IdP trust

Customer organizations typically already have identity infrastructure — Okta, Azure AD, PingFederate, DoD CAC / PIV, military branch-level IdPs. Each of those is registered as a brokered provider in the relevant enclave’s Keycloak. The customer’s identity administrators retain full control; Keycloak is a broker, not a replacement.

3.3 mTLS at the mesh

Internal service-to-service authentication uses mTLS with SPIFFE-issued identities, validated by Istio’s mesh. A cross-enclave mTLS connection explicitly terminates at the federation gateway and re-originates inside the peer enclave with a local identity. This prevents an external identity from inheriting intra-enclave access by accident.

4. Network federation

4.1 Cilium ClusterMesh

L4 connectivity across enclaves is provided by Cilium ClusterMesh. Each participating enclave runs a mesh-control-plane peer. Policy at the Cilium layer is CiliumNetworkPolicy resources declaring which L4 flows are permitted between enclaves. The default is deny.

The ClusterMesh control plane does not share secrets across enclaves; each cluster remains a distinct control plane with its own etcd. The peering is pairwise — if three enclaves need to cooperate, three pairings exist.

4.2 Hybrid PQC on cross-enclave TLS

Every cross-enclave TLS uses the same hybrid X25519 + ML-KEM-768 + ML-DSA-65 posture as north-south ingress. This is not a separate code path; the dcrypto wrapper enforces it, and federation is a client of the same wrapper.

4.3 CDS transit for cross-impact-level

The cast-iron rule of the federation layer is that IL4 traffic and IL5 traffic never flow directly between enclaves. Every cross-impact-level channel transits a Cross-Domain Solution (CDS). The federation control plane knows the impact level of every enclave and refuses to route pairwise between enclaves of different impact levels. A CDS is an accredited third-party component; we integrate with Forcepoint, Owl, and BlueSpace models.

5. Data federation

5.1 Trino + Iceberg

Cross-enclave analytics use Trino as the query engine with Iceberg as the table format. Each enclave maintains its own Iceberg catalog; a Trino cluster runs in the querying enclave and issues federated queries against remote Iceberg endpoints. Data filters applied by OPA (see §5.2 below) run on the serving side, not the querying side, so data never leaves the serving enclave without policy evaluation.

5.2 OpenFGA and ABAC at query time

Every cross-enclave data access is authorized by OpenFGA with Attribute-Based Access Control policies. Attributes evaluated include: caller identity, caller trust domain, classification level of the data, release markings, releasability to partner (e.g., NOFORN, REL TO FVEY), and purpose-of-use.

5.3 Search federation

OpenSearch cross-cluster search is supported for full-text and hybrid search. The search API respects the same ABAC policy as analytical queries.

6. Model federation

6.1 Gateway peering

An enclave’s Writ gateway can peer with another enclave’s Writ gateway at the /v1/* surface. When a peered call comes in, the local gateway validates the cross-enclave token, checks release policy, and either (a) answers locally from the enclave’s models or (b) forwards to a specified downstream peer.

6.2 Federated learning (Flower)

Federated learning across enclaves uses the Flower framework with a homomorphic-aggregation plugin built on TenSEAL (CKKS). Gradients are encrypted in the client enclave before leaving; the aggregator sees only encrypted gradients and sums. The aggregated encrypted gradient is decrypted only inside the enclave with the decryption key. No enclave ever sees another enclave’s plaintext training data.

6.3 MCP peering

At the agent layer, each enclave’s MCP Director (see WP-001 §1.2) can announce a subset of its tools to peer enclaves. A peer enclave’s agent can then call those tools by their writ.federation.{peer}.{tool} namespace. Every tool invocation is OPA-gated; many tools are peer-invokable in read-only or aggregation mode but not in write mode.

7. The no-cross-impact-level rule

The rule, stated plainly: IL4 traffic never flows to IL5 without transiting a CDS, and IL5 traffic never flows to IL4 without transiting a CDS. Every cross-impact-level channel is explicit, auditable, and defaults off.

In implementation terms:

• Federation-policy keys name both enclaves’ impact levels; the policy engine rejects pairings that violate the rule.
• Cilium ClusterMesh peering is forbidden between enclaves of different impact levels.
• Gateway peering across impact levels is allowed only via an explicitly-registered CDS route.
• OPA rules refuse any action whose evaluation produces a cross-impact-level channel.

The rule is the reason a Type Authorization is feasible. A new enclave is a delta review: “how does this enclave differ from the signed baseline, and does it violate the no-cross-impact-level rule?” The delta is small because the baseline forbids the cross-impact-level collapse that would balloon the review.

8. Federated accreditation pattern

The N-th enclave is accredited as follows:

1. Start from the signed baseline SSP for the relevant impact level.
2. Produce a tailoring overlay that documents the new enclave’s operating environment (physical location, tenancy model, external integrations).
3. Produce a network-policy overlay that documents the new enclave’s ClusterMesh peerings.
4. Produce a federation-policy overlay that documents the cross-enclave routes the new enclave participates in.
5. Run the evidence-collector against the new enclave for the assessor’s requested time window.
6. Assessor reviews the overlays and the evidence sample; grants Type-Authorization coverage if the overlays remain within the signed baseline’s constraints.

Typical delta-review time: 4–10 weeks, versus 12–18 months for a from-scratch accreditation.

9. What federation is not

• Not a shared control plane. Each enclave keeps its own control plane. Federation is a set of opt-in connectors, not a supervening authority.
• Not a single sign-on across ATO boundaries. Identity is brokered per call; a cross-impact-level session is refused at the broker, not at the application.
• Not a global data lake. Iceberg catalogs stay local; federation queries pull filtered views, never full replicas.
• Not a shared secret. No credential or key crosses an enclave boundary without being re-issued by the peer’s local identity infrastructure.

10. A worked example: coalition query at IL4

Scenario: an FVEY partner enclave issues a maritime-anomaly query that must be answered by a CONUS IL4 enclave. The query topic is release-to-FVEY.

Sequence:

1. Partner end-user authenticates to Partner Keycloak (brokered from partner IdP).
2. Partner agent calls writ.federation.conus-1.query with the query text and topic.
3. Partner’s Keycloak issues a cross-enclave token carrying the end-user’s identity, the partner trust domain, and the release-to-FVEY claim.
4. Cilium ClusterMesh routes the call from Partner enclave to CONUS-1 enclave over hybrid PQC TLS.
5. CONUS-1’s federation gateway validates the token against the signed federation policy, then validates release-to-FVEY against OPA for the query topic.
6. If both checks pass, CONUS-1 answers from its local /v1/* surface (typically generative + RAG).
7. Response is returned through the federation gateway, with an encrypted attestation of the source enclave.
8. Both enclaves emit an AU-12 audit record referencing a shared federation audit ID.

Throughout: no shared control plane, no cross-impact-level violation, no CONUS plaintext data ever leaves CONUS.

11. References

• SPIFFE and SPIRE specifications
• Cilium ClusterMesh documentation
• Istio ambient mesh
• Flower federated learning framework
• TenSEAL / OpenFHE homomorphic encryption
• Apache Iceberg specification
• Writ Architecture Reference — see WP-001
• Writ PQC white paper — see WP-002
• Writ Accreditation Dossier — see WP-003