--- title: "Secrets: write-only for people, read by workloads · Frazer" description: "Secrets with folders, versions, aliases and rotation. People add values with a reason and read them back only with an explicit grant; clusters, services, devboxes and agents get them with their own identity, and every read is audited." url: https://frazer.ai/secrets index: https://frazer.ai/llms.txt tokens: 2398 --- > For agents: every page on frazer.ai is indexed at https://frazer.ai/llms.txt. # Secrets: write-only for people, read by workloads · Frazer **Secrets** frazer.ai # 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. [Add a secret](https://frazer.ai/start?product=secrets) [Read the docs](https://frazer.ai/docs) *The page of the demo secret STRIPE_SECRET_KEY in project acme-production: an opaque secret in folder /payments, current version v7 with the alias prod, rotated every 90 days, readable by workloads only. Its versions list authors and reasons but never values; 3 consumers use it: a cluster through its secret sync, a serverless service pinned to a revision, and an agent whose credential is added at the egress gateway. Recent activity shows each read and change with its audit permission.* One secret: its versions, where it is used and who read it product UI, demo organization 01 · How it works Fig. 1 ## Written once. Read by identity. Agents never hold the value. **Fig. 1** One value, from the person who adds it to the workloads that read it 02 · Kinds of secret Fig. 2 ## 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. *The Secrets list of the demo project acme-production: 10 secrets in 4 folders, of 4 kinds (opaque, derived, managed, dynamic), each with its version or lease, its rotation, its consumers and its last read. A strip says 2 rotations are due within 14 days, 1 consumer is still on an old version, and no values are in Git.* **Fig. 2** A project's secrets, by folder and kind product UI, demo organization Kinds of secret: who writes each, how it rotates, and an example | 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 | 03 · Rotation ## Rotate without downtime. Two valid versions while consumers move. 1. ### 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. 2. ### 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. 3. ### Consumers move The prod alias moves; clusters refresh, a serverless service starts a new revision, the broker hands out the new value. 4. ### Where used turns green Every consumer shows the new version. A rotation that cannot finish keeps the old version and raises a finding. 5. ### Retire the old version Disabled after the overlap, destroyed after 7 days. Every read stays on the record. 04 · From the CLI or from Git ## 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 alias ``` 05 · What you get ## Everything 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 `.env` file; 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. 06 · Controls ## 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_due` event. ### 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. 07 · Pricing ## 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 price](https://frazer.ai/pricing#lines) Your servers No per-secret or per-access fee Frazer fleet No per-secret or per-access fee Versions No per-version fee Imports No Frazer fee; the source bills its own egress, shown in the dry run Questions ## Secrets, 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. ## More in Data - [**Databases** Postgres with PITR](https://frazer.ai/databases) - [**In-memory store** Pick the engine and version](https://frazer.ai/memory) - [**Frazer Storage** Objects next to servers](https://frazer.ai/storage) - [**Volumes and snapshots** NVMe or replicated](https://frazer.ai/volumes) ## Add a secret once. Let workloads read it. [Add a secret](https://frazer.ai/start?product=secrets) [Read the docs](https://frazer.ai/docs)