Migrate From AWS Secrets Manager to OpenBao on Akamai Cloud

OpenBao is an open source secrets management tool and fork of HashiCorp Vault that provides teams control over how secrets are stored, encrypted, and accessed. OpenBao can be self-hosted in any environment, including on-premises and across multiple clouds.

AWS Secrets Manager is Amazon’s platform-integrated, managed secrets service that securely stores and retrieves sensitive information such as database credentials, API keys, and other application secrets.

This guide provides steps and considerations for how to migrate secrets stored in AWS Secrets Manager to OpenBao running on Akamai Cloud.

Before You Begin

1. Follow our Get Started guide to create an Akamai Cloud account if you do not already have one.

2. Ensure that you have access to your AWS cloud platform account with sufficient permissions to work with AWS Secrets Manager. The AWS CLI and eksctl must also be installed and configured.

3. Install jq, a lightweight command line JSON processor.

4. When migrating from AWS Secrets Manager to OpenBao on Akamai Cloud, OpenBao should be deployed before you begin. OpenBao can be installed on a single Linode instance or deployed to a multi-node cluster using Linode Kubernetes Engine (LKE). Follow the appropriate guide below based on your production needs:

   • Deploying OpenBao on a Linode Instance
   • Deploy OpenBao on Linode Kubernetes Engine
   • Deploying OpenBao through the Linode Marketplace

Using This Guide

This tutorial contains a number of placeholders that are intended to be replaced by your own unique values. For reference purposes, the table below lists these placeholders, what they represent, and the example values used in this guide:

Review Existing Secrets in AWS Secrets Manager

Before migrating to OpenBao, evaluate how your organization currently uses AWS Secrets Manager.

For example, a web application might rely on database credentials stored in AWS Secrets Manager. Rather than embedding these credentials in source code or container images, the application is assigned a role that allows it to retrieve them securely at runtime. This prevents secrets from being exposed through version control or CI/CD pipelines.

OpenBao supports similar access workflows using dynamic injection, AppRole-based access control, and integration with Kubernetes workloads.

Review Secrets Using the AWS Console

In the AWS Secrets Manager dashboard, navigate to the Secrets menu to review your existing secrets and their descriptions.

The below example secrets are used throughout this guide.

Review Secrets Using the AWS CLI

Alternatively, the AWS CLI can quickly provide insight into existing secrets and their usage.

1. Run the following AWS CLI command to list all secrets:

   aws secretsmanager list-secrets --query 'SecretList[*].Name'

   [
       "psql-credentials",
       "jwt-signing-secret",
       "shipping_service_api_key"
   ]

2. To retrieve the value for a specific secret, use the AWS_SECRET_NAME (e.g. jwt-signing-secret) with the get-secret-value command:

   aws secretsmanager get-secret-value \
     --secret-id AWS_SECRET_NAME \
     --query SecretString \
     --output text \
     | jq

   For Example:

   aws secretsmanager get-secret-value \
     --secret-id psql-credentials \
     --query SecretString \
     --output text \
     | jq

   {
     "username": "psqluser",
     "password": "W0H@Z52IGI0VjqoGS3xMkJ9SO533w$fcfrmzs!m$TudDxEe#",
     "engine": "postgres",
     "host": "psql.example-cloud.com",
     "port": "5432",
     "dbname": "web_app_production"
   }

AWS Secrets Manager secrets are stored either as key/value pairs or as plaintext. In the previous example, the single psql-credentials secret is a set of key/value pairs.

AWS Secrets Manager uses AWS Identity and Access Management (IAM) to control access to secrets. As an example of role-based access control (RBAC), a role such as DatabaseReader might have an attached policy that allows the secretsmanager:GetSecretValue action on the psql-credentials resource. Here, the web application that accesses the database would be given the DatabaseReader role so that it can obtain the secret values that allow it to connect to the database.

