Tenant is getting an empty string from env referencing a secret

[EStork09]

After upgrading to 6.0.x, the tenant is no longer getting the environment value from the secret. i.e.

spec:
  configuration:
    name: minio-configuration
  env:
    - name: MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM
      valueFrom:
        secretKeyRef:
          key: client-secret
          name: minio-oidc

shows up in the /tmp/minio/config.env as export MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM=""

Expected Behavior

export MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM="" should be a value and not an empty string.

Current Behavior

export MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM="" is being set as an empty string.

Possible Solution

I suppose I could look at putting the secret in the config file with the admin credentials, but I would rather keep that clean and just what is needed.

Steps to Reproduce (for bugs)

1. Update tenant with a environment variable referencing a secret

Context

My OIDC auth has failed because it is now passing an empty string as teh secret.

Regression

Yes? v6.0.x

Your Environment

• Version used (minio-operator): 6.0.2
• Environment name and version (e.g. kubernetes v1.17.2): 1.29.4
• Server type and version: container, RELEASE.2024-08-03T04-33-23Z
• Operating System and version (uname -a): Linux rke2-worker-1 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux
• Link to your deployment file: values.yaml

[ramondeklein]

Operator v6 saves the environment variable to a configuration file on disk, but it only seems to support environment variables that are mapped explicitly to a value (source):

func envVarsToFileContent(envVars []corev1.EnvVar) string {
	content := ""
	for _, env := range envVars {
		content += fmt.Sprintf("export %s=\"%s\"\n", env.Name, env.Value)
	}
	return content
}

It should also be able to resolve variables that are mapped using env.ValueFrom.

[ramondeklein]

I think this needs a fix, because it breaks existing behavior where the environment variables were directly mapped into the pod (like in v5). I can imagine you want to hide some values in a secret...

[EStork09]

Yes, I would very much like to keep secrets a secret 😄

[ramondeklein]

@EStork09 As a temporary workaround, you can also add export MINIO_IDENTITY_OPENID_CLIENT_SECRET_PRIMARY_IAM=... to the minio-configuration secret (add to the existing value of config.env).

[rulim34]

Operator v7 is already released now. Is there any update on this issue? I am using sealed secret to store my secret inside GitOps, and I would like to use separated secret key for each value instead of single config.env key, so that I can track what values are there.

[jwtryg]

Hi, any updates on this issue? :)

[ramondeklein]

No, I'm sorry. This is not an easy change, because currently the configuration file is being created in the operator instead of mounting the environment variables by Kubernetes. We need to rework the structure (essentially move back to how we did this in Operator v5). But that also will bring back things that we tried to resolve with Operator v6:

• Less downtime during upgrades.
• Less downtime when changing configuration.

We still didn't decide if we would go back to the old architecture or keep using this approach.

[Rvarman0110]

Hi @ramondeklein,

Greetings!

I am facing a similar issue with environment variables referencing secrets in Tenant configuration using MinIO Operator v6. I read your comment in another PR that from v7 the behavior will revert back to the old working behavior. Could you please confirm whether upgrading to MinIO Operator v7 would resolve this issue?

Your confirmation will really help us move forward with our deployment model.

Thanks in advance

[ramondeklein]

No, the only way to retain this functionality is to stick with operator v5 for now.