FIPS 140-3 hyperconverged infrastructure
Security Model
Basalt’s security model starts with database-enforced multi-tenancy and continues through FIPS-path cryptography, zero-trust agent enrollment, short-lived resource activation leases, and fail-closed authorization.
Database-Enforced Multi-Tenancy
Postgres Row-Level Security is applied at every business table. Basalt does not rely on every application query remembering to append the correct tenant predicate; the database engine itself refuses rows outside the active authorization context.
The rls_transaction() wrapper sets that authorization context at transaction start,
before business reads or writes execute. Cross-tenant data leaks are eliminated at the database
layer, not merely at the application layer.
Even if application code has a bug, RLS prevents cross-tenant reads. This is the security side of the architecture described in Basalt’s three-component architecture.
FIPS 140-3 Without OpenSSL
Basalt uses aws-lc-rs and rustls throughout the platform. There is no
OpenSSL dependency anywhere in the management plane.
The FIPS path is built on a FIPS-validated cryptographic module with AlmaLinux 10 as the host operating system. That gives regulated infrastructure teams a modern Rust TLS stack without reintroducing OpenSSL as a platform dependency.
This model is designed for environments such as regulated infrastructure requiring auditable cryptography.
Zero-Trust Agent Identity
Agents enroll with ECDSA P-384 keypairs and a one-time bootstrap token. After enrollment, the platform performs periodic reauthentication with nonce rotation instead of treating first contact as permanent trust.
Agent sessions use HMAC-SHA256 JWTs with jti deny-list support and rate limits.
Mutual TLS plus nonce-rotated JWTs is stronger than typical shared-secret agent schemes because
both the transport identity and the application token must remain valid.
Resource Activation Leases
Activation leases are short-lived grants authorizing agents to take dangerous actions on specific resources. Without an active lease, agents will not execute those operations even if the manifest says to.
This protects against split-brain and dual-active corruption by requiring current permission at the moment of action. The lease table is itself RLS-protected, so tenants cannot observe or mint grants outside their scope.
For VM operations, these leases complement compute lifecycle controls enforced through the Basalt agent.
Fail-Closed Authorization
Basalt models authorization as roughly 200 granular permissions in resource.action
form. Permissions are evaluated across system, tenant, and cluster scopes so high-impact
operations can be delegated without flattening every operator into an administrator.
Custom role definitions are tenant-scoped. Missing or ambiguous authorization does not become an implicit allow; it fails closed.