Security

This article explains Arctic's security model, authentication mechanisms, and trust relationships.

Trust Model

Arctic's trust model is based on cryptographic verification:

License-Based Trust

Trust flows from the license:

Tillered signs licenses with cryptographic keys
Agents verify license signatures at bootstrap
Peers verify each other against the same license
Only peers with valid, matching licenses can join

Why License-Based?

No central authority: Peers verify independently
Offline capable: No network call to verify membership
Cryptographic: Cannot be forged without private keys
Revocable: License expiration limits access

Cryptographic Security

Arctic uses industry-standard cryptographic algorithms throughout:

Digital signatures for license signing, peer identity, and handshake authentication
Authenticated encryption for transport security between peers
Modern key exchange protocols with perfect forward secrecy for IP tunnels

All cryptographic implementations use well-audited libraries and follow current best practices.

Peer Authentication

Key Generation

During bootstrap, each peer:

Generates a cryptographic key pair
Stores the private key securely in $DATA_DIR/peer.key
Registers the public key with the cluster

Handshake Authentication

When peers connect:

Both peers must have valid signatures to complete the handshake.

API Authentication

OAuth2 Client Credentials

API authentication uses OAuth2:

Client sends client_id and client_secret
Server validates credentials
Server issues JWT access token
Client uses token for subsequent requests

Token Structure

Access tokens are JWTs containing:

Peer ID (issuer)
Client ID (subject)
Scopes (permissions)
Expiration (1 hour default)

Scope-Based Authorization

Credentials can be limited to specific operations:

Scope	Permissions
`admin`	Full access
`peers.read`	List/get peers
`peers.write`	Add/update/delete peers
`services.read`	List/get services
`services.write`	Create/update/delete services
`credentials.read`	List credentials
`credentials.write`	Create/revoke credentials

Transport Security

API (HTTPS)

For production deployments:

Use a reverse proxy with TLS
Arctic agent serves HTTP by default
TLS termination at load balancer recommended

Peer Communication

Peer-to-peer traffic is always encrypted:

TCP traffic: Encrypted headers and payload
Non-TCP traffic: Encrypted tunnel with forward secrecy
No plaintext between peers

Data Security

At Rest

Sensitive data stored on disk:

Data	Location	Protection
Private key	`peer.key`	File permissions (600)
Credentials	`arctic.db`	Application-level
License	`license.json`	Signed, not encrypted

Recommendations

Restrict file system access to Arctic data directory
Use full-disk encryption for hosts
Regular backups of arctic.db

License Security

License Structure

Licenses contain:

{
  "license_id": "lic_...",
  "customer_id": "cust_...",
  "issued_at": "2024-01-01T00:00:00Z",
  "expires_at": "2025-12-31T23:59:59Z",
  "max_nodes": 10,
  "max_services": 100,
  "signature": "base64..."
}