Overview
This is a repackaged software product wherein additional charges apply for hardening, security configuration, and 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 - unlike bare OpenBao AMIs that ship uninitialised and sealed, expose the API in cleartext, leave operators to run `bao operator init` and three manual unseals before any use, and re-seal on every reboot.
- CIS Level 1 hardened Ubuntu 24.04 LTS: auditd, fail2ban, AppArmor, SSH key-only, IMDSv2 enforced. CVE-scanned before every release. SBOM (CycloneDX) and CIS Conformance Report included.
- Full HashiCorp Vault feature parity from the open-source fork: KV v1/v2, transit (encryption as a service), PKI, SSH CA, database (dynamic Postgres / MySQL / MongoDB / Redis credentials), AWS / GCP / Azure cloud credentials, TOTP, identity store with userpass / AppRole / JWT / OIDC / Kubernetes / LDAP / GitHub / AWS IAM auth methods, ACL policies, audit devices, and a built-in Web UI. MPL-2.0 license - fully auditable, no vendor lock-in.
Details
Introducing multi-product solutions
You can now purchase comprehensive solutions tailored to use cases and industries.
Features and programs
Financing for AWS Marketplace purchases
Pricing
Free trial
Dimension | Cost/hour |
|---|---|
t3.large Recommended | $0.03 |
t3.medium | $0.02 |
m6i.xlarge | $0.05 |
m6i.large | $0.03 |
Vendor refund policy
We do not offer refunds for this product. AWS infrastructure charges (EC2, EBS, data transfer) are billed separately by AWS and are not refundable by us.
How can we make this page better?
Legal
Vendor terms and conditions
Content disclaimer
Delivery details
64-bit (x86) Amazon Machine Image (AMI)
Amazon Machine Image (AMI)
An AMI is a virtual image that provides the information required to launch an instance. Amazon EC2 (Elastic Compute Cloud) instances are virtual servers on which you can run your applications and workloads, offering varying combinations of CPU, memory, storage, and networking resources. You can launch as many instances from as many different AMIs as you need.
Version release notes
Version 2.5.3 - Initial release (May 2026)
- OpenBao 2.5.3 on Ubuntu 24.04 LTS
- CIS Level 1 hardening applied (ansible-lockdown/UBUNTU24-CIS)
- CVE-scanned before every release
- Auto-initialisation + auto-unseal at first boot, 5-of-3 Shamir key share
- Initial root token + all 5 unseal keys at /root/openbao-credentials.txt (chmod 600)
- OpenBao listener bound to 127.0.0.1:8200, Nginx reverse proxy with TLS on 443
- Auto-unseal on reboot from /var/lib/openbao/.unseal-keys (chmod 600)
- UFW firewall pre-configured (TCP 22, 80, 443 only)
- fail2ban, auditd, AppArmor pre-configured
- SBOM (CycloneDX 1.6) at /etc/lynxroute/sbom.json
- CIS Conformance Report (OpenSCAP) at /etc/lynxroute/cis-report.html
- IMDSv2 enforced
Additional details
Usage instructions
- Launch instance (t3.large recommended)
- Open Security Group - allow TCP 443 from your IP
- SSH: ssh -i key.pem ubuntu@<PUBLIC_IP>
- Read credentials: sudo cat /root/openbao-credentials.txt
- Open https://<PUBLIC_IP>/ - accept the self-signed certificate warning
- Sign in with the initial root token from the credentials file
- In the UI, create AppRole or userpass auth, issue limited-scope tokens, and rotate the root token
The 5 unseal keys and initial root token are stored in /root/openbao-credentials.txt at first boot. OpenBao auto-unseals at every reboot using keys cached at /var/lib/openbao/.unseal-keys (chmod 600).
Production checklist:
- Revoke the initial root token after creating scoped tokens: bao token revoke <root-token>
- Replace the self-signed TLS certificate: sudo certbot --nginx -d YOUR_DOMAIN
- Migrate from local-disk seal-key cache to KMS or Transit auto-unseal, then delete /var/lib/openbao/.unseal-keys
- Enable audit devices (file or syslog)
CLI quickstart on the instance: export BAO_ADDR=http://127.0.0.1:8200 export BAO_TOKEN=<root-token-from-credentials-file> bao secrets enable -path=secret kv-v2 bao kv put secret/hello message=world bao kv get secret/hello
Resources
Vendor resources
Support
Vendor support
Visit us online: https://lynxroute.com
For OpenBao documentation: https://openbao.org/docs/ For OpenBao upstream issues: https://github.com/openbao/openbao/issues For AWS infrastructure issues:
AWS infrastructure support
AWS Support is a one-on-one, fast-response support channel that is staffed 24x7x365 with experienced and technical support engineers. The service helps customers of all sizes and technical abilities to successfully utilize the products and features provided by Amazon Web Services.