Zero trust

Explanation of Alpacon’s zero trust security model and how it differs from traditional SSH approaches.

What is zero trust?

Zero trust is a security model based on the principle “never trust, always verify”. It doesn’t distinguish between internal and external networks—every access is verified.

Limitations of traditional SSH

Security risks

Port 22 exposed to the internet

• Constant bot scans for SSH daemons (thousands per day)
• Automated brute force attempts
• Zero-day vulnerabilities in SSH daemon
• Attack surface exists even with fail2ban and firewalls

Full server access with SSH keys

• SSH keys are all-or-nothing
• Read-only operations require full access
• If key leaks, attackers have complete control
• No way to restrict specific commands

Operational pain points

Key rotation nightmare

• 10 servers = 10 different keys to manage
• Each repository needs its own copy of secrets
• Must update all servers and repos during rotation
• No centralized management view

No centralized audit trail

• Logs scattered across multiple servers
• SSH logs show only IP addresses (not which workflow)
• Hard to trace “Who deployed last Tuesday at 3pm?”

Alpacon’s zero trust implementation

API token-based authentication

Instead of SSH keys, Alpacon uses API tokens with fine-grained access control.

Command ACLs (Access Control Lists)

• Explicitly specify allowed commands per token
• Block operators (&&, ||, |, >, ;) to prevent command chaining
• Even if token leaks, only permitted commands work

# Example: Token with specific command allowlist
allowed_commands:
  - "pm2 restart app"
  - "systemctl status nginx"
  - "git pull"

Reverse connection (zero exposed ports)

Servers don’t open any externally accessible ports.

1. Server initiates outbound connection to Alpacon workspace
2. No inbound ports on server
3. Server not discoverable from internet

Threats eliminated:

• SSH port scanning
• Brute force attacks
• Direct connection attempts

Centralized audit trail

All access and command execution is automatically logged.

• Operator (user/token) and target server
• Exact command executed with full output
• File transfers with size and timestamps
• Centrally managed in workspace

Simple token management

SSH key rotation (traditional)

1. Generate new key pairs for each server
2. Update authorized_keys on every server
3. Update GitHub Secrets in every repository
4. Debug failures

Alpacon token rotation

1. Update token in workspace
2. Update GitHub Secrets once
3. Done

Security benefits summary