Custom Applications in ACRA

This page defines what constitutes an application in ACRA, how trust boundaries are enforced, how identity is assigned, and how applications are registered and admitted into an enclave.

This page is an architectural explanation describing enforcement mechanisms and system boundaries.

ACRA Platform Model

ACRA separates platform management, workload execution, and infrastructure responsibilities.

Layer	Purpose
Control Plane	Creates and manages enclaves, deployments, permissions, and configuration
Enclaves	Execute application workloads under enforced isolation
Platform Services	Provide logging, monitoring, scanning, and secret management
System & Infrastructure	Provide hardened compute, networking, and storage

Applications operate inside enclaves and inherit platform-enforced controls including authorization, identity, encryption, and network policy.

What Defines an Application

In ACRA, an application is a workload deployed inside a secure enclave that:

• Executes business or mission logic
• Interacts with platform services through controlled interfaces
• Emits logs, metrics, and audit events
• Operates under enclave-scoped policy

An application is not defined by a single container image.

An application may consist of:

• One or more services
• Supporting components such as Postgres, Redis, or NATS
• Storage bindings
• Policy definitions
• Network rules

All components execute inside the enclave boundary.

These components inherit the following enforcement mechanisms from the platform:

• Authentication and identity enforcement
• Encryption in transit
• Encryption at rest
• Explicit ingress and egress control

An application is therefore defined by:

Property	Description
Runtime components	Services and supporting components that execute together
Identity	The workload identity assigned by the platform
Policy scope	Network, access, and resource policies applied to the application
Integration points	Controlled interactions with platform services

Infrastructure is not considered part of the application definition. Infrastructure remains a separate layer in the ACRA system model.

Trust Boundaries

ACRA enforces several trust boundaries that apply to custom applications.

Enclave Boundary

The enclave is the primary isolation boundary.

It enforces:

• Default-deny ingress and egress
• Resource limits
• Visibility of communication
• Service-to-service policy enforcement
• Workload isolation

Inter-service communication must be explicitly authorised. No implicit east-west trust exists.

Custom applications cannot bypass enclave controls. All execution occurs within this boundary.

Control Plane vs Application Plane

The control plane creates and manages enclaves and deployments.

Applications execute inside enclaves and cannot modify control plane state.

This separation ensures:

• Operators manage lifecycle and policy
• Applications execute business logic
• Compromise of one application does not grant control plane authority
• Control plane roles and application roles remain separate

Application-level identities cannot acquire platform administrative permissions.

Inter-Application Boundaries

When multiple applications run inside a single enclave:

• Communication is policy-defined
• Identity is workload-scoped
• Secrets are injected per workload

When applications run in separate enclaves, communication must follow an explicit federation pattern such as:

• enclave-to-enclave communication
• enclave-to-external federation

There is no implicit cross-enclave access.

Application Identity Model

Each application workload operates under an assigned identity.

Identity enforcement occurs at the platform layer using RBAC and ReBAC models.

Application identity is used to:

• Authorise service-to-service calls
• Validate access to databases or object storage
• Scope secret injection
• Enforce policy at the enclave boundary

Authentication and authorisation checks occur before workflow execution begins.

Identity is not embedded in application code. It is assigned and validated by the platform.

This prevents developers from implementing ad-hoc trust models that bypass platform enforcement.

All access decisions are auditable through platform logging and telemetry services.

Application Registration Flow

Application registration is a control-plane-managed process.

This process establishes:

• Application identity
• Deployment configuration
• Declared supporting services
• Network policy scope
• Secrets and configuration bindings

Registration Sequence

1. The application artefact is published to a controlled registry.
2. The control plane validates operator permissions.
3. Declarative configuration is applied and version tracked.
4. Required supporting services are provisioned inside the enclave.
5. Secrets are injected dynamically at runtime.
6. Network policy is enforced before exposure.
7. Deployment validation checks run and publish status.

50%

The application does not become reachable until ingress policy is explicitly configured.

If validation fails, promotion is blocked by the control plane.

Deletion of an application removes its active runtime environment. There is no archive or sleep state at the control plane or infrastructure level.

Summary

Applications in ACRA operate within enforced execution boundaries defined by the enclave architecture.

The platform controls:

• Identity assignment
• Policy enforcement
• Network boundaries
• Secret distribution
• Lifecycle management

Applications implement business logic while the platform enforces containment and access discipline.

This separation ensures that workload execution does not weaken platform control or security guarantees.