Security
Pages 48-50 of the Bitsmasher Lab Operations Manual (62 pages)
The lab.bitsmasher.net infrastructure relies on multiple security layers -- from SSH key-based authentication to automated vulnerability scanning. This chapter documents the security posture, procedures, and policies in place.
SSH Key Management
The lab uses ed25519 SSH keys for host authentication. All automation hosts share a common key pair:
- <strong>Private key:</strong> ~/.ssh/id\_ed25519\_openclaw (chonk)
- <strong>Public key:</strong> ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJb9mV02PpxD8VpzYCnu7192dTwMnGWUc3qh55BIeElN openclaw@chonk
- <strong>Key users:</strong> ``openclaw'' user on all production hosts
SSH Hardening and Drop-In Standards
All hosts use standardized hardening.conf} drop-ins in /etc/ssh/sshd\_config.d/:
- <strong>PermitRootLogin prohibit-password</strong> -- root login allowed only via key, never password
- <strong>StrictModes yes</strong> -- OpenSSH enforces file permission checks on ~/.ssh and authorized\_keys
- <strong>Explicit user key sync</strong> -- ed25519 keys deployed to target hosts via ansible ssh role; no manual key management
Password Policy -- Subnet Exceptions
Passwords are used only as a temporary fallback. The following hosts have documented exceptions:
- <strong>Jetson nodes (node900--node903)</strong>: Temporary password authentication allowed pending ed25519 key rollout. Password is \texttt{123} for the franklin user. These nodes will be migrated to key-only auth when infrastructure permits.
All other hosts enforce key-only authentication. No new password-based access may be granted without operator approval.
User Accounts
center}
tabular}{lll}
franklin & Primary admin user & All hosts; sudo NOPASSWD on skynet \\
openclaw & Automation user & All production hosts via ed25519 key \\
tabular}
center}
Subnet Segmentation
The lab is divided into dedicated subnets providing implicit isolation:
- <strong>Main office:</strong> 10.10.8.0/21 -- core infrastructure (chonk, stargate)
- <strong>Backbone:</strong> 10.10.16.0/24 -- game server, DNS services
- <strong>Edge/specialized:</strong> 10.10.12.x -- Jetson nodes, NTP, KDC, edge devices
- <strong>Service zone:</strong> 10.10.13.0/24 -- LDAP directory services
- <strong>Storage zone:</strong> 10.10.14.0/24 -- Blowfish and shared storage hosts
- <strong>Non-standard:</strong> 192.168.86.x -- Music desktop (routed through skynet)
Firewall Rules
The Ansible ``prereq'' role handles firewall exceptions for K3s API ports (6443, 2379--2381). Both UFW (Debian) and Firewalld (RedHat-family) are supported. Default policy is deny-all inbound with only explicitly allowed services accessible.
The ``tls'' role manages certificate provisioning across the lab:
- Certificates are stored on NFS (clusterfs2) for cross-host availability
- OpenLDAP server experienced a TLS failure in December 2025 due to an expired certificate -- this is the primary remaining TLS vulnerability
- All external-facing services use HTTPS with valid certificates where applicable
Pass + GPG (Stash House)
Credentials are stored using pass} with GPG encryption. The Stash House project manages encrypted credential backups synced via bare git repositories:
- Credentials never exist in plaintext in any repository
- Git repos use bare repositories to store only the encrypted .gpg files
- <strong>No git-lfs</strong> is used for credential data (see LFS policy)
Ansible Vault
Sensitive variables (firewall credentials, API keys) are stored using ansible-vault}. Vault files should never be committed to version control. The vault passphrase is managed outside the repository.
Data Backups
NFS-mounted clusterfs2 provides shared storage with redundant copies across hosts. DNS zones are version-controlled in BIND configuration files. Credential data uses GPG-encrypted pass entries synced via bare git repos.
Service Availability Status
center}
tabular}{llll}
NTP stratum-1 & time.lab.bitsmasher.net & Online & Current \\
KDC (Kerberos) & odroid-c1.lab.bitsmasher.net & Online & ~242 days uptime \\
DNS (BIND) & node3.lab.bitsmasher.net & Operational & August 2026 \\
OpenLDAP & ldap.lab.bitsmasher.net & Offline & December 2025 \\
tabular}
center}
Disaster Recovery Priorities
- <strong>NTP (time host)</strong> -- time sync failure cascades to all Kerberos authentication
- <strong>DNS (node3, BIND)</strong> -- resolution failure makes most hosts unreachable by name
- <strong>Kerberos KDC</strong> -- authentication cascade failure affects all service access
- <strong>LDAP</strong> -- directory services, offline since December 2025
The k3s cluster is hardened with:
Version pinning to 2.1.x
Containerd runtime with NVIDIA GPU support
TLS for all API communication (k3s default)
Pod security policies via Kubernetes native admission controllers
The .github directory contains the following automated workflows:
center}
tabular}{lcl}
bandit.yml & Bandit & Python static analysis for security vulnerabilities \\
tfsec-sarif.yml & tfsec & Terraform IaC security scanning \\
trivy.yaml / trivy-cb.yml & Trivy & Container and filesystem vulnerability scanning \\
bash\_check.yaml & GNU Autotools & Build system validation (make security) \\
tabular}
center}
All scanning workflows run on every pull request and main branch push. Results are uploaded as SARIF artifacts for review.