This implements the design we discussed. In simplified terms, the config server
generates a unique encryption key for each snapshot. A sealed variant (the
public part) of this key is then stored in ZooKeeper, along with the version
number of the private key used to seal the key. The private key itself is stored
in a TypedSecretStore.
A node/host that satisfies the node filter can request a copy of the shared key,
sealed with a public key presented by the client. The host then unseals this
shared key locally and uses it to encrypt/decrypt snapshot data. While this
doesn't provide any security itself, it provides some other benefits:
Data is encrypted and encryption keys are managed independently of the service
storing the snapshot data
The config server enforces access control to snapshots by restricting access
to the encryption key
We avoid storing and passing around a plain-text encryption key across API
boundaries
Depends on internal PR.
This implements the design we discussed. In simplified terms, the config server generates a unique encryption key for each snapshot. A sealed variant (the public part) of this key is then stored in ZooKeeper, along with the version number of the private key used to seal the key. The private key itself is stored in a
TypedSecretStore.A node/host that satisfies the node filter can request a copy of the shared key, sealed with a public key presented by the client. The host then unseals this shared key locally and uses it to encrypt/decrypt snapshot data. While this doesn't provide any security itself, it provides some other benefits:
@tokle