Tools

Secret Manager

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

ConceptDescription
StoreA container for related secrets and the identities that can use them. Its store key is auto-generated from the name.
SecretA named set of key/value entries (e.g. API_KEY, DB_PASSWORD) inside a store. Updates create new versions.
AccessA 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)

Create a store

1

Open Secret Manager

In the portal sidebar, click Secret Manager under Tools.

2

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:

ActionWhat it does
ViewReveals the current version’s key/values as JSON, with Copy JSON
UpdateEdit the key/values and Save new version — the previous version is kept
HistoryLists every version with its state; Rollback restores an older version
DeleteRemoves 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:

ResourceSupported operations
StoresCreate, list, get, update, archive, unarchive, and permanently delete
SecretsCreate individually or in a batch, list metadata, get metadata, read the current value, replace or patch the value, and soft-delete
VersionsList version metadata, read one version, roll back, undelete versions, and irreversibly destroy selected versions
Application identitiesCreate AppRole or Kubernetes identities; list, get, update, disable, enable, revoke sessions, and delete
Access scopesList, add, update, and delete store-specific permissions for an identity
CleanupPermanently delete a secret, then permanently delete its store

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.

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

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:

FieldOptions
Access methodAppRole (VMs, servers, scripts) or Kubernetes (pods, service accounts)
Access namee.g. payments-api
PermissionRead only or Read & write
Kubernetes namespace / Service accountRequired 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.

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