Create design for client side encryption #6480
Conversation
Signed-off-by: Jeremias Weber <jeremias.weber@cloudogu.com>
|
/kind changelog-not-required |
github-actions
bot
added
the
kind/changelog-not-required
| Then however, it has to be implemented in every single object store plugin. | ||
| This is not viable. | ||
|
|
||
| We could just make use of server-side encryption of an object store. |
There was a problem hiding this comment.
most cloud based Object stores do support encryption at rest using user managed keys.
Can you give production examples where users are using object stores which don't support such functionality.
There was a problem hiding this comment.
Our customers primary concern is that encryption of object stores happens server-side so the data is unencrypted during transit.
There was a problem hiding this comment.
Data should also be encrypted in transit using TLS, though having client side encryption is useful as well.
There was a problem hiding this comment.
A case where this may help is if bsl is set to use insecure for whatever reason.. ie. User decides to use aws plugin and override s3url to use a minio server which is uses self signed cert and have not bothered to setup cacert properly.
There was a problem hiding this comment.
I think the main use case this solves is allowing the consumption of third party object storage for backups without having to entrust the service provider with data encryption keys.
Server-side encryption and transit encryption isn't enough to protect against potential malicious activity at the service provider level. This is just another very useful layer in the security onion.
|
|
||
| Encryption will happen during the backup process before the objects are persisted (e.g. written to an object store). | ||
| Decryption will happen during a restore after the persisted objects have been read. | ||
| The encryption key will be stored in a Kubernetes secret by the user. |
There was a problem hiding this comment.
what are your thoughts on using cloud provider based secret stores for example KeyVault in Azure / AWS Secret manager for maintaing the secret.
Because we are all aware that kubernetes secrets are just plaintext and do no come with any security.
Additionally the lifecycle of the secret is tied to the lifecycle of the cluster.
Storing clusters in secret stores outside might be more secure and durable. Think cross cluster restore
There was a problem hiding this comment.
I understand that this might not be specific use case for you, but I want to bring this up in context of design extensibility. How can current design extend to support such scenarios.
or if it is not planned to supported at all, please put it in non goals
There was a problem hiding this comment.
I designed this feature explicitly in such a way that fetching secrets from a KMS can be implemented as well. See the KeyRetriever interface. Although, maybe this might have to be extended by a plugin API for it to be truly swappable.
|
|
||
| Encryption will happen during the backup process before the objects are persisted (e.g. written to an object store). | ||
| Decryption will happen during a restore after the persisted objects have been read. | ||
| The encryption key will be stored in a Kubernetes secret by the user. |
There was a problem hiding this comment.
I understand that this might not be specific use case for you, but I want to bring this up in context of design extensibility. How can current design extend to support such scenarios.
or if it is not planned to supported at all, please put it in non goals
|
|
||
| ## Background | ||
|
|
||
| As of today, Velero stores only PersistentVolume data in a Restic/Kopia repository. |
There was a problem hiding this comment.
Can you perhaps explain how the Kopia repository is encrypted today. I am personally not aware of the mechanism, will be good to callout in this doc somewhere.
There was a problem hiding this comment.
There's a secret velero-repo-credentials containing the repository password. By default, the password there has the value static-passw0rd. As you see, this is not a strong password and my guess is that the only reason this was used at all is because Kopia and Restic require encryption. While it is possible to change the password in the secret, it is as of yet not a documented feature.
There was a problem hiding this comment.
Documenting the secret is being tracked in #6443.
There was a problem hiding this comment.
Kopia encryption is described here: https://kopia.io/docs/advanced/encryption/.
There was a problem hiding this comment.
Thanks for explaining @jelemux / and the info @draghuram
Thank you for contributing to Velero!
Summary
Currently, backups are not encrypted at rest.
This PR introduces a design proposal that aims to fix this while still retaining backwards compatibility.
A proof-of-concept implementation can be found at https://github.com/cloudogu/velero/tree/feature/client-side-encryption.
Does your change fix a particular issue?
Fixes #434
Fixes #3218
Please indicate you've done the following:
/kind changelog-not-requiredas a comment on this pull request.Updated the corresponding documentation innot necessary, since this is a design docsite/content/docs/main.