Secrets and TLS Bundles

Use a secret for one sensitive value such as an API token or password. Use a TLS bundle when a supported component needs a related certificate and key set. Both surfaces keep plaintext out of ordinary job configuration and return redacted metadata on reads.

Create a secret

You need platform-administrator access.

Open Credentials, then select Secrets.
Select New secret.
Enter a scope, name, and value. Scope and name accept letters, numbers, periods, hyphens, and underscores.
Save the secret.
Select the new row and copy its expansion for job authoring.

For example, a secret named token in the status-api scope is referenced as:

input:
  http-poll:
    url: https://status.example.com/api/incidents
    auth:
      header-token:
        token: "${secret|status-api/token}"
    payload-mode: json

The job definition stores the reference, not the value. Do not put the value in a context variable, commit it to YAML, or paste it into a support bundle.

Scope a secret

Secret metadata can limit use to named jobs and workers. Treat both dimensions as allowlists: a job reference alone does not grant every worker access, and an allowed worker does not grant every job access.

Before deployment:

inspect Usage for the selected secret;
confirm the intended job and worker scopes;
confirm the selected worker is connected and can service the job; and
run the job with a non-destructive provider operation where possible.

The product masks secret values in management responses. Logs, scripts, and provider responses can still disclose material if a pipeline explicitly copies it into an event or command, so review downstream handling as well.

Rotate a secret

Open Credentials → Secrets.
Select the secret.
Choose Rotate, then enter the replacement value.
Save and run a bounded verification on every dependent job.
Revoke the old value at the external provider when the provider supports explicit revocation.

Rotation updates the stored value under the same reference. It does not prove the provider accepted the new value, and it does not revoke old provider-side material automatically.

Managed secrets show a Managed badge. Rotate or remove those values from the owning surface instead of the Secrets tab. This preserves the relationship between the generated secret and its bundle or managed setup.

Delete a secret

Select Usage before deletion. LyftData blocks deletion when known jobs, workers, or managed owners still depend on the record. Remove or migrate those dependencies, rerun the usage check, then confirm deletion.

Deletion removes the LyftData record. It does not revoke a token, password, or certificate at the external provider.

TLS bundles

The TLS bundles tab groups fields required by supported TLS use cases. The current surface includes:

MQTT client TLS;
FTPS client certificates; and
WebSocket server TLS.

Create the bundle, supply each required PEM value, and scope it to the intended jobs and workers. Bundle reads return names, types, expiry metadata, and warnings without returning private field values.

Rotate a bundle when a certificate or key changes. Verify the new certificate chain, key pairing, hostname, and expiry against the remote peer; a saved bundle does not prove a successful TLS handshake.

Backups and key custody

The server encrypts secret and credential state with installation master keys. Those keys are deployment responsibilities:

protect environment-backed keys in a root-owned file with restrictive permissions;
back up the master keys separately from the server staging snapshot;
encrypt backups containing sensitive state;
rehearse restore with the matching keys; and
record rotation and recovery ownership in your runbook.

Losing the master key can make encrypted state unreadable. A staging-directory backup without the matching key is not a complete credential backup. See Configuration, Security hardening, and Backup and recovery.