> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.ibee.co.in/docs/tools/secret-manager/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.co.in/_mcp/server.

# Secret Manager

> Store API keys, passwords, and other sensitive values in IBEE Solutions Secret Manager — versioned secrets grouped in stores, with AppRole and Kubernetes access for your apps.

Secret Manager keeps sensitive values — API keys, database passwords, tokens — out of your code and config files. Secrets live in **stores**, every update creates a new **version** you can roll back to, and applications read secrets through scoped **access identities** instead of sharing human credentials.

## Concepts

| Concept    | Description                                                                                                                                                          |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Store**  | A container for related secrets and the identities that can use them. Its **store key** is auto-generated from the name.                                             |
| **Secret** | A named set of key/value entries (e.g. `API_KEY`, `DB_PASSWORD`) inside a store. Updates create new versions.                                                        |
| **Access** | A machine identity — **AppRole** for VMs, servers, and scripts, or **Kubernetes** for pods and service accounts — with **Read only** or **Read & write** permission. |

## Before you begin

* A verified IBEE Solutions organization — Secret Manager actions require identity verification ([Verify your identity](/docs/getting-started/account-setup/verify-account))

## Create a store

### Open Secret Manager

In the portal sidebar, click **Secret Manager** under **Tools**.

### Create the store

Click **Create Store** and fill in:

* **Store name** — e.g. `Payments`. The store key is auto-generated from the name.
* **Description** — optional.

The store appears in the list with its name, store key, status, and last-updated time. Click it to open the detail view with two tabs: **Secrets** and **Access**.

## Create a secret

On the store's **Secrets** tab, click **Create Secret**:

* **Secret name** — lowercase, e.g. `stripe-api`.
* **Keys and values** — one or more entries (e.g. `API_KEY` = `sk_live_...`). Click **+ Add another key** for more.

Row actions on each secret:

| Action      | What it does                                                                |
| ----------- | --------------------------------------------------------------------------- |
| **View**    | Reveals the current version's key/values as JSON, with **Copy JSON**        |
| **Update**  | Edit the key/values and **Save new version** — the previous version is kept |
| **History** | Lists every version with its state; **Rollback** restores an older version  |
| **Delete**  | Removes the secret (confirmation required)                                  |

## API and SDK lifecycle

Every API, SDK, and CLI request must use the same `workspace_id` that owns the store and secret. A secret ID is not globally accessible: using an ID with another workspace correctly returns `403 FORBIDDEN` with a message that the secret does not belong to that workspace.

The public lifecycle includes:

| Resource                   | Supported operations                                                                                                                |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Stores**                 | Create, list, get, update, archive, unarchive, and permanently delete                                                               |
| **Secrets**                | Create individually or in a batch, list metadata, get metadata, read the current value, replace or patch the value, and soft-delete |
| **Versions**               | List version metadata, read one version, roll back, undelete versions, and irreversibly destroy selected versions                   |
| **Application identities** | Create AppRole or Kubernetes identities; list, get, update, disable, enable, revoke sessions, and delete                            |
| **Access scopes**          | List, add, update, and delete store-specific permissions for an identity                                                            |
| **Cleanup**                | Permanently delete a secret, then permanently delete its store                                                                      |

> **Info**
>
> List and metadata operations never include secret values. Use the dedicated **Get secret value** or **Get secret version** operation when your token has `secret-store.read` scope.

> **Warning**
>
> Destroying versions, permanently deleting a secret, and permanently deleting a store cannot be undone. The CLI requires explicit confirmation for these commands.

> **Warning**
>
> **Get application identity access details** generates a fresh AppRole `secret_id` for AppRole identities. Treat it like a password and do not log it. Kubernetes identities return their role, namespace, and service-account binding instead.

The application runtime login and scoped secret-read endpoints use the short-lived Secret Store session token issued to an AppRole or Kubernetes workload. That session token is separate from the platform API token used by the control-plane operations above.

## Grant application access

On the store's **Access** tab, click **Create Access**:

| Field                                      | Options                                                                        |
| ------------------------------------------ | ------------------------------------------------------------------------------ |
| **Access method**                          | **AppRole** (VMs, servers, scripts) or **Kubernetes** (pods, service accounts) |
| **Access name**                            | e.g. `payments-api`                                                            |
| **Permission**                             | **Read only** or **Read & write**                                              |
| **Kubernetes namespace / Service account** | Required for the Kubernetes method                                             |

After creation, use the row actions:

* **Login Details** — shows the credentials your app authenticates with (Role ID and Secret ID for AppRole; namespace and service account for Kubernetes). From here you can **Rotate secret ID** (AppRole) or **Revoke sessions**.
* **Permissions** — grant the identity access to additional stores, and optionally allow reading older versions, rolling back, or destroying versions (write permission required for the last two).
* **Disable / Enable** — temporarily block an identity without deleting it.

## Archive, restore, and delete a store

From the store detail **Actions** menu:

* **Archive** blocks all access to the store until you **Restore** it.
* **Delete** permanently removes the store, its secrets, and its access entries. This cannot be undone.

> **Warning**
>
> Deleting a store deletes every secret and access identity inside it. Archive instead if you might need the store again.

## Related pages

* [API tokens](/docs/tools/api-tokens)
* [Team members & access roles](/docs/platform-fundamentals/iam)
* [Secret Store API reference](/docs/api-reference/secret-store)

> Store API keys, passwords, and other sensitive values in IBEE Solutions Secret Manager — versioned secrets grouped in stores, with AppRole and Kubernetes access for your apps.