ACRA Enclaves

The ACRA portal defines the primary access and governance boundary for a deployment. Within this boundary, an ACRA enclave is an isolated execution environment that hosts one or more applications together with their required supporting services, and acts as a secondary, nested boundary enforcing compute, storage, network, and identity isolation.

What Enclaves Are

An enclave contains:

• Application workloads
• Supporting services such as databases or messaging systems
• Policy definitions governing communication and access
• Enclave-scoped identity and secret bindings

Enclaves execute on shared underlying infrastructure, including containerised workloads and optional virtual machine isolation (for example via KubeVirt), while remaining isolated at the compute, storage, network, and identity layers. Isolation is enforced by the platform, not by application logic.

Isolation is enforced by platform mechanisms rather than by application logic. Applications, Valarian and Custom, inherit authentication, encryption in transit, encryption at rest, explicit ingress and egress controls, and workload-scoped authorisation without implementing those controls themselves.

An enclave is therefore a hard boundary with defined ingress, egress, identity scope, and policy enforcement.

Threat Model

ACRA enclaves operate under an assumed-breach model.

The platform assumes:

• workloads may contain vulnerabilities
• infrastructure may be multi-tenant
• external networks are untrusted
• users may have differing privilege levels

Under this model the enclave prevents:

• lateral movement between enclaves
• unauthorised east-west communication
• uncontrolled data egress
• privilege escalation from workload to control plane

Default-deny networking ensures that workloads cannot initiate communication outside their defined policy scope.

Identity enforcement at the enclave boundary ensures that access to services and data is authenticated and authorised before execution proceeds.

Separation between control plane and application plane prevents compromise of a workload from granting administrative authority over enclave lifecycle or policy.

This threat model does not rely on application correctness. It relies on enforced architectural boundaries.

Isolation Guarantees

Isolation in ACRA enclaves is enforced across multiple layers.

Compute Isolation

Workloads run as isolated containers and pods with enforced resource limits.

Multiple enclaves may run on the same node, but runtime separation is enforced through orchestration and policy controls.

Node-level placement policies can further constrain sensitive workloads when required.

Network Isolation

All ingress and egress traffic is policy-defined and default-deny.

Nothing enters or leaves an enclave unless explicitly permitted.

All traffic flows through controlled interfaces where identity and authorisation are validated.

This applies to:

• enclave-to-enclave communication
• enclave-to-external systems
• external systems calling into an enclave

If a communication path is not declared in policy, it does not exist.

Identity and Secret Isolation

Enclaves do not share identity scopes, permissions, or secrets.

RBAC and ReBAC models enforce workload-level and user-level authorisation.

Secrets are injected per workload rather than embedded in application code.

Compromise of one enclave does not grant identity or secret access to another enclave.

Data Isolation

Encryption at rest is enforced by platform storage services.

Encryption in transit is enforced by service mesh controls.

Application data, logs, and runtime state remain enclave-scoped unless explicit federation is configured.

Lifecycle of an Enclave

The enclave lifecycle is managed exclusively by the control plane.

The control plane is responsible for:

• creating enclaves
• applying configuration and policy
• deploying and updating applications
• managing permissions and secrets
• publishing status and health visibility

The enclave plane executes workloads and enforces runtime policy.

It does not control its own creation, identity model, or external permissions.

Enclaves are provisioned through declarative configuration and remain active until explicitly deleted.

There is no sleep or archive state at the control plane, core, or infrastructure level.

Deletion removes the active runtime environment according to configured operational procedures.

Operational visibility includes:

• deployment validation
• health checks and metrics
• issue reporting with contextual logs
• update readiness gating

This lifecycle model ensures enclave state transitions remain controlled, observable, and attributable.

Control Plane vs Application Plane

ACRA maintains a strict separation between the control plane** and the **enclave plane.

Control Plane Responsibilities

The control plane:

• manages lifecycle and configuration
• controls permissions and identity models
• provides version visibility and health status

It does not execute application logic or access application data.

Enclave Plane Responsibilities

The enclave plane:

• runs application workloads
• processes mission data
• enforces runtime network and identity policy

It cannot alter its own lifecycle state or expand its trust boundaries.

This separation prevents workload compromise from escalating into platform-level compromise.

Conclusion

ACRA enclaves provide enforced isolation, explicit communication control, and lifecycle governance at the architectural level.

They constrain blast radius, prevent implicit trust, and allow sensitive workloads to operate securely on shared infrastructure without cross-environment contamination.