Support for fscrypt filesystem encryption

[bilbof]

Is your feature request related to a problem? Please describe.

Encryption at rest is a critical concern. Filesystem encryption is useful when full-disk encryption is impractical or insufficient.

For use cases that rely on local static provisioned volumes, there is currently no easy, built-in method to encrypt data at the filesystem level. This leaves users needing to configure filesystem encryption of directories and volumes out of band of the storage provisioner.

Describe the solution you'd like in detail

I'd like to propose adding support for fscrypt in the local-static-provisioner to provide transparent filesystem-level encryption and decryption of local volumes.

How it could work:

1. Configuration Changes: An additional configuration option in the storageClassMap ConfigMap for local volumes would allow users to specify encryption requirements. Administrators could choose which directories are managed with fscrypt by adding an fscrypt flag in the local-storage-provisioner configuration file. When a new volume is created (i.e., the local static provisioner allocates a directory for a PersistentVolume), fscrypt would be initialized and encryption policies would be applied.
2. Encryption Flow: On volume creation, the provisioner would run the fscrypt tool to set up encryption on the designated directory. The fscrypt utility would be used to automatically lock/unlock the volumes based on policies defined in the fscrypt.conf file (for example, using a key management service or passphrase). The provisioner could manage volume locks, unlocking the encrypted directory when Bound and locking when Available.
3. Decryption/Locking: When a PersistentVolumeClaim is deleted or the volume is released, the provisioner could ensure the directory is securely locked again by fscrypt, protecting the data until the volume is reclaimed or deleted.
4. Volume Lifecycle: Encryption would follow the volume through its lifecycle. When a volume is mounted by a Pod, the provisioner could ensure the fscrypt context is available and the volume is unlocked. When the Pod stops using the volume, the provisioner would re-lock it.

Benefits:

• Security: Encrypting local static volumes would prevent unauthorized access to data even if the disk is compromised or physically accessed.
• Native Integration: Handling encryption at the provisioner means this would be transparent and opt-in per application.
• Flexibility: fscrypt allows the use of different key sources (password-based, hardware-backed) and policies, giving users flexibility in how they manage encrypted volumes.

Describe alternatives you've considered

• Manual Setup of Filesystem Encryption: Administrators can manually configure fscrypt or other encryption mechanisms on local storage directories. This is not integrated into the Kubernetes volume lifecycle. It requires manual intervention each time a new volume is created or deleted, reducing the overall benefit of using the local static provisioner.
• dm-crypt/LUKS: Full disk encryption using dm-crypt or LUKS is another alternative, but it doesn't fit well with the dynamic provisioning model since it's primarily block-level and doesn't offer the flexibility of encrypting individual directories as fscrypt does. Additionally, dm-crypt is more suited for static, persistent disk encryption rather than dynamically created or destroyed volumes.
• Application-level Encryption: Application developers could handle encryption directly at the application layer. However, this requires every application to be encryption-aware, adding complexity to development and management. It places the burden on developers rather than the infrastructure layer.

Additional context

The local-static-provisioner will need to handle locking/unlocking logic gracefully, ensuring that volume access is seamless for users, which could add some complexity to the provisioner's codebase.

The fscrypt utility is easy to use and probably the interface in local-static-provisioner can be made simple. There's still some complexity that end-users will be opting in to and would need to be documented, for instance it will only work on empty directories and some filesystems like ext4.

We’d be very interested in contributing this feature if the maintainers are open to the idea. Please let us know if this is something you would consider and if there are any particular aspects you'd like to see addressed in the design.