Replicating this setup using OpenBao involves creating an application role (AppRole) to take the place of the AWS IAM role. This allows applications to use an API token associated with the AppRole to authenticate requests for the secret.

Access Your OpenBao Deployment on Akamai Cloud

The following steps focus on migrating secrets into your OpenBao deployment on Akamai Cloud. You should already have a running OpenBao instance on either a standalone Linode instance, in an LKE cluster, or deployed via the Linode Marketplace.

If your OpenBao environment is not yet ready, refer to the appropriate deployment guide listed in the Before You Begin section and complete the setup.

Once deployed, log into your OpenBao environment. Before continuing, verify that:

• OpenBao is successfully initialized.
• The vault is unsealed.
• The BAO_ADDR environment variable is set.
• You are authenticated using the root token.

Create a Policy and AppRole

Use AppRoles to replicate AWS IAM-style access control in OpenBao. In AWS Secrets Manager, applications typically assume IAM roles (e.g. DatabaseReader) that permit secret retrieval via policies like secretsmanager:GetSecretValue. In OpenBao, equivalent functionality is achieved through policy-bound AppRoles that authorize secrets access through token-based authentication.

Follow these steps to create an OpenBao AppRole that mimics the IAM-based access used in AWS Secrets Manager.

Enable AppRole

1. Enable the AppRole authentication method:

   bao auth enable approle

   Success! Enabled approle auth method at: approle/

Create a Policy

2. Using a text editor like nano, create a new .hcl policy file in /etc/openbao, replacing POLICY_FILE (e.g. db-secrets-policy.hcl) with a policy filename of your choosing:

   sudo nano /etc/openbao/POLICY_FILE

   For Example:

   sudo nano /etc/openbao/db-secrets-policy.hcl

3. Give the file the following contents, replacing SECRET_MOUNT_PATH (e.g. database-credentials) with your chosen mount path:

   File: POLICY_FILE.hcl

   1 2 3

   path "SECRET_MOUNT_PATH/*" { capabilities = ["read"] }

   For Example:

   File: db-secrets-policy.hcl

   1 2 3

   path "database-credentials/*" { capabilities = ["read"] }

   This policy grants read access to any secrets within the specified mount path.

   When done, press CTRL+X, followed by Y then Enter to save the file and exit nano.

4. Add the policy to OpenBao, replacing POLICY_NAME (e.g. db-secrets-policy) and POLICY_FILE:

   bao policy write POLICY_NAME /etc/openbao/POLICY_FILE

   For Example:

   bao policy write db-secrets-policy /etc/openbao/db-secrets-policy.hcl

   Success! Uploaded policy: db-secrets-policy

Create an AppRole

5. Create an AppRole for the application that needs access to the secret, replacing APPROLE_NAME (e.g. web-app-approle) and POLICY_NAME:

   bao write auth/approle/role/APPROLE_NAME token_policies=POLICY_NAME

   For Example:

   bao write auth/approle/role/web-app-approle token_policies=db-secrets-policy

   Success! Data written to: auth/approle/role/web-app-approle

6. Verify that the AppRole was written successfully, replacing APPROLE_NAME:

   bao read auth/approle/role/APPROLE_NAME

   For Example:

   bao read auth/approle/role/web-app-approle

   Key                        Value
   ---                        -----
   bind_secret_id             true
   local_secret_ids           false
   secret_id_bound_cidrs      <nil>
   secret_id_num_uses         0
   secret_id_ttl              0s
   token_bound_cidrs          []
   token_explicit_max_ttl     0s
   token_max_ttl              0s
   token_no_default_policy    false
   token_num_uses             0
   token_period               0s
   token_policies             [db-secrets-policy]
   token_strictly_bind_ip     false
   token_ttl                  0s
   token_type                 default

7. Fetch the AppRole ID, replacing APPROLE_NAME:

   bao read auth/approle/role/APPROLE_NAME/role-id

   For Example:

   bao read auth/approle/role/web-app-approle/role-id

   Key        Value
   ---        -----
   role_id    1d41b8be-03d2-6f61-702d-1731c957fd13

Generate a Secret ID

8. Generate a secret ID for the role, replacing APPROLE_NAME:

   bao write -f auth/approle/role/APPROLE_NAME/secret-id

   For Example:

   bao write -f auth/approle/role/web-app-approle/secret-id

   Key                   Value
   ---                   -----
   secret_id             4eb6e604-681c-3fc3-bedd-a2dc774955bb
   secret_id_accessor    fe899dc6-85f7-f596-fb93-3c961f7919a9
   secret_id_num_uses    0
   secret_id_ttl         0s

Generate an API Token

9. Generate an API token for the AppRole, supplying the APPROLE_ID (e.g. 1d41b8be-03d2-6f61-702d-1731c957fd13) and the APPROLE_SECRET_ID (e.g. 4eb6e604-681c-3fc3-bedd-a2dc774955bb) from the previous commands:

   bao write auth/approle/login \
     role_id="APPROLE_ID" \
     secret_id="APPROLE_SECRET_ID"

   For Example:

   bao write auth/approle/login \
     role_id="1d41b8be-03d2-6f61-702d-1731c957fd13" \
     secret_id="4eb6e604-681c-3fc3-bedd-a2dc774955bb"

   Key                     Value
   ---                     -----
   token                   s.kpKsgWNtYLAktRYQT4BiMVMy
   token_accessor          Rwlq5EmvrHC8VvvHwoRyJzUh
   token_duration          768h
   token_renewable         true
   token_policies          ["db-secrets-policy" "default"]
   identity_policies       []
   policies                ["db-secrets-policy" "default"]
   token_meta_role_name    web-app-approle

   The resulting AppRole token (e.g. s.kpKsgWNtYLAktRYQT4BiMVMy) can be used by a user, machine, or service (e.g. a web application) to authenticate OpenBao API calls and read the database credential secret.

Storing Secrets

Create the secret store defined in the policy created above.

1. Enable the KV secrets engine, replacing SECRET_MOUNT_PATH:

   bao secrets enable --path=SECRET_MOUNT_PATH kv

   For Example:

   bao secrets enable --path=database-credentials kv

   Success! Enabled the kv secrets engine at: database-credentials/

2. The example secret in AWS Secrets Manager contains multiple fields formatted as a JSON object. To replicate this structure, store each field as a separate key/value pair in the SECRET_MOUNT_PATH under the secret name SECRET_NAME (e.g. psql):

   bao kv put --mount=SECRET_MOUNT_PATH SECRET_NAME \
     "SECRET_KEY_1"="SECRET_VALUE_1" \
     "SECRET_KEY_2"="SECRET_VALUE_2" \
     "SECRET_KEY_3"="SECRET_VALUE_3" \
     "SECRET_KEY_4"="SECRET_VALUE_4" \
     "SECRET_KEY_5"="SECRET_VALUE_5" \
     "SECRET_KEY_6"="SECRET_VALUE_6"

   For Example:

   bao kv put --mount=database-credentials psql \
     "username"="psqluser" \
     "password"="W0H@Z52IGI0VjqoGS3xMkJ9SO533w$fcfrmzs.vault-tokenTudDxEe\#"  \
     "engine"="postgres" \
     "host"="psql.example-cloud.com" \
     "port"="5432" \
     "dbname"="web_app_production"

   Success! Data written to: database-credentials/psql

Retrieving Secrets

1. While authenticated with the root token, retrieve the secret using the OpenBao CLI (bao), replacing SECRET_MOUNT_PATH and SECRET_NAME:

   bao kv get --mount=SECRET_MOUNT_PATH SECRET_NAME

   For Example:

   bao kv get --mount=database-credentials psql

   ====== Data ======
   Key         Value
   ---         -----
   dbname      web_app_production
   engine      postgres
   host        psql.example-cloud.com
   password    W0H@Z52IGI0VjqoGS3xMkJ9SO533w.vault-tokenTudDxEe\#
   port        5432
   username    psqluser

