> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.ibee.co.in/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.ibee.co.in/docs/_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)