A config registry that never stores secret values
Podifi · Software Engineer · Aug 2026 — Aug 2026
Created an authoritative workspace configuration registry that stores references to managed secrets rather than sensitive values.
Context
A workspace control plane needed tenant- and project-specific configuration, but no system owned those records. Freeform identifiers could drift from upstream catalogs, and keeping sensitive values alongside ordinary configuration would have widened the surface that had to be protected.
Decisions
Where should workspace configuration and its sensitive values be owned?
Chosen
Own configuration in a dedicated registry and keep secret values out of it entirely
Separating ordinary configuration from secret values established one auditable control surface while leaving sensitive material to the system already built to hold it.
Rejected alternatives
Hold secret values in the registry storage itself
That would duplicate ownership of sensitive material across two systems, and put it on the same paths as ordinary configuration.
Embed workspace configuration in the identity domain
Identity catalogs supply valid organization choices, but making them own workspace runtime configuration would blur separate domain responsibilities.
Outcomes
Every outcome below is shown with the evidence behind it.
| Outcome | Result | Evidence |
|---|---|---|
| Authoritative workspace configuration | Enabled catalog-backed configuration for workspace creation | The delivered registry owns static workspace configuration and validates tenant and project selection against upstream catalogs rather than accepting freeform input. |
| Secrets-by-reference boundary | Enabled configuration without persisting secret values | Configuration records carry references rather than values, so a secret never enters the registry storage at all. |
Architecture
In the operator portal, an operator selects tenant and project identities from authoritative catalogs rather than typing freeform keys, and those audited writes reach the config registry. The registry keeps workspace configuration and a reference to each secret in its own storage, which holds no secret values; the value itself is written to a separate managed secret store. A workspace control plane reads the configuration and follows the reference to that store. Configuration and secret value never share a storage boundary, which is the whole point of the design.