Credentials and Secrets
LyftData keeps sensitive values outside job definitions and delivers only the material a job and worker are allowed to use. Start here when a pipeline needs an API token, TLS certificate, OAuth grant, or other provider credential.
Choose the right surface
Section titled “Choose the right surface”| You need to store | Use | Reference from a job |
|---|---|---|
| A non-secret setting such as a URL, region, or batch size | Context | {{name}} |
| One password, API token, or private value | Secret | `${secret |
| A certificate/key set for a supported TLS use case | TLS bundle | Copy the reference supplied by the bundle |
| An OAuth grant with consent, refresh, and scope policy | Credential Manager | Use the credential ID in a supported component |
| A reusable group of existing OAuth credentials | Credential bundle | Bind the bundle to a job from the Credential bundles tab |
A context is reusable configuration, not a vault. Encryption of the variables store protects server state at rest, but ordinary context values can still appear in rendered configuration and operational views. Put confidential material in a secret or credential surface.
How governed delivery works
Section titled “How governed delivery works”The safe path has distinct stages:
- A platform administrator creates sensitive material in Credentials.
- LyftData returns redacted metadata and a reference or credential ID, not the stored plaintext value.
- The administrator limits which jobs and workers may use the material.
- A supported input, action, or output requests the reference at runtime.
- LyftData delivers bounded material to the selected runtime.
A saved record is not proof that a job can use it. A credential may still need activation, a job binding, an allowed-worker decision, a serviceable worker, and provider connectivity. Verify those layers separately.