Security Architecture

Understanding Noid's security model, isolation guarantees, and best practices.

Threat Model

Assumptions

Untrusted code execution: VMs may run malicious code
Network attacks: VMs may attempt network-based attacks
Resource exhaustion: VMs may try to consume excessive resources
Escape attempts: VMs may try to break isolation

Protection Goals

Host protection: Prevent VM escape to host
VM isolation: Prevent cross-VM attacks
Resource limits: Prevent DoS via resource exhaustion
Data confidentiality: Protect sensitive data
API security: Secure server access

Isolation Layers

1. Hardware Isolation (KVM)

Technology: Linux Kernel-based Virtual Machine

Guarantees:

Hardware-enforced memory isolation
CPU execution isolation
Interrupt isolation
I/O isolation via IOMMU (if available)

Attack Surface:

Kernel vulnerabilities
Hardware side-channels (Spectre, Meltdown)

Mitigations:

Keep kernel updated
Enable CPU mitigations
Use dedicated hardware for sensitive workloads

2. Firecracker VMM

Design Principles:

Minimal codebase (~50K lines of Rust)
No unnecessary features
Built with memory-safe language
Extensive security testing

Attack Surface:

Firecracker API
Device emulation layer
Snapshot/restore logic

Mitigations:

Regular security updates
Fuzzing and penetration testing
Reduced device emulation surface

3. Network Isolation

Mechanisms:

Separate network namespaces
Isolated TAP devices
Controlled routing

Protection:

VMs cannot sniff other VMs' traffic
Network flows are isolated
Host network is protected

Configuration:

# Default: isolated but can communicate
noid create vm1  # Gets 172.16.0.10
noid create vm2  # Gets 172.16.0.11
# vm1 can ping vm2

# Fully isolated network
noid create vm3 --network isolated

4. Filesystem Isolation

Mechanisms:

Separate rootfs per VM
No shared filesystems
Independent disk encryption (optional)

Protection:

VMs cannot access other VMs' data
VMs cannot access host filesystem
Copy-on-write prevents data leaks

Authentication & Authorization

API Authentication

Token-based auth:

# Generate token on server
noid-server token create --name my-token

# Use token in CLI
noid auth setup --token <token>

Token format:

64-character hex string
Stored in ~/.noid/config.toml
Sent in Authorization header

Security:

Tokens are secret, treat like passwords
Rotate tokens regularly
Use different tokens for different environments

Authorization Model

Permissions:

Role	Create VM	Destroy VM	Execute	Checkpoint	List VMs
Admin	✓	✓	✓	✓	✓
User	✓	Own only	Own only	Own only	Own only
Read-only	✗	✗	✗	✗	✓

TLS/SSL

Production setup:

# /etc/noid/config.toml
[server]
tls_cert = "/etc/noid/cert.pem"
tls_key = "/etc/noid/key.pem"

Best practices:

Always use TLS in production
Use valid certificates (Let's Encrypt)
Enforce minimum TLS 1.2
Disable weak ciphers

Resource Limits

Per-VM Limits

# CPU limits
noid create vm --vcpus 2  # Max 2 vCPUs

# Memory limits
noid create vm --memory 2048  # Max 2GB

# Disk quotas (future)
noid create vm --disk-quota 10G

Server-wide Limits

# /etc/noid/config.toml
[limits]
max_vms_per_user = 10
max_total_vms = 100
max_vcpus_per_vm = 8
max_memory_per_vm = 16384  # MB

Data Protection

Secrets Management

Environment variables:

# ✗ Bad: secrets in VM filesystem
noid exec vm -- export API_KEY=secret123
noid checkpoint vm snap1  # API_KEY in snapshot!

# ✓ Good: secrets via exec env
noid exec vm -e API_KEY=secret123 -- ./app
# API_KEY not persisted

Checkpoint encryption:

# Encrypt sensitive checkpoints
noid checkpoint vm snap1 --encrypt --key-file ./key.pem
noid restore vm snap1 --decrypt --key-file ./key.pem

Data at Rest

Disk encryption:

# LUKS encryption for VM data
cryptsetup luksFormat /dev/vdb
mount /dev/mapper/encrypted /var/lib/noid

Checkpoint storage:

Checkpoints contain full VM state
Include memory dumps (may contain secrets)
Apply filesystem encryption
Control access permissions

Network Security

Firewall Rules

Host firewall:

# Allow only server port
iptables -A INPUT -p tcp --dport 7654 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT  # SSH
iptables -A INPUT -j DROP

VM firewall:

# Restrict VM network access
noid exec vm -- iptables -A OUTPUT -p tcp --dport 443 -j ACCEPT
noid exec vm -- iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
noid exec vm -- iptables -A OUTPUT -j DROP

Network Policies

Isolate VM groups:

# Production VMs
noid create prod-vm --network-group production

# Development VMs
noid create dev-vm --network-group development

# No cross-group communication

Audit Logging

Server Logs

# /etc/noid/config.toml
[logging]
level = "info"
audit = true
audit_file = "/var/log/noid/audit.log"

Audit events:

VM creation/destruction
Command execution
Checkpoint operations
Authentication failures
Configuration changes

Example log:

{
  "timestamp": "2024-01-15T10:30:00Z",
  "event": "vm.exec",
  "user": "alice",
  "vm": "prod-api",
  "command": "systemctl restart nginx",
  "success": true
}

Security Best Practices

1. Principle of Least Privilege

Use read-only tokens when possible
Limit VM resources to minimum needed
Restrict network access
Regular permission audits

2. Defense in Depth

Multiple isolation layers
Network segmentation
Regular updates
Monitoring and alerts

3. Secure Defaults

TLS enabled by default
Strong token generation
Resource limits enforced
Audit logging enabled

4. Regular Updates

# Update Noid components
apt-get update
apt-get upgrade noid-server noid-cli

# Update Firecracker
./scripts/update-firecracker.sh

# Update kernel (for KVM security fixes)
apt-get upgrade linux-image-generic

5. Monitoring & Alerting

Security metrics to track:

Failed authentication attempts
Unusual resource usage
Network anomalies
Checkpoint creation frequency
VM lifecycle events

Compliance Considerations

Data Residency

VMs run on specified host
Checkpoints stored locally
No data sent to external services
Full control over data location

Encryption Requirements

TLS for data in transit
Optional disk encryption for data at rest
Encrypted checkpoints for sensitive data

Audit Requirements

Comprehensive audit logging
Immutable log storage
Log retention policies
Regular security audits

Vulnerability Disclosure

Reporting security issues:

Email: security@noid.one
PGP key: Available on website
Response time: 48 hours
Coordinated disclosure process

Next Steps

Architecture Overview - System architecture
Deployment - Production setup
Server Setup - Configure Noid server