Read Secrets from Disk as well as from Env

[xorima]

Summary

Today secrets such as REDIS_USERNAME are only readable via os.GetEnv() which means we cannot mount secrets from disk. For some

Motivation

Within some environments I work in we can only mount secrets from disk following gatekeeper policies, this means today I cannot run argocd in these environments as the rules around this block me.

Proposal

Where we are reading secrets today we could either:

1. Give the env var an alternative _FILEPATH and read the file from there
2. Have a config file which can be read from using a tool like viper to give users the option.

Potential additional benefits are that when secrets change (such as a redis password rotation) the change can be automatically picked up without needing a pod restart.

Notes

I am happy to start implementing this if people agree, it's more an RFP before putting in the work

[crenshaw-dev]

Do you have a full list of the relevant secrets?

[xorima]

Name	Default (Based on helm chart)

│ REDIS_USERNAME: <set to the key 'redis-username' in secret 'argocd-redis'> Optional: true │ │ REDIS_PASSWORD: <set to the key 'auth' in secret 'argocd-redis'> Optional: false │ │ REDIS_SENTINEL_USERNAME: <set to the key 'redis-sentinel-username' in secret 'argocd-redis'> Optional: true │ │ REDIS_SENTINEL_PASSWORD: <set to the key 'redis-sentinel-password' in secret 'argocd-redis'> Optional: true │

So it's pretty much the redis items.

Upon reflection, rather than have it load from disk, maybe this should just be read directly from k8s secrets, such as how the argocd-repo-server-tls works today, or a new secret created, and read directly

[anandf]

@crenshaw-dev @xorima Can this be worked on ? We are mentoring group of students for upstream contribution and I think, it might be a good ticket for them to work on.

[crenshaw-dev]

maybe this should just be read directly from k8s secrets

I'm wondering the same. My only hesitation is that I'm not sure we want to give the repo-server k8s API access at all.

[xorima]

maybe this should just be read directly from k8s secrets

I'm wondering the same. My only hesitation is that I'm not sure we want to give the repo-server k8s API access at all.

what is the concern here, would it be better to have it mount from disk in the helm chart & ammend the existing code to support that flow as well?

My main thing here is to not have it mount from environment variables as these are blocked within my workplace systems and thus I cannot run argocd when I wan to currently