Deployment guide

OpenBao

Overview

OpenBao is the open-source, community-driven fork of HashiCorp Vault for secrets management. It stores tokens, passwords, certificates and encryption keys securely and tightly controls access to them, with dynamic secrets, leasing and renewal, encryption as a service, and a complete audit trail.

This SecureAnyCloud image installs OpenBao 2.5.5 as a dedicated systemd service, with file storage bound to loopback behind an nginx reverse proxy on port 80. The encrypted store lives on a dedicated Azure data disk, and the vault is initialised and unsealed with unique keys on the first boot of every VM.

What you get:

OpenBao 2.5.5 (binary /usr/bin/bao) with file storage and the web UI enabled
nginx on :80 fronting the loopback OpenBao listener (OpenBao uses token authentication, not basic authentication)
Per-VM initialisation: five unseal keys and a root token generated on first boot and saved to a root-only file
Automatic unseal on every boot from the stored keys
A dedicated Azure data disk at /var/lib/openbao that holds the encrypted store, separate from the OS disk and re-provisioned with every VM
openbao.service and nginx.service as enabled, active systemd units
24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2ms (2 vCPU / 8 GiB RAM) is a good starting size.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network and 80/tcp for the web UI and API. Put TLS in front of port 80 before you expose it publicly (see Enabling HTTPS).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for OpenBao by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Review the dedicated data disk on the Disks tab, then select Review + create and Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:openbao-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name openbao \
  --image sac1647283583153:openbao-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name openbao --port 80 --priority 1010

Step 3 - Connect to your VM

Connect to the VM over SSH as the administrator user:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

Check that both services are active:

systemctl is-active openbao.service nginx.service

Both services report active. The vault is initialised and unsealed automatically on first boot.

Step 5 - Retrieve your unseal keys and root token

On first boot, OpenBao is initialised with five unseal keys and a root token. Both are written to a root-only file. Read it as root:

sudo cat /root/openbao-credentials.txt

OPENBAO_ROOT_TOKEN signs you in to the UI and authenticates API calls. OPENBAO_UNSEAL_KEY_1..5 unseal the vault.

Copy these values somewhere safe, then remove the file. Anyone with the keys and root token has full control of your secrets. The vault unseals itself on reboot from the stored keys. For stronger protection, move to an external auto-unseal (KMS) and delete the stored keys.

Step 6 - Check the health endpoint

nginx serves an unauthenticated health endpoint for load balancers and probes. Query it:

curl -s http://localhost/health

It returns ok.

Step 7 - Open the web UI

Browse to http://<vm-public-ip>/ui/ and sign in with the token method, using OPENBAO_ROOT_TOKEN from Step 5.

The UI lists your secrets engines. From there you can create, read and manage secrets, policies and authentication methods.

Step 8 - Confirm the vault from the command line

The API expects the root token in an X-Vault-Token header. Run the following to confirm that the vault is initialised and unsealed:

curl -s -H "X-Vault-Token: <OPENBAO_ROOT_TOKEN>" http://localhost/v1/sys/health | jq '{initialized, sealed, version}'

The output shows "initialized": true, "sealed": false and the running version.

Step 9 - Store and read a secret

Enable the key/value (version 2) secrets engine, write a secret and read it back. All three calls use the API with your root token:

curl -s -H "X-Vault-Token: <OPENBAO_ROOT_TOKEN>" -X POST -d '{"type":"kv","options":{"version":"2"}}' http://localhost/v1/sys/mounts/secret
curl -s -H "X-Vault-Token: <OPENBAO_ROOT_TOKEN>" -X POST -d '{"data":{"db_password":"S3cr3t-Pa55"}}' http://localhost/v1/secret/data/myapp/config
curl -s -H "X-Vault-Token: <OPENBAO_ROOT_TOKEN>" http://localhost/v1/secret/data/myapp/config | jq '.data.data'

The final read returns { "db_password": "S3cr3t-Pa55" }. The same secret is now visible in the web UI under the secret/ engine.

Step 10 - Confirm storage lives on the dedicated disk

The encrypted store sits on the dedicated Azure data disk, so it survives OS changes and can be resized independently. Confirm the mount:

findmnt /var/lib/openbao

The mount is backed by a separate Azure data disk that is captured into the image and re-provisioned on every VM.

Enabling HTTPS

The nginx reverse proxy serves plain HTTP on port 80. OpenBao handles sensitive secrets, so terminate TLS before you expose it.

Add a DNS name for the VM. Then either use the companion SecureAnyCloud nginx-ssl-certbot image as a TLS reverse proxy, or install certbot and extend the existing nginx site with a listen 443 ssl; server block.

Keep OpenBao bound to loopback, so the only public surface is the authenticated, TLS-terminated proxy.

Maintenance

