Skip to content

Provide way to read config environment vars from secrets instead of configmap #597

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
containerpope opened this issue Jun 25, 2019 · 1 comment

Comments

@containerpope
Copy link

containerpope commented Jun 25, 2019

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?

@containerpope containerpope changed the title Provide way to read pod_config from secrets instead of configmap Provide way to read config environment vars from secrets instead of configmap Jun 25, 2019
@FxKu
Copy link
Member

FxKu commented Jul 30, 2020

Closing as #946 got merged. Thanks for bringing it up.

@FxKu FxKu closed this as completed Jul 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants