Migrate From GCP Secret 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.

Google Cloud Platform (GCP) Secret Manager is a managed secrets service that securely stores sensitive data like API keys, passwords, and certificates. It integrates with other GCP services and simplifies access control through Identity and Access Management (IAM).

This guide provides steps and considerations for how to migrate secrets stored in GCP Secret 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. When migrating from GCP Secret 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

3. Ensure that you have access to your GCP account with sufficient permissions to work with GCP Secret Manager. The gcloud CLI must also be installed and configured.

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

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 GCP Secret Manager

Before migrating to OpenBao, evaluate how your organization currently uses GCP Secret Manager.

For example, a web application might verify the signature of a JSON Web Token (JWT) using a secret key stored in GCP Secret Manager. Instead of embedding the secret in source code or container images, the application is granted a role that allows it to retrieve the secret at runtime. This protects the secret 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 GCP Console

1. Navigate to Security > Secret Manager to list secrets. The example secrets below are used throughout this guide:

2. To display a secret’s value, select the secret, open the latest version, and click Actions > View secret value:

Review Secrets Using the gcloud CLI

You can also use the gcloud CLI to authenticate and inspect the secrets stored in GCP Secret Manager.

1. Authenticate with the CLI:

   gcloud auth login

2. Set the active project, replacing GCP_PROJECT_ID (e.g. ecommerce-application-454116) with your actual project ID:

   gcloud config set project GCP_PROJECT_ID

   For Example:

   gcloud config set project ecommerce-application-454116

3. List all secrets:

   gcloud secrets list

   NAME                       CREATED              REPLICATION_POLICY  LOCATIONS
   billing_service_API_key    2025-03-01T12:25:36  automatic           -
   deploy_key                 2025-02-28T04:04:58  automatic           -
   inventory_service_API_key  2024-11-15T16:35:35  automatic           -
   jwt-signing-secret         2025-03-08T12:01:30  automatic           -
   slack_webhook_url          2024-11-19T21:19:15  automatic           -

4. Retrieve the latest version of a secret, replacing GCP_SECRET_NAME (e.g. jwt-signing-secret) with an actual secret name:

   gcloud secrets versions access latest --secret=GCP_SECRET_NAME

   For Example:

   gcloud secrets versions access latest --secret=jwt-signing-secret

   EU&&7O^#c2GAMIdRyJlZkPEdoWKgy%CW

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

To replicate GCP IAM-style access control, OpenBao provides AppRoles. For example, in GCP, a service might be granted a role like JWTSigner to retrieve a secret. In OpenBao, this same functionality is implemented using a policy-bound AppRole.

Follow these steps to create an OpenBao AppRole that mimics the role-based access used in GCP IAM.

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. jwt-secrets-policy.hcl) with a policy filename of your choosing:

   sudo nano /etc/openbao/POLICY_FILE

   For Example:

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

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

   File: POLICY_FILE.hcl

   1 2 3

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

   For Example:

   File: jwt-secrets-policy.hcl

   1 2 3

   path "jwt/*" { 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. jwt-secrets-policy) and POLICY_FILE:

   bao policy write POLICY_NAME /etc/openbao/POLICY_FILE

   For Example:

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

   Success! Uploaded policy: jwt-secrets-policy

Create an AppRole

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

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

   For Example:

   bao write \
     auth/approle/role/app-authenticator-approle \
     token_policies=jwt-secrets-policy

   Success! Data written to: auth/approle/role/app-authenticator-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/app-authenticator-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             [jwt-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

   Key        Value
   ---        -----
   role_id    019e2cc5-b8ce-4aa4-91b9-c2c9e9e59863

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/app-authenticator-approle/secret-id

   Key                   Value
   ---                   -----
   secret_id             cef786fb-1d1c-4c52-9466-aea47b3c8d3a
   secret_id_accessor    373500ba-6922-4f91-b7f3-ec25f8253d1d
   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. 019e2cc5-b8ce-4aa4-91b9-c2c9e9e59863) and APPROLE_SECRET_ID (e.g. cef786fb-1d1c-4c52-9466-aea47b3c8d3a) 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="019e2cc5-b8ce-4aa4-91b9-c2c9e9e59863" \
     secret_id="cef786fb-1d1c-4c52-9466-aea47b3c8d3a"

   Key                     Value
   ---                     -----
   token                   s.dy572yUtTNvHTZgIoxdNVO41
   token_accessor          zT1TP281vORYSjysBiuMydht
   token_duration          768h
   token_renewable         true
   token_policies          ["jwt-secrets-policy" "default"]
   identity_policies       []
   policies                ["jwt-secrets-policy" "default"]
   token_meta_role_name    app-authenticator-approle

   The resulting AppRole token (e.g. s.dy572yUtTNvHTZgIoxdNVO41) can be used by a user, machine, or service (e.g. the authentication API for a web application) to authenticate OpenBao API calls and read the JWT signing 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=jwt kv

   Success! Enabled the kv secrets engine at: jwt/

2. The GCP example secret contains a single sensitive value. Store this value in the SECRET_MOUNT_PATH using a SECRET_KEY (e.g. secret) and assign it a SECRET_NAME (e.g. signer):

   bao kv put --mount=SECRET_MOUNT_PATH SECRET_NAME \
     "SECRET_KEY"="SECRET_VALUE"

   For Example:

   bao kv put --mount=jwt signer \
     "secret"="EU&&7O^#c2GAMIdRyJlZkPEdoWKgy%CW"

   Success! Data written to: jwt/signer

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=jwt signer

   ====== Data ======
   Key         Value
   ---         -----
   secret      EU&&7O^#c2GAMIdRyJlZkPEdoWKgy%CW

2. Test access using the APPROLE_TOKEN (e.g. s.dy572yUtTNvHTZgIoxdNVO41) saved earlier, 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.dy572yUtTNvHTZgIoxdNVO41" \
        --request GET \
        $BAO_ADDR/v1/jwt/signer \
        | jq

   {
     "request_id": "0e70b929-06b6-4685-b787-dc1ce6c31b9b",
     "lease_id": "",
     "renewable": false,
     "lease_duration": 2764800,
     "data": {
       "secret": "EU&&7O^#c2GAMIdRyJlZkPEdoWKgy%CW"
     },
     "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 GCP Secret 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 only grant 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.

• Google Cloud Secret Manager Documentation
• gcloud secrets documentation
• OpenBao Configuration Documentation
• OpenBao Integrated Storage
• OpenBao GitHub