Secrets and credentials

Store integration credentials, manage encryption material, and rotate access.

Infra stores credentials used by backup destinations, notification routes, connectors, provisioning integrations, and network services. Secret access is separate from resource configuration access.

Create a secretCopy link

Open Settings → Secrets in the intended scope. Choose the secret type, enter its value, and restrict its permitted consumers. A backup credential should be usable by its backup destination rather than every project integration.

Stored secret values are masked after creation. Configuration views show the secret reference, revision, and last update without returning the plaintext. A service that consumes the secret receives only the material required for its configured integration.

Scope and referencesCopy link

Project secrets can be referenced by permitted resources in that project. Organization secrets can be restricted to named regions or consumers. A reference to a secret outside the caller's permitted scope is rejected.

Deleting a referenced secret is blocked by active consumers. Remove or replace the references first. Revoking an external credential can still break an active consumer even when the stored reference remains valid.

RotationCopy link

1. Create the replacement credential in the issuing provider's account with the required permissions. Keep the old credential valid during this planned rotation.
2. Open Settings → Secrets in the secret's scope, select the secret, and add a revision containing the complete replacement value.
3. Apply the replacement through each consumer's configuration: use backup destination credentials for an archive account or HTTPS listener rotation for a certificate.
4. Read the secret's consumer results and confirm the requested revision is also the observed revision. For a backup destination, run its capability test and check the result.
5. Inspect the consumer's active operations under Operations → Queue. Wait for transfers still using the old credential to finish before revoking it at the provider.

An update does not guarantee that an already running transfer can switch credentials midway. Retain the old credential until active consumers finish or the integration documents a safe transition.

Encryption materialCopy link

Self-hosted installations keep encryption material outside the primary database and use it to protect stored secret values. Include that material in the control-plane backup using a separately protected path. A database restore without the required key cannot recover encrypted credentials.

Key rotation must preserve the ability to read existing encrypted revisions until they have been rewrapped or expired. Do not remove old key material merely because new writes use a newer key.

Workload secretsCopy link

Guest user data and images are not secret stores. They can be read by operators with configuration access and can persist in guest logs or snapshots. Deliver application secrets through a workload secret manager or a short-lived bootstrap exchange after the guest identity is established.

Exposure responseCopy link

For an exposed external credential, revoke it at the issuing provider first; planned rotation's overlap period is inappropriate while an attacker might use it. Then follow Rotation to install a replacement in Infra's consumers. Deleting the masked secret entry does not revoke provider access.

Open Operations → Queue to identify consumer work affected by revocation. Correct authentication failures after the replacement is adopted, and use the audit log to review requests during the exposure period. Copies in retained backups remain subject to their retention policy.

For enrollment and API credentials, use their dedicated revocation workflows in Node enrollment and API authentication.