---
slug: /myaccount/e2esecrets/
title: E2E Secrets Management
---

# 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.
<br/>

| Attribute | Example |
|-----------|---------|
| Vault Endpoint URL | `https://openbao-<ID>.e2enetworks.net` |
| Root Token | `s.XXXXXXXXXXXXXXXX` |

:::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.** 
:::

## 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

    :::tip 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.
:::

## 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](#cli-access)
2. **Programmatic Access** - If you want to access using Programmatic methods, [click here](#programmatic-access-for-applications)

## 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](https://openbao.org/docs/install/).

Refer to the official [bao CLI documentation](https://openbao.org/docs/commands/) for a complete list of available commands and usage examples.

### Environment Setup

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

```bash
export VAULT_ADDR="https://openbao-<ID>.e2enetworks.net"
export VAULT_TOKEN="YOUR_ROOT_TOKEN"
```
Verify login: 
 ```
 bao login $VAULT_TOKEN
 ```

Check authentication:

```bash
bao token lookup
```

## 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](https://openbao.org/docs/secrets/).

### Check Enabled Engines

```bash
bao secrets list
```

### 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):

```bash
bao secrets enable -path=secret kv-v2
```

#### Write a Secret

```bash
bao kv put secret/app key="value123"
```

#### Read a Secret

```bash
bao kv get secret/app
```

#### Update a Secret

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

#### List Secrets Under a Location

```bash
bao kv list secret/
```

#### Soft Delete (Latest Version Only)

```bash
bao kv delete secret/app
```

#### Permanently Delete Metadata and All Versions

```bash
bao kv metadata delete secret/app
```

## Token & Access Management

### Create a New Token for Apps

```bash
bao token create -ttl=24h
```

### Revoke a Token

```bash
bao token revoke <token>
```

## Role-Based Access Control (RBAC)

Policies restrict what a token can access. The root token has unrestricted access and should only be used for initial setup. For applications, create dedicated tokens with narrowly scoped policies to limit blast radius if a token is compromised.

### Create a Policy File

Example: allow read-only access to a path

Create a file named `policy.hcl`:

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

### Load Policy

```bash
bao policy write readonly policy.hcl
```

### List Policies

```bash
bao policy list
```

### Issue a Token with That Policy

```bash
bao token create -policy=readonly
```

## Monitoring 

### Checking Cluster Status

```bash
bao status
```

Common states:
- unsealed
- standby
- leader

:::info
**E2E Secrets Management is deployed in a high-availability configuration with 3 replicas. Your secret store is ready to use as soon as you receive your credentials.**
:::

### Last Token Usage Details

```bash
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

```bash
pip install hvac
```

#### A. Basic Connection and Secret Operations

```python
#!/usr/bin/env python3
import os
import hvac

client = hvac.Client(
    url=os.environ["VAULT_ADDR"],
    token=os.environ["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, and delete operations.

```python
#!/usr/bin/env python3
import os
import hvac

client = hvac.Client(
    url=os.environ["VAULT_ADDR"],
    token=os.environ["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

## 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


---