Feature Request: Support for multiple / layered Rclone remotes in `configData` secret

[Dual-0]

Hello,

this feature request is related to a significant limitation when trying to deploy Rclone mounts with complex configurations, specifically layered remotes (e.g., crypt over a base remote) via the csi-rclone driver.

Problem

The current implementation of the Mount function in pkg/rclone/rclone.go includes a check:

	if len(secs) != 2 { //there's also a DEFAULT section
		return fmt.Errorf("Mounting failed: expected only one config section: %s", cfg.SectionStrings())
	}

This strictly enforces that the configData provided in the Kubernetes Secret (which is then passed as rcloneConfigData) must contain only one non-default Rclone remote section.

This prevents common and essential use cases such as:

• Mounting a crypt remote (e.g., gdrive_crypt) which relies on a base remote (e.g., gdrive).
• Defining specific configuration parameters (like drive_chunk_size, drive_pacer_min_sleep, user_agent) for the base gdrive remote, while also using an encrypted gdrive_crypt remote for the actual mount.

When attempting to provide a configData with both gdrive and gdrive_crypt sections, the driver immediately fails with the described "expected only one config section" error. This forces users to either forgo encryption or lose the ability to fine-tune the base remote, or resort to less Kubernetes-native workarounds.

Solution

I would like the csi-rclone driver to be enhanced to support multiple Rclone remote sections within the configData field of the Kubernetes Secret. This would enable the use of layered remotes and other complex Rclone configurations.

Specifically, the desired behavior of the Mount function (and potentially NodePublishVolume in pkg/nodeserver/nodeserver.go) should include:

1. Removal of the if len(secs) != 2 check: This is the primary blocker that needs to be removed.
2. Iterative Remote Creation: The driver should parse all remote sections present in rcloneConfigData. For each section, it should make a config/create RC API call to the rclone rcd daemon.
3. Dependency Resolution (Crucial for Layered Remotes):
   • Remotes should be created in an order that respects dependencies. For example, a gdrive remote must be created before a gdrive_crypt remote that refers to it (remote = gdrive:...). A simple retry loop or a dependency graph solver could achieve this.
4. Unique RC Remote Naming: Each remote created by the driver for a specific volume (e.g., gdrive, gdrive_crypt) should be given a unique name within the rclone rcd daemon's context (e.g., rclone-mounter-<volumeId>-gdrive, rclone-mounter-<volumeId>-gdrive_crypt).
5. Referencing Layered Remotes: When creating a layered remote (like gdrive_crypt where remote = gdrive:path), the driver should automatically update the remote parameter to point to the dynamically generated RC name of the base remote (e.g., remote = rclone-mounter-<volumeId>-gdrive:path).
6. Final Mount Target: The mount/mount RC API call should then use the dynamically generated RC name of the final desired mount target (e.g., rclone-mounter-<volumeId>-gdrive_crypt).

Current alternatives

1. Rclone Sidecar with HostPath and DaemonSet: This is the current workaround. It involves running separate DaemonSet pods with privileged access on each node to handle the Rclone mounts, then exposing these mounts via hostPath volumes to application pods.

   • Pros: Works, allows full Rclone flexibility (including layered remotes), and maintains Pod Security Standard compliance for application pods.
   • Cons: Less Kubernetes-native than a CSI driver, introduces hostPath reliance, and potentially higher resource consumption (Rclone processes running on multiple nodes even if not actively used).

2. Mounting the Unencrypted Base Remote (e.g., gdrive) Directly:

   • Pros: Works with the current driver.
   • Cons: Loses client-side encryption provided by crypt remotes, which is often a critical requirement.

Additional context

The use of layered Rclone remotes (especially crypt remotes) is a very common pattern for users concerned about data privacy and security when storing files in cloud storage. A CSI driver that natively supports this would greatly enhance its utility and adoption for such users.

The current limitation forces users into less ideal workarounds or compromises on security, which could be avoided with a more flexible configuration parsing mechanism.

Thanks in advance

[ppoloskov]

I have found that only https://github.com/dvcrn/csi-rclone-reloaded/ implementation supports multiple mounts