-
Notifications
You must be signed in to change notification settings - Fork 7
Description
Hello,
Thank you for all your work on this project.
I know the Operator is not ready yet, this is not a bug, more like a feature request you already know with feedback you already know but can eventually help the community.
I tried using the Operator to install RustFS in Multiple Node Multiple Disk with TLS support. As far as I know this is not yet implemented by the Operator as the Tenant Custom Resource doesn't provide properties to add certificates.
If I read the documentation correctly, RustFS currently only provide the RUSTFS_TLS_PATH environment variable to be able to specify the directory were it can find all the certificates it needs. RustFS seems to browse this directory to search for server public / private keys and trusted bundles. It also seems to browse sub directories considering each sub directory as a domain.
I modified the Operator to be able to mount a Secret, containing server public / private keys, and to mount a ConfigMap containing the CA bundle to trust. It didn't work because of Kubernetes way of dealing with mounts. Here is an example of the RUSTFS_TLS_PATH directory with mounted files:
├── ..2026_01_15_08_42_17.1209469815
│ ├── ca.crt
│ ├── tls.crt
│ └── tls.key
├── ..data -> ..2026_01_15_08_42_17.1209469815
├── ca.crt -> ..data/ca.crt
├── tls.crt -> ..data/tls.crt
└── tls.key -> ..data/tls.key
Considering this tree structure and RustFS browsing sub directories. RustFS does find the server public / private keys (tls.crt and tls.key) and the CA bunble (ca.crt). But it also finds certificates for the domain ..data and ..2026_01_15_08_42_17.1209469815, which of course, aren't domains.
I resolved it by adding an initContainer to the generated StatefulSet to mount Kubernetes Secret / ConfigMap into a directory (tls_mount) and to create another directory (RUSTFS_TLS_PATH) which holds only symbolic links to the previous directory:
├── ca.crt -> ../tls_mount/ca.crt
├── tls.crt -> ../tls_mount/tls.crt
└── tls.key -> ../tls_mount/tls.key
Maybe, another way would have been to use Kubernetes VolumeMount subPath to avoid Kubernetes from creating symbolic links but this approach prevents Kubernetes from automatically updating the mounts.
I looked at RustFS Helm Chart but its seems to only consider terminating the TLS at Gateway API level.
What do you think will be the best approach? Does RustFS miss some environment variables to be able to configure the TLS?
Hope it helped someone. Don't bother to answer if it is not relevant.