Versioned credentials and deliberate rotation
Secret versions and binding promotion make credential changes explicit, with checks that preserve tenant ownership and secret lineage.
Give a credential change an identity
SecretProxy now supports versioned secrets and explicit binding promotion. Updating a credential creates a version that can be identified separately from the secret itself. A binding records which version it uses.
This makes rotation a concrete operation. An operator can add the next credential value and decide when a target binding should move to it. The application’s reference and the upstream credential’s lifecycle no longer have to be treated as the same thing.
Validate the destination of a promotion
The promotion operation checks the binding and target version within the tenant. It then verifies that the target version belongs to the same secret as the current version. A version from another secret or another tenant cannot be used as a shortcut around that relationship.
The management API exposes version history with masked values. That gives the interface a way to show the progression of a secret without turning a routine list or history view into a display of credential material.
Coordinate with the upstream service
A proxy-side version is one part of rotation. The upstream service must still recognize the new credential, and the operator must decide when the previous credential should stop working. Updating a binding does not revoke a key at the service that issued it.
The new model makes those steps easier to distinguish and inspect. It provides a defined point at which SecretProxy changes the version used for a target, while leaving upstream issuance and revocation as explicit operational work.