[ProbstenHias]

Problem

charts/substrate renders rustfs.accessKey and rustfs.secretKey as literal env[].value entries in three Pod specs: the RustFS Deployment, the rustfs-bucket-init Job and the object-store plugin. Anyone who can read those Pod specs can read the credentials, and they cannot be managed by an external secret store.

Change

Add rustfs.existingSecret. When it is set, all three consumers read the credentials with valueFrom.secretKeyRef from the keys AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY of that Secret, and rustfs.accessKey/rustfs.secretKey are ignored. One helper, substrate.rustfs.credentialsEnv, renders the env entries for all three.

The keys match what charts/substrate-atelet already expects for objectStore.credentialsSecret, so one Secret can serve both charts.

Backwards compatibility

existingSecret defaults to "". With default values, helm template output is byte-identical to main.

Testing

• helm unittest charts/substrate: exit 0, 63/63 passed. New tests/rustfs_credentials_test.yaml covers the default (literal values) path and the existingSecret path for all three consumers.
• helm template with default values, diffed against main: empty diff, exit 0.
• helm template --set rustfs.existingSecret=foo: none of the 8 RUSTFS_*_KEY/AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY entries has a literal value:.
• helm lint charts/substrate charts/substrate-crds charts/substrate-podcert charts/substrate-atelet: exit 0.
• hack/render-manifests.sh --check: exit 0.

AI disclosure: I used an AI coding assistant to help prepare this change. I reviewed and tested every line.