Vault Version: 1.19.0
Kubernetes Version: 1.32.0
Environment: Kubernetes cluster with two Vault instances (source and destination)
Description:
I'm evaluating vault-secret-sync to synchronize secrets between two Vault instances. During testing, I've observed two behaviors related to secret versioning that we'd like to clarify:
-
Latest Version Sync Only:
Scenario: A secret exists in the source Vault with multiple versions (e.g., v1, v2, v3).
Observation: When the synchronization process runs, only the latest version (v3 in the example) of the secret appears to be created/updated in the destination Vault. The historical versions (v1, v2) are not present.
Impact: If applications or configurations relying on the destination Vault attempt to access a specific, older version of the secret (e.g., secret/data/my-secret?version=2), this fails because only the latest version's data exists under that version number (e.g., v1 in the destination vault might contain the data from v3 of the source vault).
Question: Is syncing only the latest version of a secret the intended design? If so, is there any mechanism or plan to support syncing historical versions or ensuring version numbers align between source and destination?
-
Destination Version Bump on Manual/Re-Sync:
Scenario: A secret has been successfully synced from the source to the destination Vault. No changes are made to the secret in the source Vault. I then either manually trigger a sync or re-apply/re-create the vault-secret-sync CRD associated with this secret.
Observation: Upon this re-sync action, the version number of the secret in the destination Vault is incremented, even though the underlying secret data (from the source) has not changed.
Example: Source secret secret/data/my-app is at v2. Destination secret secret/data/my-app is synced and is at v1 (containing source v2 data). Re-trigger sync. Destination secret secret/data/my-app becomes v2, still containing source v2 data.
Question: Is it the intended behavior for the destination secret's version to be incremented on every sync trigger (manual or via CRD update), regardless of whether the source secret data has changed? If so, could you explain the reasoning?
Vault Version: 1.19.0
Kubernetes Version: 1.32.0
Environment: Kubernetes cluster with two Vault instances (source and destination)
Description:
I'm evaluating vault-secret-sync to synchronize secrets between two Vault instances. During testing, I've observed two behaviors related to secret versioning that we'd like to clarify:
Latest Version Sync Only:
Scenario: A secret exists in the source Vault with multiple versions (e.g., v1, v2, v3).
Observation: When the synchronization process runs, only the latest version (v3 in the example) of the secret appears to be created/updated in the destination Vault. The historical versions (v1, v2) are not present.
Impact: If applications or configurations relying on the destination Vault attempt to access a specific, older version of the secret (e.g., secret/data/my-secret?version=2), this fails because only the latest version's data exists under that version number (e.g., v1 in the destination vault might contain the data from v3 of the source vault).
Question: Is syncing only the latest version of a secret the intended design? If so, is there any mechanism or plan to support syncing historical versions or ensuring version numbers align between source and destination?
Destination Version Bump on Manual/Re-Sync:
Scenario: A secret has been successfully synced from the source to the destination Vault. No changes are made to the secret in the source Vault. I then either manually trigger a sync or re-apply/re-create the vault-secret-sync CRD associated with this secret.
Observation: Upon this re-sync action, the version number of the secret in the destination Vault is incremented, even though the underlying secret data (from the source) has not changed.
Example: Source secret secret/data/my-app is at v2. Destination secret secret/data/my-app is synced and is at v1 (containing source v2 data). Re-trigger sync. Destination secret secret/data/my-app becomes v2, still containing source v2 data.
Question: Is it the intended behavior for the destination secret's version to be incremented on every sync trigger (manual or via CRD update), regardless of whether the source secret data has changed? If so, could you explain the reasoning?