Secrets management
Security
Sensitive app configuration, integration credentials, signing keys, and app environment variable values sit in the customer’s Key Vault. The Greenlight control plane stores references and metadata needed to bind them to apps, but never the values themselves.
What’s on disk on the control plane, in a database backup, in an exfiltrated control-plane dump? A reference, not a secret.
Where things live
| Material | Where it lives | What the control plane knows |
|---|---|---|
| Integration credentials | Key Vault | Reference + which apps are granted |
| App env vars, plain and sensitive | Key Vault, injected into app pods through the app’s Kubernetes Secret | Reference + variable name + sensitivity flag |
| Workload identity | Cluster identity service, never persisted | The mapping from workload to app |
| End-user passwords | Customer’s IdP | Nothing |
| Upstream user tokens | In-memory at the broker during a request | Nothing after the request completes |
| Audit log records | Control plane database | The structured event (not request bodies) |
Plain env vars can be revealed through the dashboard or MCP when the caller is authorized, but the value still comes from Key Vault. Sensitive env vars are write-only after creation: admins can see the name and metadata, not the value.
What admins can see
Greenlight admins can see that a secret exists. They can see which app it is bound to, which integration uses it, when it was last rotated. They cannot see the value through the dashboard, the API, or any MCP tool.
The only path to a secret value is to read it through the Key Vault directly using the cloud provider’s own access controls. An audit event is written for every Greenlight-mediated secret reference change; reads of the Key Vault are audited by the cloud provider’s native logging.
Rotation
Integration credentials are rotated through the dashboard. The flow is: paste the new credential, click rotate, the new value lands in Key Vault under a new version, the broker switches to the new version on the next call. The old version is retained for the org’s configured grace period and then purged.
There is no app-side change required during rotation. Apps continue to call the broker; the broker pulls whichever version is current.
Workload identity rotates automatically on a cadence the cluster controls — typically every few hours. App pods see this as transparent; they reauthenticate to the broker on each call.
No plaintext at rest, no exceptions
The platform does not have a “but for this one integration we needed plaintext on disk” exception. Every secret routes through Key Vault. If a future provider integration can’t be done that way, it doesn’t ship until it can.