E2E Secrets Management

E2E Secrets Management provides a secure, dedicated secret store instance per customer team or application. All sensitive data is encrypted at rest and in transit. The system ensures safe lifecycle management of critical secrets including API keys, passwords, database credentials, certificates, and encryption keys.

Users interact with E2E Secrets using a Vault-compatible CLI and client libraries. The platform abstracts cluster infrastructure, high-availability configuration, automated replication, and upgrades while providing customers complete control over their own secret paths.

Provisioning & Accessing Your Secret Store

Creating a Secret Store

Follow these steps to create your secret store:

• Log in to the E2E Cloud Console
• Go to Secrets Management
• Click Create New Secret
• Select a plan and Click on Create Secret
• You will receive an email with the details of your secrets.

Attribute	Example
Vault Endpoint URL	https://openbao-<ID>.e2enetworks.net
Root Token	s.XXXXXXXXXXXXXXXX
Unseal Keys	Sent via mail

info

Store these credentials securely. The vault credentials will be sent to your email, and the credential link will expire within 7 days. Please ensure you save the credentials for future use.

Accessing Your Secret Store

There are two ways to access the Secret Management:

1. CLI Access - If you want to access using CLI, click here
2. Programmatic Access - If you want to access using Programmatic methods, click here

CLI Access

Before using the CLI, you need to install the bao CLI tool.

Installing bao

You can refer to these docs for installing OpenBao: official OpenBao installation guide.

Refer to the official bao CLI documentation for a complete list of available commands and usage examples.

info

Secrets are accessible only when a node is unsealed. A sealed node cannot decrypt or serve any secret.

Environment Setup

Set up your environment variables to connect to your secret store:

export VAULT_ADDR="https://openbao-<ID>.e2enetworks.net"
export VAULT_TOKEN="YOUR_ROOT_TOKEN"

Verify login:

bao login $VAULT_TOKEN

Check authentication:

bao token lookup

Operational Requirements

Checking Status

bao status

Common states:

• sealed
• unsealed
• standby
• leader

Unseal (General)

Unseal keys are provided once to the admin on instance creation. Each node must reach the unseal threshold:

bao operator unseal <UNSEAL_KEY_1>
bao operator unseal <UNSEAL_KEY_2>
bao operator unseal <UNSEAL_KEY_3>

Check status again:

bao status

info

We deploy the Secrets Manager in 3 replicas for high availability.Each replica acts as a separate node in the cluster, and each node must be unsealed individually using the same set of unseal keys until it meets the unseal threshold. Only after all replicas are unsealed does the cluster become fully operational.

warning

Keep all unseal keys offline, encrypted, and securely backed up.Losing these keys means you cannot unseal the cluster again.

Secrets Engine

Secrets engines are components that store, generate, or encrypt data. They function as pluggable backends that perform specific operations on data and return results. Secrets engines are enabled at defined paths and behave like a virtual filesystem, supporting standard operations such as read, write, and delete.

E2E Secrets Management supports multiple secrets engines. Among all available secrets engines, the KV (Key-Value) secrets engine is the most popular and widely used for storing static secrets. Below, we provide examples of how to enable and use the KV secrets engine.

For more information, refer to the Secret Engines documentation.

KV Secrets Engine

The KV (Key-Value) secrets engine is used to store arbitrary secrets within the configured physical storage for your secret store.

Enable KV v2 Engine

Enable KV v2 engine at required path (optional if already enabled):

bao secrets enable -path=secret kv-v2

Write a Secret

bao kv put secret/app key="value123"

Read a Secret

bao kv get secret/app

Update a Secret

bao kv put secret/app key="updated-value"

List Secrets Under a Location

bao kv list secret/

Soft Delete (Latest Version Only)

bao kv delete secret/app

Permanently Delete Metadata and All Versions

bao kv metadata delete secret/app

Check Enabled Engines

bao secrets list

Token & Access Management

Create a New Token for Apps

bao token create -ttl=24h

Revoke a Token

bao token revoke <token>

Role-Based Access Control (RBAC)

