v0lkan
commented
5 months ago Thought about this for a while…
To make things simpler, and easier to handle the data management should act as a plugin.
Whatever we do on file system, should be doable if we swap the file system with KMS.
Also, no two plugins shall be active simultaneously <- This is to ensure that VSecM Safe has a single place to look for cached secrets. Querying multiple places has the potential to give inconsistent results; synchronizing writes to them will be an issue; it will complicate the business logic; and it does not have any practical value (as a user I would not want my secrets to be stored in AWS KMS, Azure KeyVault, and File System all at the same time — If there is a need to write to multiple places simultaneously without loss, then we’ll need to implement a message queue first — if that’s the case, then Safe should push the secret to backup to the queue, and something should fan it out to wherever it needs to go (including file system) -- We already have work items to include NATS into the system, when that happens, we can think about leveraging that; but until that happens, it is only a single plugin at the same time)
The KMS “plugin” will:
- Store secrets as soon as VSecM Safe persists them in memory
- (It does not need to encrypt the secrets because KMS is encrypted in itself anyway)
- Stores versioned-backups of those secrets just like how VSecM Safe does.
VSecM Safe will:
- Fetch the secret from KMS if it’s not in memory
- Be able to configure via an environment variable to use “file system” versus “KMS” as its backing store.
In this initial implementation, the interaction is “one way”. That is to say, if someone modifies the secret in KMS, the change does not reflect to VSecM Safe’s memory. KMS will be a secondary (backup) storage. — later we may introduce a “bypass memory” option to VSecM Safe, which will let it directly talk to the KMS (or File System for that matter) plugin, without relying on its in-memory cahce: that would be slightly slower, but could be what the user wants due to whatever regulatory requirement they need — But for now, and for the sake of this issue, KMS is not a primary storage; it is a backup storage.
This also means when someone sets a secret in KMS in a format that Safe can understand, than safe will automatically fetch it and also replicate it to the file system store when neeeded.
However, when a secret is deleted from KMS it does not automatically get deleted from Safe; you need sentinel to wipe the secret entirely.
Also, we need to clarify what to do when deleting secret for a workload; if we just delete from memory, it will reappear upon a restart; so deleting a secret shall also delete it from FS and KMS too.
In addition, if the secret on KMS changes, ideally it should ripple and update both file system, and memory — but we can create a separate issue for that.
Plus; this issue in itself is large enough to turn into a GitHub project on its own.
Once this is implemented, think about doing the same for GCP, Azure, and HashiCorp Vault too.