Secret versions

Every time YEKE applies a Secret — from the UI, through an AI tool, via API/shell, or through a revert/restore operation — it records that content as an encrypted version row. A change made inside the cluster outside YEKE (kubectl, Helm, another operator…) is not lost either: the next time YEKE itself writes to that Secret, it adds the intervening difference to the history with the "Outside YEKE" source. There is NO continuous watch/poll process — detection is tied to YEKE's own write moment (see Limits).

This feature is a history of the Secret's content; the Secret's RBAC, what it's mounted by, or how it's consumed are not covered on this page.

The new "History" tab on the Secret detail page lists every recorded version for that Secret, newest first. Each row reads as rN · <date time> (with an accessible name like "Revision 7") and carries a source tag:

A Secret that has never been written through YEKE shows the History tab's empty state: "No versions yet" — "YEKE has not written to this Secret yet — history starts with the first YEKE write, and changes made outside YEKE are recorded on the next YEKE write."

Clicking a row in the History tab opens a comparison panel right BELOW the selected version: by default it compares the selected version against the Secret's live, current state ("rN vs. now"). Only keys that DIFFER are listed row by row; keys that stayed the same are hidden behind "Show the N identical keys". A value's visibility opens with the row's own "Show" control, and closes with the "Hide" control that appears in the same place once it's open.

Each row has its own "Restore"/"Remove" action — it restores just that key to its value in the selected earlier version, or removes a key that doesn't exist in the selected version. The control at the top of the screen does the same for the whole Secret in one step: if the Secret still exists in the cluster it reads "Restore all to rN"; if it's been deleted from the cluster, the same control reads "Recreate from rN".

Whether row by row or all at once, every restore goes through YEKE's single write path: it builds a plan and is applied only after passing through an approval card — the History tab never writes straight to the live Secret. Restoring never changes the Secret's type, only its data.

Recreating a deleted Secret

The "Deleted Secrets" view on the Secret list page lists Secrets that have been deleted from the cluster but whose history is still within the retention window; each row's "Open history" link takes you straight to that Secret's History tab. There you pick whichever version still has its content stored and choose "Recreate from rN" — this only works for the WHOLE Secret (not a single key) and requires permission to CREATE the Secret; key-level access is not enough. The recreated Secret comes back in the cluster as a new object — it gets a new uid, it is not a continuation of the old one.

Version history works together with the Secret display ceiling (YEKE_SECRET_DISPLAY), it doesn't bypass it. While the ceiling is masked or hidden, values stay masked in the diff screen — but which keys changed, when, and which key would be restored to which earlier version stays visible. That makes a "blind restore" possible: restoring a key with "Restore", knowing which keys changed, without ever reading the value itself.

The same boundary applies to a user with a permission group's key-level access: restoring from the History tab can only change the value of a key that user already has "Can edit" access to and that already EXISTS — it cannot add a new key or remove one. Adding or removing a key requires full write access to the Secret.

Version rows past YEKE_SECRET_VERSION_RETENTION_DAYS are deleted. But a Secret's highest-revision head row is never deleted this way; once it ages out, only its content is dropped — the row itself and its rN number stay put. YEKE_SECRET_VERSION_MAX caps how many rows are kept per Secret: the newest N rows stay, older ones (again except the head row) are deleted.

Enterprise — secret-versions (E6, the fourth item of "Access and Secret management"). It joins secret-display, secret-keys and effective-access. If the license lapses, new version recording stops and reading/restoring from the History tab closes — but existing version rows are NOT deleted, they only drop once retention (90 days by default) expires.

• No key rotation. History is stored using the existing envelope encryption mechanism; if the encryption key is rotated, older versions can no longer be opened.
• Detection is lazy, not a continuous watch. A change made outside YEKE only becomes visible the NEXT time YEKE itself writes to that Secret. If more than one outside change happened between two YEKE writes, only the LAST one is recorded in history — the states in between are lost.
• History starts from YEKE's FIRST write. A Secret never written through YEKE has no history; the first record opens with YEKE's first write to that Secret.
• Helm's own release Secrets are out of scope. Secrets carrying the helm.sh/release.v1 label don't go through this mechanism — Helm has its own versioning, and the right tool there is helm rollback.
• Restoring never changes a Secret's type. It writes only the data (the key–value pairs); the Secret's type field stays as it is.
• Reading history requires cluster access. The cluster always decides what you can read — history is not a separate source of authority independent of the cluster.
• An existing Enterprise license in production does not unlock this item on its own. secret-versions is its own feature key; a license carrying one of the old E6 names is treated as having unlocked the previous three items (see pricing), but the fourth item needs the license re-signed with the secret-versions name.