Auto-unseal. The vault unseals itself on reboot from the keys in /root/openbao-credentials.txt. Configure an external auto-unseal (cloud KMS) and remove the stored keys for stronger protection.
Backups. Snapshot the /var/lib/openbao data disk to back up the encrypted store.
Policies and authentication. Create ACL policies and enable auth methods (AppRole, userpass, JWT and others) in the UI under Policies and Access. Stop using the root token for day-to-day work.
Upgrades. Install a newer OpenBao package, then run sudo systemctl restart openbao. The vault re-seals on restart, and the unseal service unseals it again.
Security patches. unattended-upgrades stays enabled, so the OS keeps receiving security updates automatically.

Support

SecureAnyCloud provides 24/7 expert support for this image. For questions or help with your deployment, contact sales@secureanycloud.com.

Deploy on Azure

Launch OpenBao on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Overview

OpenBao is the open-source, community-driven secrets management platform. It is a Linux Foundation project and the MPL-2.0 licensed fork of Vault. It stores tokens, passwords, certificates, API keys and other secrets centrally, tightly controls access to them, and provides encryption as a service so your applications never handle raw keys. You can work with it from the built-in web UI, the bao command-line interface or the HTTP API.

This SecureAnyCloud image installs the single static bao server binary under /usr/local/bin. It runs as a dedicated unprivileged openbao system account under a systemd service that starts on boot and restarts on failure. The built-in web UI and the full HTTP API are published on port 8200.

What you get:

Encrypted secret store on OpenBao's integrated raft storage at /var/lib/openbao, a dedicated, independently resizable EBS data volume
OpenBao starts sealed and uninitialized. On the first boot of every instance, a one-shot service initializes the store, captures the single unseal key and initial root token unique to that instance, unseals the server, and writes both to /root/openbao-credentials.txt with mode 0600, readable only by root
No shared or default credentials, no pre-initialized store and no preset unseal key in the image, so two instances launched from the same Amazon Machine Image never share a root token or unseal key
A second service that re-unseals the server automatically after every reboot, so the appliance returns to a healthy state unattended

Prerequisites

Before you deploy this image, make sure you have:

An Amazon Web Services account where you can launch EC2 instances
IAM permissions to launch instances, create security groups and subscribe to AWS Marketplace products
An EC2 key pair in the target Region for SSH access to the instance
A VPC and subnet in the target Region, with a security group that allows inbound port 22 from your management network and port 8200 for the web UI and the HTTP API
The AWS CLI (version 2) installed locally, if you plan to deploy from the command line

Launch the instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for OpenBao. Select the SecureAnyCloud listing, choose Select, then choose Continue on the subscription summary.

Pick an instance type of t3.medium or larger. Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, then create or select a security group that opens port 22 from your management network and port 8200 for the web UI and the HTTP API. Leave the root volume at the default size or larger.

Select Launch instance. First-boot initialisation runs once, after the instance state becomes Running and the status checks pass. It initializes and unseals OpenBao, so allow a short moment before the web UI accepts a sign-in.

Launch the instance from the AWS CLI

Run the following command to launch an instance from the SecureAnyCloud OpenBao Marketplace AMI into an existing subnet and security group. Replace <ami-id> with the AMI ID shown on the Marketplace listing. Replace <key-name> with your EC2 key pair name and <subnet-id> with your subnet ID. Replace <security-group-id> with a security group that opens ports 22 and 8200 as described above.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type t3.medium \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=openbao}]'

When the instance reaches the Running state and its status checks pass, note its public IP address or DNS name. You can find it in the EC2 console or with aws ec2 describe-instances.

Connect to your instance

Connect over SSH, using your key pair and the login user for your operating system variant.

OS variant SSH login user

Ubuntu 24.04 ubuntu

ssh -i <key-name>.pem ubuntu@<public-ip>

Retrieve the root token and unseal key

The initial root token and the single unseal key are unique to your instance. They were generated on first boot. Read the credentials file as root:

sudo cat /root/openbao-credentials.txt

The file lists the web UI URL, the initial root token (openbao.root.token) and the single unseal key (openbao.unseal.key). The auto-unseal service uses the same unseal key to bring the server back up after a reboot.

Keep both values somewhere safe. The root token is the most privileged credential in OpenBao, so treat it like a master password. Step 11 explains how to replace it with your own admin credentials.

Confirm OpenBao is running and unsealed

Over SSH, confirm that the service is active and the server reports healthy. The health endpoint returns HTTP 200 only when OpenBao is both initialized and unsealed:

sudo systemctl is-active openbao

curl -s http://127.0.0.1:8200/v1/sys/health | head -c 200; echo

A healthy server reports "initialized":true and "sealed":false in the JSON. To check the installed version, run:

bao version

Sign in to the web UI

The built-in web UI is served on port 8200. In a browser, open:

http://<instance-public-ip>:8200/ui/

The sign-in page offers a Method selector. Leave it set to Token, paste your initial root token into the Token field and choose Sign In. You land on the Secrets Engines list, the main dashboard for the store.

