Zero Trust Architecture

Exaba’s internal architecture is zero-trust by construction: identity is cryptographic, not topological. A request is trusted because it presents a current X.509 leaf certificate signed by the cluster’s intermediate CA, not because it arrived on a particular IP, network segment, or VLAN.

Mutual TLS on every internal hop

Every service-to-service call inside an Exaba cluster is authenticated and encrypted with mutual TLS (mTLS). There is no fallback path that admits an unauthenticated request on the assumption that the underlying network is trusted.

When a request arrives at any internal endpoint, the mTLS layer:

  1. completes the mutual TLS handshake,
  2. extracts and validates the peer’s certificate,
  3. reads the service identity and role grants encoded in the certificate, and
  4. rejects the request with 401 Unauthorized if any step fails.

Only after identity is established does the request reach the handler.

Identity is a signed property of the certificate

Role grants for every internal service are signed into the leaf certificate at issuance, so they cannot be forged or upgraded after the fact:

  • A caller cannot claim a role it was not issued.
  • A compromised network position cannot escalate privilege by impersonating an internal address; the verifier checks the certificate chain, the validity dates, and the signed roles before any handler runs.

Service handlers consult the certificate’s role grants to decide whether the caller is allowed to perform the requested operation.

Pure-mTLS on internal endpoints

Internal service-to-service authentication is mTLS-only; there is no JSON Web Token (JWT) path between internal services. JWTs are used only for end-user-facing interactions with the IAM service, for example browser-driven console login.

For control-plane API calls that need a bearer token, for example audit-trail submissions, services use a Machine-to-Machine (M2M) client that obtains short-lived access and refresh tokens against the control plane over mTLS. Tokens are signed asymmetrically and short-lived, so a stolen token cannot be silently replayed.

Verifier configuration

The internal mTLS verifier requires a valid client certificate on every internal endpoint. “Optional” client authentication is used only at the public client edge, where TLS terminates before traffic enters the internal mesh.

The verifier is keyed off the cluster’s intermediate CA chain, delivered by the control plane at install time. Leaf certificates are short-lived and rotated automatically, so a compromised certificate expires quickly without bespoke revocation tooling.

What this gives you

  • No flat-network trust. Internal lateral movement gains nothing without a valid leaf certificate issued by the cluster CA.
  • No bearer-token replay across internal services. mTLS-only on internal endpoints removes the JWT replay attack surface that service meshes commonly carry.
  • Role separation that survives network compromise. Roles are signed into the certificate, not asserted in headers.
  • Short blast-radius windows. Short-lived leaf certificates mean a compromised certificate expires quickly.

See also: System Components for the inter-service map, and Encryption & Key Management for the PKI roots that issue these certificates.