Network Containment Specification

This document defines how ACRA enforces network containment between workloads, enclaves, and external systems.

The specification describes:

• The network isolation model
• Allowed communication paths
• Policy definition examples
• Enforcement mechanisms

Key invariant

ACRA uses a default-deny network model. No service, enclave, or external system communicates unless policy explicitly allows the path.

1. Network Isolation Model

ACRA enforces network isolation at multiple layers of the platform. Isolation boundaries exist between enclaves, between services inside an enclave, and between the enclave and external networks.

The platform implements a default-deny network model:

• No service may communicate with another service unless policy explicitly allows the connection
• No external system may access an enclave unless ingress rules permit it
• Outbound network communication is blocked unless explicitly authorised

Each enclave operates as an independent execution environment with controlled ingress and egress. Workloads inside an enclave are isolated from workloads in other enclaves and from the underlying infrastructure network.

Isolation is enforced across three containment boundaries.

Boundary	Description
Inter-enclave isolation	Enclaves cannot communicate with each other unless a federation policy is configured
Intra-enclave service isolation	Services inside an enclave cannot communicate unless service-to-service policy allows it
External network boundary	All ingress and egress traffic passes through controlled gateways and policy enforcement points

This structure ensures that network paths are always explicit and observable.

50%

2. Allowed Communication Paths

ACRA recognises a small number of permitted communication patterns. All permitted paths require explicit policy configuration.

External → Enclave

External systems may access APIs hosted inside an enclave through an ingress gateway. The gateway enforces authentication, routing, and policy validation before traffic reaches the application.

Typical use cases include:

• User access to enclave applications
• API calls from trusted upstream systems
• Federation from external data sources

Enclave → External

Applications inside an enclave may call external systems when egress policy permits it.

Outbound communication is restricted to:

• Approved destination domains or IP ranges
• Approved ports and protocols
• Approved application identities

Typical use cases include:

• Federated analysis services
• External data sources
• Third-party APIs

Enclave → Enclave

Within a single ACRA deployment, one enclave may call services hosted in another enclave when explicitly authorised.

Examples include:

• Shared platform services (for example a model inference enclave)
• Data replication between enclaves
• Cross-environment orchestration

These interactions are controlled using identity-based service policies.

ACRA → ACRA

Separate ACRA deployments may communicate for controlled federation scenarios such as replication or failover.

These connections require:

• Explicit network allow rules
• Mutual authentication between deployments
• Transport encryption

3. Policy Examples

Network containment policies define which services may communicate and under what conditions.

Policies specify:

• Source identity
• Destination identity
• Protocol and port
• Direction of communication

Example: Service-to-Service Policy

Allow an API service to access a database within the same enclave.

policy:
  source: api-service
  destination: postgres-db
  protocol: tcp
  port: 5432
  action: allow

Enforcement summary

Network containment is enforced through a combination of service mesh policy, network policy, ingress and egress gateways, and workload identity. These controls ensure that permitted paths are explicit and all other paths are denied.