Because you signed in with a root token, OpenBao reminds you that the token is held in your browser for this session only and is not persisted. You must sign in again after you close or refresh the window. This is expected behaviour for the initial root token.

Enable a secrets engine and store a secret

From the Secrets Engines list, choose Enable new engine to mount an engine such as KV (key/value), PKI, SSH, Database or Transit (encryption as a service). After you enable a KV version 2 engine, you can write a secret at a path and read it back through the UI. The screenshot below shows a key/value secret with several fields stored in the KV engine. The values are masked until you reveal them.

You can do the same from the command line. On the instance, point the CLI at the local server and authenticate with your root token. Then enable an engine and write a secret. Replace <your-token> with the initial root token from the credentials file:

export BAO_ADDR=http://127.0.0.1:8200
export BAO_TOKEN=<your-token> bao secrets enable -path=secret kv-v2 bao kv put secret/myapp/config username=app password=example bao kv get secret/myapp/config

Alternatively, run bao login interactively and paste the token when prompted, instead of exporting BAO_TOKEN.

Configure authentication methods

Real users and applications should not use the root token. Open the Access section of the UI to manage Authentication Methods. The screenshot below shows the token method (always present) alongside a userpass method enabled on the server.

Enable an auth method that suits your environment: userpass, AppRole for machines, or JWT/OIDC for single sign-on. Then attach policies that scope each identity to only the paths it needs. From the CLI, for example (replace <your-token> with your root token):

export BAO_ADDR=http://127.0.0.1:8200
export BAO_TOKEN=<your-token> bao auth enable userpass bao write auth/userpass/users/alice password=changeme policies=default

Check the data volume

The encrypted secret store, the init and seal state, and the raft logs all live on a dedicated EBS volume mounted at /var/lib/openbao, using OpenBao's integrated raft storage. This keeps the store off the operating system disk and lets you resize or snapshot it independently. Confirm the mount:

df -h /var/lib/openbao

To grow the store, expand the EBS volume in the AWS console. Then grow the filesystem on the instance by running sudo resize2fs on the underlying device.

Auto-unseal across reboots and switching to AWS KMS

After any reboot, OpenBao comes back sealed, and the health endpoint returns 503 until it is unsealed. This image ships a small auto-unseal service. On every boot, it reads the stored unseal key from the credentials file and unseals the server, so the appliance returns to a healthy state unattended.

Storing the unseal key on the instance is a single-node convenience. It lets the appliance survive reboots without an operator, but it weakens the seal guarantee, because anyone with root and disk access to the instance can unseal the server.

For stronger protection, switch to AWS KMS auto-unseal, which keeps the unseal material in AWS Key Management Service rather than on the instance. To switch:

Add a seal "awskms" stanza to /etc/openbao/config.hcl that references a KMS key your instance role can use.
Give the instance an IAM role with kms:Encrypt, kms:Decrypt and kms:DescribeKey on that key.
Migrate the existing Shamir seal to KMS.
Disable the bundled openbao-unseal.service and remove the stored unseal key from /root/openbao-credentials.txt.

With KMS auto-unseal in place, OpenBao unseals itself from KMS on every boot, with no key on disk.

Enable TLS and replace the initial root token

This appliance serves OpenBao over plain HTTP on port 8200 by default, so it is ready to use immediately. To harden it:

Enable TLS. Obtain a certificate for your domain. Add a tls_cert_file and tls_key_file to the listener "tcp" stanza in /etc/openbao/config.hcl and remove tls_disable = true, so the API and UI are served over HTTPS. Update api_addr and cluster_addr to the https:// scheme. Restrict the security group so port 8200 is reachable only from the networks that use OpenBao.
Replace the initial root token. Create your own admin auth method and policies (Steps 7 and 8) and confirm that you can administer the server with them. Then revoke the initial root token written on first boot, so it can no longer be used:

export BAO_ADDR=http://127.0.0.1:8200
export BAO_TOKEN=<your-token> bao token revoke <your-token>

If you need a new root token after revoking the old one, generate it with bao operator generate-root and a quorum of unseal key holders.

Back up and maintain

Back up the secret store by snapshotting the /var/lib/openbao EBS volume, which captures the entire raft store. Alternatively, take a consistent raft snapshot with bao operator raft snapshot save. Keep the snapshot and your unseal or recovery keys somewhere safe, because the store is encrypted and useless without them.

Apply operating system security updates with sudo apt-get update && sudo apt-get upgrade. Reboot when a new kernel is installed. OpenBao starts and unseals automatically on boot.

Support

SecureAnyCloud publishes and supports this image. Support covers deployment, secrets engine and auth method configuration, policies, PKI, transit encryption, AWS KMS auto-unseal, TLS, raft storage and backup. Contact SecureAnyCloud through the support channel listed on the AWS Marketplace listing.

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.

Deploy on AWS

Launch OpenBao on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on AWS