Skip to main content

Treasury and Secrets

Worka uses Treasury as the system of record for sensitive values such as API keys, access tokens, registry credentials, and auto-generated infrastructure credentials.

The practical rule is simple:

people, packs, and services should work with secret references and controlled grants, not raw secret values scattered through code or configuration.

Store these things in Treasury​

Use Treasury for:

  • third-party API keys
  • OAuth access and refresh tokens
  • registry pull credentials
  • publication credentials
  • auto-generated database or infrastructure passwords
  • other high-value connection material

Do not spread those values across environment files, generated business logic, or ad hoc notes. If the platform needs a secret to operate, Treasury should be able to account for it.

What you should be able to inspect​

You should be able to inspect:

  • the name or purpose of a secret
  • which workspace or connection it belongs to
  • which pack or service is allowed to use it
  • when it was last rotated or updated

You should not need to expose the raw value in order to manage it.

Granting access​

Think of secrets in two steps:

  1. the secret exists
  2. something is allowed to use it

Those are separate decisions.

That matters because the same workspace may hold several sensitive credentials but only one pack should be allowed to use a specific one. Granular grants keep mistakes small.

Rotation​

Plan for rotation from the start.

You should be able to rotate:

  • user-provided connection credentials
  • platform publication credentials
  • auto-generated infrastructure secrets

When you rotate a secret, review:

  • which workspace connections depend on it
  • which services or packs receive it
  • whether old grants should remain in place

Rotation is only useful if you can see who will be affected.

Revocation​

When a connection is removed or a workspace no longer needs a credential, revoke its grants and review downstream impact.

Revocation should make it obvious:

  • what stopped working
  • which workflows or services will now fail
  • which secret references are now unused

That clarity makes cleanup safe instead of risky.

Operator checklist​

Review these regularly:

  • secrets with broad grants
  • secrets that have not been rotated for too long
  • credentials backing public or shared assets
  • registry and publication credentials
  • auto-generated infrastructure secrets and their consumers

If a secret matters enough to break production when mishandled, it matters enough to review on purpose.