Encryption in Garage? #416
Labels
No Label
AdminAPI
Bug
Check AWS
CI
Correctness
Critical
Documentation
Ideas
Improvement
Low priority
Newcomer
Performance
S3 Compatibility
Testing
Usability
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#416
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Encryption is a recurring subject when discussing Garage. I tagged this issue as "documentation" as many things can already be done with Garage's current feature set and the existing ecosystem. If we identify some non adressed use cases after this review, we may consider specifying some encryption mechanisms in Garage.
I think we need to have a broader answer, documenting LUKS and client-side encryption.
We should have a very high level approach to answer users' needs, not limiting ourselves to the software scope. This is even more appropriate as we are trying to solve this problem with Aerogramme.
Some logs of discussions we had on Garage's channel:
Make clear that traffic is (always) encrypted between Garage nodes
Explain how to make sure that the traffic between a Garage node and your client is encrypted
HTTP API endpoints are in clear text. You have multiple options to have encryption between your client and a node:
Make clear that data is (always) stored in plain text on the filesystem
Give some hints how to encrypt data on rest
Give some hints how to encrypt data on the client side
Feedbacks that could help us
Best practises for encryption in Garageto Encryption in Garage?I am using encryption at rest for my Garage data. My filesystem is ZFS, so I'm using the native ZFS-on-Linux encryption. For how I manage keys so the disks are mounted at boot without human intervention, see my blog
In 2022, encrypting the data at rest should be the default, really, as the overhead is negligible and there's no reason not to :) Plus, it makes decomissioning hard drives much easier, as there's no risk someone buying the used drives (or finding them in the trash!) could recover anything.
I am also exposing Garage behind Traefik which uses Let's Encrypt to add TLS.
We have a strange use case where we would like to share one garage network among friends. Everyone who is part of the network shares non-redundant storage space, and gets redundant storage space in return.
It would be nice if a garage node could transparently encrypt data in a bucket, using an encryption key only known to that garage node. That way, we are not able to read each other's data. Of course, we still need to trust each other to not delete data.
@twee_bloemen You'd be better served by using something like
git-annex
- documentation for which I've just commited in4c143776bf
.git-annex
also tracks where your files go, so you can mitigate the risk of an admin deleting the data by also copying it to a local external drive.