Description
If you want to use the backup functionality of WAL-E / WAL-G and you are not running on AWS, currently it is not possible to provide the secrets to the backup bucket in another way then defining a configmap that contains all secrets in plain text for the central Postgres Operator.
Delivering this information in the form of a configmap blocks us from using a GitOps centered approach, where we have tools to persist secrets in Git. Also as far as I noted, as soon as you enter the option in the operator config, that there is a separate configmap, each cluster has to have at least the empty configmap.
I know that there is the possibility to mount secrets for a cloud provider as file like aws account credentials or google ones and reference them in the configmaps for each cluster.
The problem with this approach is if you need direct access to secrets as ENV variables and you need these secrets just for certain environments.
We, for example, run on OpenStack with additional S3 storage and so we can't make real use of the file-based approach, we just need to set up buckets for the relevant clusters and backup each one individually with own environment variables, where others don't require anything else.
Maybe it would be a good idea to add the Kubernetes feature that reads secrets and places all values as env vars to the Pod ( envFrom )
envFrom:
- secretRef:
name: <secret-name>This could be provided in a per cluster spec as:
secret_env:
or similar.
This would allow decoupling the configuration from the secrets.
Am I overlooking something or would this be a viable approach?