Secrets, write-only for people.
Read by workloads, with their identity.
Add a value once, with a reason; by default no person sees it again. Clusters, serverless services, devboxes and agents get it with their own identity, and every read is on the record. Rotation keeps two versions valid until every consumer has moved.
Written once. Read by identity.
Agents never hold the value.
A kind for every credential.
Frazer rotates the ones it issues.
Keys you paste in, credentials Frazer manages for its own resources, database roles made on each read, and values built from other secrets, side by side in folders.
| Kind | Written by | Rotation | Example |
|---|---|---|---|
| Opaque | People, CI or an import | On a schedule, with a reminder to the owners | STRIPE_SECRET_KEY |
| Managed | Frazer, for a Frazer resource | Frazer rotates it; two valid versions overlap | The app user of a managed Postgres, an LLM gateway key |
| Dynamic | Created on each read | A lease: 1 hour by default, 24 hours at most | A Postgres role for an analyst or an agent session |
| Derived | Frazer, from a template with references | Whenever a referenced secret changes | DATABASE_URL |
| Certificate | Frazer's certificate authority | Before it expires | mTLS client certificates |
Rotate without downtime.
Two valid versions while consumers move.
Schedule
A period of an hour or more, an overlap of 24 hours by default, and a rotator: Frazer for what it issues, or a reminder to the owners.
Add the new version
Frazer adds it for what it issues. For the rest, the owners get a reminder and someone adds the value with a reason.
Consumers move
The prod alias moves; clusters refresh, a serverless service starts a new revision, the broker hands out the new value.
Where used turns green
Every consumer shows the new version. A rotation that cannot finish keeps the old version and raises a finding.
Retire the old version
Disabled after the overlap, destroyed after 7 days. Every read stays on the record.
A value in. A reference out.
Git holds the reference, never the value.
Create the secret and add a version from the CLI, then point a cluster at its alias from your environment repository. The cluster's secret sync reads it with its own identity.
$ frazer secrets create stripe-secret-key --folder /payments \
--key STRIPE_SECRET_KEY --rotation 90d
$ printf %s "$V" | frazer secrets versions add stripe-secret-key \
--from-stdin --reason "rotated at the payments provider"
$ frazer secrets versions alias stripe-secret-key prod 7
$ frazer secrets where-used stripe-secret-key# envs/production/payments/stripe.yaml: no value in Git
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: payments-stripe
namespace: payments
spec:
secretStoreRef:
kind: ClusterSecretStore
name: frazer-secrets
target:
name: payments-stripe
data:
- secretKey: STRIPE_SECRET_KEY
remoteRef:
key: "@prod/payments/stripe-secret-key" # follows the prod aliasEverything around a secret.
Reading it back takes an explicit grant.
Folders, versions, aliases
Group by folder; pin a version or follow an alias such as
prod.Where used
Every cluster, service, box and agent that reads a secret, with the version it holds.
Rotation with overlap
Frazer rotates what it issues; two versions stay valid until every consumer moves.
Dynamic database roles
A Postgres role per read, on a lease of 1 hour by default.
History and restore
Every version with its author and reason; a disabled version can be enabled again.
Import with a dry run
From another secret manager, a password vault or a
.envfile; the source credential is deleted after.Shared between projects
One project's secret shared to chosen projects, audited in both.
Approvals and file mounts
Approvals for production edits, CSI file mounts and your own keys.
Who may do what.
Nobody reads a value back by default.
Who may do what
- Owners and admins
- Add versions, move aliases, set rotation and access. Reading a value is not part of the role.
- Developers
- Add versions in non-production; production needs an admin.
- Viewers and auditors
- See metadata: versions, authors, reasons, where used.
- Workloads
- Read only the secrets bound to them, with their own identity.
- Secret Accessor
- The one grant that lets a person read a value; no basic role includes it. Each read needs step-up 2FA and is audited, production can require an approval, and a project policy can forbid human reads.
What is logged
- Every read, as an audit entry, counted per identity and hour.
- Every version, with its author and the reason given.
- Access changes, alias moves, disables and destroys.
- Rotation reminders, also as a
secret.rotate_dueevent.
At the cap
- No fee per secret, version or read: secrets add nothing to a budget.
- Default limits: 10,000 secrets per project and 64 KiB per value.
- 100 versions kept per secret; 100 reads a second per project, bursts to 500.
No fee per secret.
Or per read.
Secrets come with every project. You pay for the servers and services that use them, never per secret, per version or per read.
See every priceSecrets, answered.
Can anyone read a secret's value?
Workloads read values with their own identity. People add versions and see metadata: the version, its author, the time and the reason. A person reads a value only with an explicit Secret Accessor grant, which no basic role includes, Owner and Admin among them. Every such read needs step-up 2FA and is audited, production can require an approval first, and a project policy can forbid all human reads.
How do my workloads get secrets?
Clusters through their secret sync, with each cluster's own identity. Serverless services through a binding, pinned per revision. Devboxes get short-lived credentials from the credential broker where it can mint them. Agents never hold a value: the egress gateway adds it for each allowed host.
What happens when I rotate a secret?
Frazer adds the new version, or reminds the owners to. The prod alias moves, clusters refresh and serverless services start a new revision, while the old version stays valid for the overlap, 24 hours by default. Where used shows when every consumer has moved; then the old version is disabled, and destroyed after 7 days.
Where are values stored?
In Frazer Secrets, run by Frazer in each region outside your clusters, with a namespace per project. Snapshots are taken every 5 minutes and copied off-site. No other cloud's secret manager sits behind it.
Can I bring secrets from my current secret manager?
Yes, from Google Secret Manager, AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, 1Password, Doppler, Infisical or a .env file. Every import runs a dry run first, verifies checksums and never logs a value; the import credential is deleted when the import closes.
Can agents read secrets?
No. An agent's sandbox never holds a value; the egress gateway adds the credential for each allowed host. The secrets tools agents use show metadata only.