Tenant CRD: no way to mount extra Secrets/ConfigMaps or add initContainers (blocks RUSTFS_EXTRA_CA_CERT and similar env vars)

[davoszabo]

RustFS supports RUSTFS_EXTRA_CA_CERT to trust a custom CA, but this requires the cert to exist as a file inside the pod. The Tenant CRD currently has no way to get arbitrary files into the pod filesystem:

• No extraMounts/volumes/volumeMounts field on the Tenant spec
• No way to reference an extra ConfigMap or Secret for mounting (outside the TLS-only tls.caTrust/certManager block, which doesn't feed RUSTFS_EXTRA_CA_CERT)
• No initContainers support — related issue Support for TLS #74 worked around a similar TLS-cert-mounting problem with a hand-patched initContainer, but this isn't exposed via the CRD
• A side_cars field exists commented-out in tenant.rs, suggesting this was considered but never finished

Workaround today: copying the CA file onto the data PVC out-of-band (e.g. via a sync job) and pointing RUSTFS_EXTRA_CA_CERT at that path — fragile, and doesn't work for anyone without a shared/NFS-backed data volume.

Real-world impact: in a homelab/self-hosted setup, the OIDC identity provider (e.g. Authentik) sits behind an internally-issued CA. Since RustFS can't be made to trust that CA, OpenID Connect login (RUSTFS_IDENTITY_OPENID_*) simply doesn't work — TLS verification against the IdP's well-known/token endpoints fails. This isn't a cosmetic gap; it blocks a core auth feature for anyone not using a publicly-trusted cert on their IdP.

Ask: add one (or more) of:

1. spec.extraMounts / spec.volumes + spec.volumeMounts for arbitrary ConfigMap/Secret mounts, and/or
2. spec.initContainers passthrough, and/or
3. wire tls.caTrust.caSecretRef (or a new extraCaCertSecretRef) through to RUSTFS_EXTRA_CA_CERT directly

Any of these would unblock custom CA trust (and OIDC in particular) without operator-side hacks.