Secrets security and limits
Every secret read names a site, an optional app, a key, and a caller. TaruviBase uses these, together with the secret's sensitivity level, to find the secret and decide whether the caller can read its value.
Access model
Read access depends on the caller, the endpoint, and the secret type's sensitivity level. The read endpoints do not all behave the same way, and they signal a denial differently — a single‑secret read returns a status code, while a batch read omits denied keys.
Who the caller is
- Unauthenticated — a request with no credential.
- Site user — a user signed in to the site with a JWT or session; most application end users. See Authentication and authorization for how callers authenticate.
- API key or cloud user — an API key, or a member of your organization signed in to TaruviBase; used for server-to-server and administrative access.
Single‑secret read — GET /api/secrets/{key}/
Returns the value, or a status code on denial:
| Caller | public | private | sensitive |
|---|---|---|---|
| Unauthenticated | 200 value | 401 | 401 |
| Site user | 200 value | 200 value | 403 |
| System token or cloud caller | 200 value | 200 value | 200 value |
A tags filter that matches none of the secret's tags, or a missing key,
returns 404.
Batch read — GET /api/secrets/?keys=
Returns 200 with the secrets the caller may read; a key the caller may not
read, or that does not exist, is omitted from the response rather than
returning 403. An unauthenticated batch returns only public keys and omits
the rest, and returns 401 only when none of the requested keys are readable. A
site user receives public and private keys with sensitive keys omitted;
a system token or cloud caller receives every requested key that exists.
List — GET /api/secrets/ (no keys)
Requires authentication; an unauthenticated caller is rejected rather than
served public values. A site user sees public and private secrets with
sensitive excluded; a system token or cloud caller sees all.
History — GET /api/secrets/{key}/history/
Requires sign-in; a site user is denied a
sensitive secret's history.
An accepted credential does not by itself prove authorization. Confirm the
allowed and denied cases for your caller and endpoint before you rely on
private or sensitive access.
Write authorization
You create, update, and delete secrets in TaruviBase Console; the SDKs are read-only. Any signed-in user with access to the site can create, update, or delete secrets — not only administrators — so be careful who you give site access to.
App roles don't restrict who can manage secrets; site access does.
How values are resolved and cached
Single and batch reads decrypt the value first, then check whether the caller may see it. If your own policy requires that a value is never decrypted before that check, don't rely on these reads.
Resolved values, including secret values, are cached for up to one hour. The cache is shared by all callers of the same site, scope, and key. Saving or deleting a secret clears the cache, but don't assume every permission change takes effect immediately.
Scope every operation
In Console, the page you open sets the scope:
- the site selected in Console;
- site Secrets, or Operate → Secrets inside one app;
- the key that names the secret;
- the signed-in caller; and
- the sensitivity level, inherited from the secret type.
A key locates a secret within its scope. Read access is decided separately from the key by the caller and the sensitivity level.
Encryption at rest
The sensitivity level chosen on the secret type controls storage:
- a
publicvalue is stored in a plaintext field; - a
privateorsensitivevalue is stored in an encrypted database field.
TaruviBase reads and writes the field that matches the type's sensitivity level and clears the other field on write. Because the level is fixed at type creation, a value's storage field does not change for the life of the type.
TaruviBase manages the encryption keys; you don't need to configure them.
Tenancy
Secrets are stored per site. The request hostname selects the site, and a request resolves only secrets within that site. Do not treat possession of a key name as authority to read its value across scopes. Report any result that returns a secret from an unexpected site or app as a security issue.
Immutable and protected fields
- A secret type's sensitivity level cannot change after creation.
- A secret type's classification (
systemorcustom) cannot change after creation. - A
systemsecret type cannot be deleted. - A secret type in use cannot be deleted until the secrets that reference it are removed.
Protect destructive changes
Deleting a secret removes it from its scope.
Deletion removes the secret from its site or app scope. The value is not recorded in history, so it cannot be recovered from the audit trail after deletion.
Before you delete a secret:
- Confirm the affected resource: the site, the app scope, and the exact key. Deleting a site secret affects every app that resolves that key; deleting an app secret affects only that app.
- Treat the operation as irreversible; the value cannot be restored from history.
- Any signed-in user with site access can delete secrets, so make sure you are the right person to do it.
- Record the current value in your own approved secret store first if you may need to restore it.
- Confirm the key from the same site/app Secrets page, then choose Delete.
- In Delete Secret, choose Delete, then use Refresh and verify the key is absent.
- Recreate the secret from your own approved store if recovery is required; TaruviBase does not retain the deleted value.
Sensitive information
Do not place credentials, personal data, or infrastructure details in URLs, examples, screenshots, or logs.
Console masks values in cards and detail views initially, but the detail dialog offers Show, Copy, and Copy all values, which reveal the real value. Check the site, app, and key first, avoid screen sharing, and never paste copied values into chat, tickets, or logs.
Limits
TaruviBase applies these limits:
| Limit | Value |
|---|---|
| Secret key | Up to 255 characters at the API schema and model layer; Console input is narrower |
| Secret-type name length | 100 characters |
| Batch retrieval keys | 100 per request |
| Secret list page size | Clamped to 100 maximum; 20 default |
| History page size | 1–100, 10 default |
A secret value has no separate size limit, but a request body larger than about 2.5 MB is rejected. Secrets has no specific rate limit. If a request is rejected for size or volume, reduce it and try again.
Keep in mind
- Never print secret values in logs.
- Store credentials as secrets, not as ordinary site settings.
- A deleted secret can't be recovered, so keep a copy of any value you may need.