Frozen document. Dates and status refer to its original source. Private resources and unreviewed images are unavailable.

Proposed Mac VM isolation for Atlas

Historical alternative. ADR 0010 supersedes the dedicated Lima guest. Atlas will develop and certify on the Mac, then deploy to cloud hosting. This experiment is retained as research, not a required security gate for the current plan.

Status: owner approved a disposable prototype on 2026-09-23. The baseline boot succeeded but guest-root access to Mac loopback remained possible. Network containment is not accepted or complete. Related decision: Choose the Docker-first runtime topology and external accounts. Research: Mac VM options.

Recommended candidate

Use one dedicated ARM64 Linux guest under Lima with Apple's Virtualization.framework, explicit plain mode, and guest-side Docker Engine/Compose. Keep the frontend demo gateway, backend/workers, Keycloak, Camunda, PostgreSQL, ClamAV, private documents and tunnel connector inside that guest. CloudHub and Contentful remain SaaS. The Mac keeps the browser, source checkout, VM management and deployment tooling.

This is a conventional Linux VM with reduced host integration. It is not a Firecracker microVM. Firecracker requires Linux/KVM; nesting adds complexity without a demonstrated Atlas benefit. Apple's per-container VM model merits later evaluation, but Compose compatibility is unproven here. Sources and alternatives are in the research asset.

Start capacity evaluation at 8 virtual CPUs, 16 GiB RAM and 80 GiB disk. The inspected Mac has 64 GiB RAM and 16 logical CPUs. The guest budget is unmeasured; Camunda and scanning dominate it regardless of the VM label. Preserve the unrelated existing Colima profile.

File, credential and management boundaries

• No host directory mounts, including read-only home shares. No SSH-agent, X11, host Docker socket or personal credential forwarding. Do not inherit host proxy credentials or preserve the host environment in guest commands.
• Transfer selected source archives and synthetic fixtures explicitly. Exclude .git, credential files and unrelated project data. Guest builds and persistent volumes stay on guest disk.
• Keep GitHub and Anypoint deployment credentials on the host. Inject only Atlas-specific runtime credentials into the guest through a controlled transfer. A compromised guest can read its own runtime secrets; scope and rotate those secrets accordingly.
• Disable dynamic application port forwarding. Review management SSH separately and permit only a deliberate Mac-loopback binding to the demo HTTPS gateway for browser access. No LAN listeners, bridged NIC or automatically exposed container ports.
• Keep the tunnel stopped outside demo sessions. Terminating the tunnel removes the remote application path; stopping the VM stops the guest workload. Neither action revokes stolen credentials.
• FileVault protects the VM disk at rest. Retain volumes on normal shutdown. Reset or restore workflow, business, document and delivery state together to avoid inconsistent synthetic transactions.

Lima documents plain mode and version-pinned configuration. The installed CLI exposes plain mode and mount removal. These facts establish configuration options, not proof that the proposed guest is isolated.

Network gap that must be resolved

Lima's documented default user-mode network exposes host loopback through 192.168.5.2 / host.lima.internal. NAT therefore does not establish guest-to-host isolation. Disabling host DNS resolution or removing that hostname does not remove IP reachability. Default network documentation.

A proposed upstream user-v2 network policy feature was still open when checked on 2026-09-23. Do not assume the installed Lima 2.2.0 supports it. No supported, tested external egress filter has been selected for Atlas yet.

Require enforcement outside the workload guest. A firewall inside the same guest adds defense but cannot contain guest root. The selected mechanism must block new guest-initiated connections to Mac addresses and services, other VMs, LAN/VPN destinations and link-local endpoints across IPv4 and IPv6. It must handle host gateway aliases, public addresses belonging to the host and DNS names that resolve to blocked destinations. Permit only required remote services and explicit network infrastructure such as DNS. Browser-initiated connections to the approved guest gateway may receive replies.

Do not prescribe generic macOS firewall rules without validating the actual VM networking path. User-space networking can present traffic differently from a bridged interface. A host filter or separately controlled gateway is a candidate requiring evidence, not a configured guarantee.

If this boundary cannot be established with maintainable tooling, use a separate machine or cloud VM without routes back to the Mac/LAN before enabling public connectivity. That alternative reduces reliance on local network containment and requires a separate hosting decision.

Evidence required before tunnel activation

1. Inspect the resolved VM definition and live mounts, sockets and listeners. Prove host home, credential stores and unrelated workspaces are absent.
2. From guest root, test against temporary harmless listeners on Mac loopback and its network interfaces, plus authorized LAN test targets. Include gateway aliases, raw IPs, DNS, IPv6 and VPN paths. Do not scan unrelated devices. Confirm denial with external enforcement evidence.
3. Confirm the browser can use the single approved guest gateway and required public dependencies remain reachable. Check behavior after restart, network change and enforcement failure; disable remote exposure if containment is lost.
4. Test the actual ARM images, Compose operation, restart persistence and combined resource use. Inspect the chosen image and package pins before provisioning.
5. Only after containment passes, test tunnel route denial, backend service authentication and Atlas authorization, and the narrowly exposed Keycloak realm endpoints. The VM does not replace application security or prevent disclosure of guest-held synthetic data/secrets.

The initial research provisioned nothing. A subsequent owner-authorized VM prototype booted with no shared mounts and demonstrated guest-root access to a harmless Mac-loopback listener. The VM and listeners are now stopped; its disk remains for later investigation. See prototype evidence and the open security experiment. No network filter, tunnel or cloud account was provisioned. Remaining risk includes guest secrets, application flaws, hypervisor vulnerabilities and host administrator access. The recommendation reduces host integration; it does not claim complete isolation.