My initial feedback on the alpha version

[sagikazarmark]

General

• query: What's the rationale behind a separate path and key field?
• query: Can we call key something like keySelector or keyMatcher?
• Prefer camelCase instead of snake-case
• query: key-transform should be keyTransformation (let's brainstorm other names)
• plan: let's brainstorm other potential names (it's not necessarily bad, but takes some getting used to, not a blocker for alpha)
• dest: Should dest(ination) be called target instead?

Does this make sense?

secret-sync --source path/to/vault-source.yaml \
            --dest path/to/vault-dest.yaml \
            --sync path/to/sync-job.yaml

secret-sync --source path/to/vault-source.yaml \
            --dest path/to/vault-dest.yaml \
            --plan path/to/sync-job.yaml \
            --sync|--once

Provider

There are some inconsistencies in the nomenclature here. We use secret store and provider interchangeably. Provider gets even more overloaded in the code, where Provider acts as a kind of sql.DB like globally registered driver, but we still have a SecretStoreProvider and additional terms, like Client and Backend.

IMO this should be cleaned up, because it can be a major source of confusion.

Looking at the Vault provider, unseal-keys-path is an incorrect use of terminology. From what I understood it's the mountpoint from where secrets are loaded. This is also problematic for a number of reasons:

• It requires a kv type store (which can be an acceptable limitation for now, but should work with other types of stores in the future)
• I think it should be perfectly fine to synchronize from multiple mount points in a single job (For example: you have a shared kb type store and a per-cluster/namespace kv type store at two different mount points)

Permissions

I find the concept a bit confusing and premature to be honest. I guess the idea is to make sure/enforce that stores designated as source/reader cannot be used as a destination accidentally which is nice in theory, but it's probably more confusing than useful at this point.

Permission is also not the term I would use. Role comes to mind as a more fitting terminology. Source and destination (or rather target) are also slightly better terms than reader and writer IMO.

My gut feeling is we should remove this for now and open an issue about adding it back in the future once other parts of the configuration become more mature.