2. Test access using the APPROLE_TOKEN saved earlier (e.g. s.36Yb3ijEOJbifprhdEiFtPhR), your SECRET_MOUNT_PATH, and the SECRET_NAME:

   curl --header "X-Vault-Token: APPROLE_TOKEN" \
        --request GET \
        $BAO_ADDR/v1/SECRET_MOUNT_PATH/SECRET_NAME \
        | jq

   For Example:

   curl --header "X-Vault-Token: s.36Yb3ijEOJbifprhdEiFtPhR" \
        --request GET \
        $BAO_ADDR/v1/database-credentials/psql \
        | jq

   {
     "request_id": "00237a0b-4349-351d-50a0-ef127534ed18",
     "lease_id": "",
     "renewable": false,
     "lease_duration": 2764800,
     "data": {
       "dbname": "web_app_production",
       "engine": "postgres",
       "host": "psql.example-cloud.com",
       "password": "W0H@Z52IGI0VjqoGS3xMkJ9SO533w.vault-tokenTudDxEe#",
       "port": "5432",
       "username": "psqluser"
     },
     "wrap_info": null,
     "warnings": null,
     "auth": null
   }

   The AppRole token can be used by applications or services to retrieve secrets through the OpenBao API.

   Note

   According to the OpenBao API documentation, OpenBao is API-compatible with HashiCorp Vault. This means most Vault client libraries should also work with OpenBao, including:

   • Go
   • Ruby
   • C#
   • Java
   • Kotlin
   • Node.js
   • PHP
   • Python

Production Considerations

When migrating workloads from AWS Secrets Manager across providers to OpenBao on Akamai Cloud, it’s important to ensure your deployment is secure, resilient, and optimized for performance. This section covers key security and high availability considerations to help you maintain a reliable and protected secrets management system.

Security

Security should be a top priority for a production-grade OpenBao deployment. Protecting secrets from unauthorized access, ensuring secure communication, and enforcing strict access controls are essential to maintaining a secure environment.

• Access Control Policies: Use OpenBao’s policy system to enforce RBAC. Define granular policies that grant only the necessary permissions, following the principle of least privilege.
• Audit Logging: Enable detailed audit logs to track all access and modifications to secrets. OpenBao supports multiple logging backends, such as syslog and file-based logs, to help monitor suspicious activity.
• Secrets Lifecycle Management: Implement automated secrets rotation, revocation, and expiration to ensure secrets do not become stale or overexposed. Consider using dynamic secrets where possible to generate time-limited credentials.
• Securing Network Communication: Configure OpenBao to use TLS to encrypt all communications, ensuring data in transit remains secure. Regularly rotate TLS certificates to prevent expiration-related outages and reduce the risk of compromised certificates.

High Availability

Production-grade OpenBao environments should be deployed with fault tolerance and scalability in mind. OpenBao’s Autopilot mode for high availability ensures that if the active node fails, the cluster automatically elects a new leader, maintaining uptime without manual intervention. However, to enable seamless failover, organizations must configure their deployment correctly, and proactively monitor system health.

• Raft Storage Backend: Use OpenBao’s integrated storage, based on the Raft protocol, to enable distributed data replication across multiple nodes. This ensures data consistency and fault tolerance while reducing reliance on external storage backends. Configure regular Raft snapshots for disaster recovery.
• Deploy Multiple Nodes: OpenBao recommends at least five nodes for a high-availability deployment. The active node handles all requests, while standby nodes remain ready to take over in case of failure.
• Monitor Leader Status: Use bao operator raft list-peers to check the cluster’s leader and node statuses. This command helps ensure that standby nodes are correctly registered and ready for failover.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

• AWS Secrets Manager Documentation
• OpenBao Configuration Documentation
• OpenBao Integrated Storage
• OpenBao GitHub