Lifecycle and Operations

This page explains how applications are built, deployed, updated, and revoked inside ACRA. It also describes how operational responsibilities are divided across the platform.

ACRA separates lifecycle control from workload execution:

Layer	Responsibility
Control Plane	Manages enclave lifecycle, platform services, permissions, and configuration
Enclaves	Execute workloads under enforced isolation
System and Infrastructure	Provide hardened compute, storage, and networking

Application Lifecycle in ACRA

Applications run inside secure enclaves. An enclave is an isolated runtime environment with controlled ingress and egress, resource limits, and enforced policy.

The control plane manages lifecycle events affecting enclaves and their applications. These lifecycle events include enclave creation and configuration, as well as update and delete.

Enclave configuration

Enclave configuration defines:

• Users and roles
• Applications and services to run
• Enclave options

Configurations are versionable and reproducible, allowing controlled rollout and reliable recovery.

When launched, the control plane provisions required services inside the enclave. Each service runs in its own Kubernetes namespace.

Deployment tooling such as ArgoCD and Helm applies manifests. Supporting services such as Postgres or NATS are provisioned inside the enclave boundary rather than shared externally.

All inter-service communication is denied by default and must be explicitly permitted through policy.

Encryption is enforcement

Encryption is enforced by platform services:

• Istio provides encrypted service communication
• Ceph provides encrypted storage

Once provisioned, enclaves remain active until explicitly deleted.

Why Enclaves Instead of Separate Virtual Machines

ACRA enclaves provide strong workload isolation without requiring each environment to run on its own virtual machine.

In VM-based deployments, networking, identity, secrets, and supporting services are typically configured separately for each environment.

In ACRA, these controls are enforced by the platform.

Enclaves inherit:

• Default-deny networking
• Encrypted service communication
• Identity-based access control
• Centrally managed lifecycle operations

This reduces configuration drift, limits misconfiguration risk, and allows multiple isolated environments to run securely on shared infrastructure.

Build, Deploy, Update, Revoke

Build

Application artefacts are built outside the enclave using standard CI pipelines.

Images and manifests are stored in a platform-controlled registry.

ACRA does not require application code to implement encryption or network enforcement. These controls are applied by the platform through:

• Service mesh policy enforcement
• Storage encryption
• Network policy enforcement

Secrets and credentials are not embedded in application code. Operators inject credentials into running workloads through controlled mechanisms.

Deploy

Deployment is initiated through the control plane.

The control plane performs the following actions:

• Validates permissions
• Applies declarative configuration
• Provisions supporting services
• Injects secrets
• Publishes status and version visibility

Ingress and egress rules are applied at the enclave boundary. No workload becomes reachable without explicit policy configuration.

After rollout, deployment validation checks run automatically. Failures are recorded and linked to logs. Update readiness gates can block promotion if validation fails.

Update

Updates may include:

• Application version changes
• Service configuration changes
• User and role updates
• Policy adjustments

Updates are orchestrated by the control plane and applied declaratively.

Pre-deployment checks and health validation reduce the risk of propagating faulty releases.

Isolation boundaries remain enforced during updates. Changes to one enclave do not affect other enclaves.

Revoke

Revocation can apply to:

• User access
• Service-to-service permissions
• External federation paths
• Entire enclaves

Access control is enforced using RBAC and ReBAC models at the platform layer.

When access is revoked, subsequent requests are denied at the boundary before reaching application logic.

ACRA does not support archival states at the control plane, core, or infrastructure levels.

If an enclave is no longer required, it must be explicitly deleted. Deletion removes the active runtime environment according to configured policy and operational procedures.

Operational Model

ACRA operates as a layered system:

1. Control plane
2. Enclaves
3. System and infrastructure
4. Authentication for third-party applications
5. Applications inside enclaves

Each layer has a defined role.

Layer	Role
Control Plane	Creates, configures, updates, and observes enclaves
Enclaves	Enforce runtime isolation and host application workloads
System and Infrastructure	Provide compute, networking, storage, monitoring, and baseline security
Platform Services	Provide logging, monitoring, scanning, and secret management
Applications	Implement business logic inside enclave boundaries

Health and behaviour checks continuously assess deployment state.

Operators can inspect:

• Environment health
• Error rates
• System behaviour changes

through shared dashboards and alerts.

All provisioned enclaves remain active. Capacity management and scaling are handled through infrastructure and orchestration controls rather than by suspending environments.

Responsibility Boundaries

Clear responsibility separation reduces implicit trust and configuration risk.

Platform Maintainers

Maintainers manage:

• Control plane configuration
• User management
• Enclave creation
• Enclave updates

Sub-roles such as Auditor and Ops extend visibility into activity logs and operational tooling.

Maintainers manage enclave lifecycle and configuration through the control plane, but this authority does not grant access to workloads or data inside an enclave.

Access to an enclave requires explicit membership.

Maintainers therefore operate the platform environment rather than the workloads themselves.

Enclave Owners and Contributors

Within an enclave:

Role	Capabilities
Owner	Manage enclave settings, user access, collaboration artefacts, and activity logs
Contributor	Operate applications they are permitted to access

Contributors cannot alter global platform settings and cannot view detailed user information across the enclave.

Actions performed in one enclave do not grant privileges in another.

Application Developers

Developers define:

• Application logic
• Data models
• Workflow behaviour

They rely on platform-enforced controls including:

• Network policy
• Encryption
• Identity and access control
• Secret injection

Developers do not configure infrastructure controls directly.

System and Infrastructure Operators

Infrastructure operators maintain:

• Compute environments
• Networking layers
• Storage systems

They ensure baseline monitoring, redundancy, and certificate management remain operational.

Infrastructure does not grant implicit workload trust. Trust is established at the enclave boundary through identity and policy enforcement.

Summary

ACRA’s lifecycle and operational model enforces isolation at every stage:

• Build
• Deploy
• Update
• Delete

The control plane manages system state. Enclaves enforce execution boundaries. Infrastructure provides hardened compute and networking.

This separation allows operators to evaluate risk, validate enforcement mechanisms, and recover systems without collapsing trust boundaries across the platform.

Reference

[1] K8s namespaces