Tenant Secrets

Tenant Secrets

A tenant secret is a named credential stored at the tenant level, shared across all services and instances in your workspace. Unlike service secrets, which are scoped to a single service and must be recreated for each new instance, a tenant secret exists once and can be injected into any service instance through the materialize API.

Choosing between tenant secrets and service secrets? See Secrets vs Parameter Store for a decision guide.

Key namespaces

Every tenant secret key must start with either system. or user..

user.* keys are created and managed by you. You can list, read, set, and delete these keys using the /mytenantsecrets API. Use this namespace for credentials you own: API keys, tokens, or any value you want to reuse across multiple service instances without copying it separately for each one.

system.* keys are written by the Open Source Cloud platform. You cannot read or delete them directly. The platform uses this namespace for credentials it manages on your behalf, such as Git credentials used by the Agentic SDLC pipeline. You can inject a system.* key into a service instance via the materialize endpoint without the raw value ever appearing in an API response.

Managing tenant secrets via the API

All endpoints require a valid personal access token in the Authorization: Bearer <token> header.

List your tenant secrets

GET /mytenantsecrets

Returns a list of user.* key names and their metadata. The system.* keys are not included in this response.

Set a tenant secret

POST /mytenantsecrets
Content-Type: application/json

{
  "key": "user.my-api-key",
  "value": "sk-...",
  "description": "Optional description"
}

The key must match the pattern user.[A-Za-z0-9._-]+. Values are encrypted at rest. Once stored, the raw value is never returned by any API.

Delete a tenant secret

DELETE /mytenantsecrets/user.my-api-key

Permanently removes the tenant secret. Any service instances that previously had this value materialized as a service secret retain the materialized copy — they are not affected by the deletion.

Injecting a tenant secret into a service instance

Tenant secrets cannot be referenced directly in service instance parameters. To inject a tenant secret into a service instance, you first materialize it as a service secret.

POST /mytenantsecrets/user.my-api-key/materialize
Content-Type: application/json

{
  "serviceId": "eyevinn-my-service",
  "serviceSecretName": "apikey"
}

The platform copies the value server-side into a service-scoped secret named apikey for eyevinn-my-service. The API returns:

{
  "reference": "{{secrets.apikey}}"
}

Pass this reference string as the value of the corresponding parameter when creating or updating a service instance. The orchestrator resolves it to the stored value at pod-creation time.

This mechanism works for both user.* and system.* keys. For system.* keys, materialization is the only way to consume the credential — there is no read endpoint that would return the raw value.

When to use tenant secrets vs service secrets

Use tenant secrets when:

• The same credential applies to multiple services or instances (for example, a shared API key for an external provider).
• You want to manage the credential in one place and push updates to all instances by re-materializing.
• The credential is managed by the platform (system.* keys).

Use service secrets (via the UI or POST /mysecrets/:serviceId) when:

• The credential is specific to a single service instance.
• You do not plan to share it with other services.
• You are working in the dashboard UI where tenant secrets are not yet exposed as a direct configuration option.

Both types are encrypted at rest and never returned in plaintext by the API after the initial write.