Secrets
Store a credential once as a project secret, shared with everyone on the project. Scope it to just yourself when you need to, and Tektona keeps it encrypted and out of your sandboxes.
A Secret is a stored value: a key (e.g. anthropic), the secret itself,
and where it lives. That's all it is. Secrets don't know where they're used. An
Egress Proxy Profile is what injects a secret into your sandboxes'
traffic, and git credentials have their own flow. This page
is just the vault. For how the whole model fits together, and why the value never
enters the sandbox, see how egress injection works.
The value lives only in the Secret. Everything that uses it references it by key, so you rotate a value in one place. A teammate can drop in their own personal value that quietly overrides the shared one for their own sandboxes, everywhere it's used.
Store a secret
A secret is a project secret by default. It lives in a project and is shared
with everyone on the project. You add and manage it on the project's
Secrets page. A secret is just a key (e.g. anthropic) and a value.
Values are write-only: once saved, no page or API call shows the secret
again. To change one, save a new value over it.
Scope a secret to just you
On the project's Secrets page you can optionally set a secret to Personal instead of leaving it shared. A personal secret is visible only to you and used only by sandboxes you own, and it overrides the shared project value for those sandboxes. Use it for your own key or quota when you don't want to put it in front of the whole project. The Project / Personal filter lets you switch between the shared values and the ones scoped to you.
Organization secrets
Organization secrets are a separate, org-wide concept. You manage them on the organization's Secrets page (org settings), and they are shared across every project in the org. An org secret acts as the cross-project fallback. A project or personal value for the same key takes precedence where one exists.
| Where it lives | Managed on | Who can see/use it | Typical use |
|---|---|---|---|
| Project (shared) | project → Secrets | everyone on the project | a project-specific key |
| Project, scoped to you | project → Secrets (Personal) | only sandboxes you own, in that project | your own key / quota |
| Organization | org → Secrets | every project in the org | a shared team key |
A personal value overrides the shared one
When something resolves the anthropic secret for a sandbox, Tektona picks the
most specific value for the sandbox's owner: a personal value first, then the
shared project value, then the organization fallback. So an org can
publish a shared key, and any user who scopes their own anthropic value to
themselves has it used automatically for their sandboxes, wherever anthropic is
referenced, with no extra configuration.
Ownership transfer rebinds personally scoped values
Because a personal value resolves against the sandbox owner, transferring a
sandbox re-binds any ${secret:...} reference (including those in an attached
egress proxy profile) to the new owner. If the new
owner has no personal value for a referenced key, and no shared project or org
value covers it, resolution fails closed rather than reusing the previous
owner's value. Transfer should therefore warn or block when a required personal
value isn't present for the new owner. (Design item to confirm.) Deleting a
secret that a profile references is the same fail-closed case. The reference
stops resolving and the call fails rather than going out without the credential.
Security
- Values never enter the sandbox when injected at the network edge (the default). They're fetched just-in-time, held briefly, and never stored on the sandbox's disk.
- Write-only. Never shown again after you save them.
- The org never sees plaintext on upload. The value is encrypted in your browser/CLI before it's sent.
- Rotate or revoke instantly. Change or delete a secret and in-flight caches drop it within seconds. Deletes are cryptographically shredded.
- Removed with your access. Personally scoped values are deleted when you leave the project (or the org), so a value never outlives your access.
Injection terminates TLS at the egress boundary, so the sandbox trusts a Tektona
CA for the injected hosts. Most tools pick this up automatically from the
system trust store and the standard CA-bundle environment variables. Tools with
their own trust store (e.g. Java's keytool) can import it with tektonactl ca cert,
which prints the current CA as PEM.