opencloud init: support environment variables for all generated secrets

[bernardgut]

Problem

opencloud init generates random passwords for all internal secrets (IDM service passwords, JWT, transfer secrets, etc.) and provides no mechanism to inject pre-defined values via environment variables.

In containerized deployments (Kubernetes, Docker), this means:

• Every pod restart with an empty config dir generates new random secrets
• IDM (LDAP) service passwords written during init no longer match what services use at runtime
• This causes LDAP bind failures and broken authentication after any restart without config volume persistence

Only --admin-password is exposed as a CLI flag. The 12 other secrets have no override mechanism.

Affected secrets

Secret	Config field	Proposed ENV var
IDM service password	idm.service_user_config.password	IDM_SVC_PASSWORD
IDM Reva service password	idm.service_user_config.reva_password	IDM_REVASVC_PASSWORD
IDM IDP service password	idm.service_user_config.idp_password	IDM_IDPSVC_PASSWORD
Admin password	admin_password	OC_ADMIN_PASSWORD
JWT secret	token_manager.jwt_secret	OC_JWT_SECRET
Machine auth API key	machine_auth_api_key	OC_MACHINE_AUTH_API_KEY
Transfer secret	transfer_secret	OC_TRANSFER_SECRET
Service account secret	service_account.service_account_secret	OC_SERVICE_ACCOUNT_SECRET
WOPI secret	collaboration.wopi.wopi_src_secret	COLLABORATION_WOPI_SECRET
System user API key	system_user_api_key	SYSTEM_USER_API_KEY
URL signing secret	n/a	OC_URL_SIGNING_SECRET
Thumbnails transfer secret	n/a	THUMBNAILS_TRANSFER_SECRET

Proposed fix

Add a helper in opencloud/pkg/init/ that checks for the corresponding environment variable before falling back to random generation:

func secretFromEnvOrRandom(envVar string, length int) (string, error) {
    if v := os.Getenv(envVar); v != "" {
        return v, nil
    }
    return generators.GenerateRandomPassword(length)
}

This is fully backward-compatible: when no ENV var is set, behavior is identical to today.

Use case

Helm charts and container orchestrators can inject stable, pre-defined secrets via Kubernetes Secrets → ENV vars, eliminating the need for config volume persistence and ensuring LDAP credentials remain consistent across restarts.

[micbar]

This is already working. You can completely skip that init step and only use env variables. We do this in kubernetes.

So there is no need to teach the init script to respect variables, just skip it entirely.

[bernardgut]

Thanks @micbar — you were right. I've validated the skip-init approach end-to-end and it works perfectly.

Complete ENV var mapping (what replaces opencloud init):

Category	ENV vars
Core secrets	OC_JWT_SECRET, OC_MACHINE_AUTH_API_KEY, OC_TRANSFER_SECRET, OC_URL_SIGNING_SECRET, OC_SYSTEM_USER_API_KEY
Service account	OC_SERVICE_ACCOUNT_ID, OC_SERVICE_ACCOUNT_SECRET, SETTINGS_SERVICE_ACCOUNT_IDS
IDM passwords	IDM_ADMIN_PASSWORD, IDM_SVC_PASSWORD, IDM_REVASVC_PASSWORD, IDM_IDPSVC_PASSWORD
LDAP bind (per-service)	USERS_LDAP_BIND_PASSWORD, GROUPS_LDAP_BIND_PASSWORD, AUTH_BASIC_LDAP_BIND_PASSWORD, IDP_LDAP_BIND_PASSWORD, GRAPH_LDAP_BIND_PASSWORD
UUIDs	OC_SYSTEM_USER_ID, OC_ADMIN_USER_ID, GRAPH_APPLICATION_ID, STORAGE_USERS_MOUNT_ID, GATEWAY_STORAGE_USERS_MOUNT_ID
Other	COLLABORATION_WOPI_SECRET, THUMBNAILS_TRANSFER_TOKEN

Key findings:

• The LDAP bind passwords must be set per-service (e.g., USERS_LDAP_BIND_PASSWORD), not just at the IDM level
• GATEWAY_STORAGE_USERS_MOUNT_ID and STORAGE_USERS_MOUNT_ID need the same value but must be set separately
• UUIDs can be any valid v4 UUID, they just need to be stable across restarts

I've updated the community Helm chart PR accordingly. PR #2484 can be closed since it's no longer needed.

Would it be useful for us to contribute this ENV var mapping to the OpenCloud docs?

[micbar]

Thank you, that is not needed. Nobody needs to directly interact with these. The opencloud helm chart does that and takes care of that.