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.

Authentication and Access Control

SSH Key Management

The lab uses ed25519 SSH keys for host authentication. All automation hosts share a common key pair:

SSH Hardening and Drop-In Standards

All hosts use standardized hardening.conf} drop-ins in /etc/ssh/sshd\_config.d/:

Password Policy -- Subnet Exceptions

Passwords are used only as a temporary fallback. The following hosts have documented exceptions:

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}

Network Security

Subnet Segmentation

The lab is divided into dedicated subnets providing implicit isolation:

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.

Certificate and TLS Management

The ``tls'' role manages certificate provisioning across the lab:

Credential Management

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:

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.

Backup and Disaster Recovery

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

  1. <strong>NTP (time host)</strong> -- time sync failure cascades to all Kerberos authentication
  2. <strong>DNS (node3, BIND)</strong> -- resolution failure makes most hosts unreachable by name
  3. <strong>Kerberos KDC</strong> -- authentication cascade failure affects all service access
  4. <strong>LDAP</strong> -- directory services, offline since December 2025

Container and Kubernetes Security

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
  • Automated Security Scanning

    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.