Policies restrict what a token can access.

Create a Policy File

Example: allow read-only access to a path

Create a file named policy.hcl:

path "secret/data/app*" {
    capabilities = ["read", "list"]
}

Load Policy

bao policy write readonly policy.hcl

List Policies

bao policy list

Issue a Token with That Policy

bao token create -policy=readonly

Monitoring and Audits

List Active Audit Devices

bao audit list

Last Token Usage Details

bao token lookup <token>

Audit logs are retained securely within platform infrastructure.

Programmatic Access for Applications

Overview

E2E Secrets Management is fully compatible with Vault client APIs. Users can securely access and manage secrets from applications using widely adopted, production-grade libraries.

Recommended Client Libraries

Language	Library	Notes
Python	HVAC	Lightweight and feature-rich KV v2/Token/RBAC support
Java	vault-java-driver	Strong integration for enterprise applications
Go	Official Vault API SDK	Preferred for cloud-native workloads
Node.js	node-vault	Fast and easy integration in JavaScript runtimes

All libraries require:

• Your E2E Vault Endpoint (VAULT_ADDR)
• A valid access token (VAULT_TOKEN)

Python Integration (Recommended)

Below are fully-tested example workflows using the HVAC library.

Install HVAC

pip install hvac

A. Basic Connection and Secret Operations

#!/usr/bin/env python3
import hvac

client = hvac.Client(
    url="VAULT_ADDR",
    token="VAULT_TOKEN"
)

print("Authenticated:", client.is_authenticated())

client.secrets.kv.v2.create_or_update_secret(
    mount_point="secret",
    path="app",
    secret={"db_password": "StrongP@ss"}
)

data = client.secrets.kv.v2.read_secret_version(
    mount_point="secret",
    path="app"
)

print("Secret:", data["data"]["data"])

B. Complete Secret Lifecycle Example

This example includes: enabling engine, write, read, update, delete, and engine list operations.

#!/usr/bin/env python3
import hvac

client = hvac.Client(
    url="VAULT_ADDR",
    token="VAULT_TOKEN"
)

print("Authenticated:", client.is_authenticated())

# 1. Enable KV v2
try:
    client.sys.enable_secrets_engine(
        backend_type="kv",
        path="secret1",
        options={"version": "2"}
    )
    print("KV v2 enabled at 'secret1/'")
except Exception:
    print("KV v2 already enabled or access denied")

# 2. Write
client.secrets.kv.v2.create_or_update_secret(
    mount_point="secret1",
    path="demo",
    secret={"key": "value123"}
)
print("Write success")

# 3. Read
secret = client.secrets.kv.v2.read_secret_version(
    mount_point="secret1",
    path="demo"
)
print("Read:", secret["data"]["data"])

# 4. Update
client.secrets.kv.v2.create_or_update_secret(
    mount_point="secret1",
    path="demo",
    secret={"key": "updated-value"}
)
print("Update success")

# 5. Soft delete
client.secrets.kv.v2.delete_latest_version_of_secret(
    mount_point="secret1",
    path="demo"
)
print("Soft delete success")

This represents the complete end-to-end lifecycle for KV v2 secrets.

Integration Notes

• mount_point refers to the secrets engine path assigned to your instance
• Application tokens should be created using RBAC and scoped permissions (not root token)
• Secrets should be rotated with operational frequency policies

Secret Store Lifecycle

Upgrading Capacity

1. Click the Upgrade icon next to the secret you wish to upgrade

2. Click Upgrade

3. Choose a desired plan and click the Upgrade Secrets button

4. Your secret will be successfully upgraded

   Notes

   Upgrades do not affect stored secrets.

Deleting a Secret Store

1. Click the Delete icon for the secret you want to remove.
2. Confirm the action by clicking the Delete button.

warning

This is irreversible and permanently deletes all secrets.

Best Practices

• Create separate tokens per environment
• Enforce TTLs on all application tokens
• Regularly rotate secrets stored under paths
• Use policies instead of sharing root-token
• Limit access to metadata deletion operations
• Always secure unseal keys offline