The EWC Secret Manager is based on OpenBao and provides secret‑management capabilities within each tenancy namespace. A mount represents a secret engine enabled at a specific path, and each engine offers different functionality such as storing static secrets, generating dynamic credentials, or performing cryptographic operations.

Default Secret Engines in EWC Tenancies

Below are the default mounts typically present in an EWC Secret Manager tenancy.

1. Cubbyhole – Per‑Token Private Storage

Mount: cubbyhole_xxxxxx/ Type: Cubbyhole Purpose: Per‑token private secret storage

Cubbyhole is a private storage area tied to the lifetime of the token used to access it. Only the token that created the cubbyhole can read or write its contents.

Use cases:

• Temporary data during login flows

• One‑time secrets

• Short‑lived handshakes between systems

More details: cubbyhole
 

2. Kubernetes External Secrets Operator

Mount: kubernetes-external-secrets-operator/ Type: Kubernetes integration backend Purpose: Synchronisation of secrets into Kubernetes via ESO

This engine is used by the External Secrets Operator to fetch secrets from OpenBao and inject them into Kubernetes Secret or ConfigMap objects.

Use cases:

• Applications running in EWC Kubernetes clusters

• Automated secret delivery to workloads

• Centralised secret management for multi‑tenant clusters

More details: External Secrets Operator
 

3. KV v2 – Default Secret Engine

Mount: kv_xxxxxxx/ Type: KV v2 Purpose: Default KV v2 engine 

This is the primary KV engine for storing static secrets in the tenancy. It is typically used for:

• Passwords

• API keys

• Tokens

• LDAP info and keys

• Operational configuration

• EUMETCast keys

• Application secrets

This is the engine most users interact with when storing or retrieving secrets.