Overview
This is a repackaged open source software product wherein additional charges apply for hardening, security configuration, and setup support.
WHAT IS OPENBAO
OpenBao is an open-source secrets management platform, forked from HashiCorp Vault 1.14 and now hosted by the Linux Foundation. Written in Go and distributed as a single static binary, OpenBao gives applications and operators a central place to store, generate, and rotate secrets: static key-value secrets, dynamic database credentials, AWS/GCP/Azure cloud credentials, x509 certificates via the PKI engine, encryption-as-a-service through the transit engine, SSH certificate authorities, JWT/OIDC issuance, and TOTP. Identity is unified through pluggable auth methods - userpass, AppRole, JWT/OIDC, Kubernetes, LDAP, GitHub, AWS IAM, Azure, GCP - and access is gated by ACL policies against fine-grained paths. The Web UI ships built in. State is held in a pluggable storage backend: file, integrated raft, or external (S3, DynamoDB, Postgres, MySQL). MPL-2.0 license, fully auditable, no vendor lock-in.
WHAT THIS AMI ADDS
Security hardening:
- OpenBao listener bound to 127.0.0.1:8200 only - reachable from the network only through the Nginx reverse proxy on TCP 443 with TLS
- Auto-initialisation at first boot with 5 unseal key shares and a threshold of 3; the initial root token plus all 5 unseal keys are written to /root/openbao-credentials.txt (chmod 600 root-only)
- Auto-unseal on every reboot using a root-only cached subset of the unseal keys at /var/lib/openbao/.unseal-keys - operators do not have to SSH in and unseal manually after a reboot; a clear production-migration path is documented in the same credentials file (revoke root token, replace TLS cert, move to KMS or Transit auto-unseal, delete the on-disk cache)
- Nginx reverse proxy with TLS, HTTP-to-HTTPS redirect, security headers (X-Content-Type-Options, X-Frame-Options, Referrer-Policy), long-poll timeouts tuned for OpenBao's blocking events endpoint
- UFW firewall pre-configured - only TCP 22, 80, 443 are exposed; OpenBao on TCP 8200 stays loopback-only
- fail2ban, AppArmor
- CVE scan - every image is scanned for vulnerabilities before release
OS hardening (CIS Level 1):
- CIS Ubuntu 24.04 LTS Level 1 benchmark applied via ansible-lockdown
- auditd, SSH hardening, kernel hardening, IMDSv2 enforced
Compliance artifacts:
- SBOM - CycloneDX 1.6 at /etc/lynxroute/sbom.json
- CIS Conformance Report at /etc/lynxroute/cis-report.html
- CIS Tailored Profile at /usr/share/doc/lynxroute/CIS_TAILORED_PROFILE.md
ARCHITECTURE NOTES
Storage is the file backend at /opt/openbao/data, persisted across reboots. The seal type is shamir (default); we set the standard 5-key share / 3-key threshold. For production use the credentials file documents how to migrate to KMS (AWS/GCP/Azure) or Transit auto-unseal so the on-disk seal keys can be removed. OpenBao's own listener has tls_disable=true because Nginx terminates TLS - operators replace the self-signed certificate with a CA-signed one through certbot --nginx without restarting OpenBao (which would re-seal the store).
Highlights
- OpenBao security baked in: API on loopback (TCP 8200) behind Nginx with TLS, store auto-initialised at first boot with a 5-of-3 unseal share, root token plus all 5 unseal keys in a root-only credentials file, auto-unseal on every reboot from a root-only on-disk key cache.