[Feature]: Allow use of Custom Username and Password keys from secret

[mananpreetsingh]

Is there an existing issue already for this feature request/idea?

• I have searched for an existing issue, and could not find anything. I believe this is a new feature request to be evaluated.

What problem is this feature going to solve? Why should it be added?

We use custom secrets key value pair to fetch postgres username and password. Usually helm charts provider has the ability to have this in the custom config along with which secret you want to use to pull credentials and also keys and values from that secret.

Describe the solution you'd like

currently this is how cluster is setup, during initdb we can specify a secrets from where it will pull username and password. I needs to have that secrets contain username and password keys that secret should have. But I cannot use if I want to use say these keys from taht secretPOSTGRES_USERNAME and POSTGRES PASSWORD

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  bootstrap:
    initdb:
      database: app
      owner: app
      secret:
        name: app-secret

  storage:
    size: 1Gi

Describe alternatives you've considered

May we we can have config like this so it can support custom keys as well:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: cluster-example-initdb
spec:
  instances: 3

  bootstrap:
    initdb:
      database: app
      owner: app
      secret:
        name: app-secret
        userKey: POSTGRES_USERNAME
        passwordKey: POSTGRES_PASSWORD


  storage:
    size: 1Gi

Additional context

No response

Backport?

Yes

Are you willing to actively contribute to this feature?

No

Code of Conduct

• I agree to follow this project's Code of Conduct

[giulianopz]

It seems indeed already possible, looking at the docs:

The PostgreSQL operator will generate up to two basic-auth type secrets for every PostgreSQL cluster it deploys:
* [cluster name]-app (unless you have provided an existing secret through .spec.bootstrap.initdb.secret.name)

[mananpreetsingh]

It seems indeed already possible, looking at the docs:

The PostgreSQL operator will generate up to two basic-auth type secrets for every PostgreSQL cluster it deploys:

• [cluster name]-app (unless you have provided an existing secret through .spec.bootstrap.initdb.secret.name)

Not really, I am talking about custom keys that already exists in the scrects, not the random secrets that gets created automatically.

e.g:
There is an K8 application already has postgres secrets values that are utilized by the application.

apiVersion: v1
data:
  POSTGRES_PASSWORD: VHhWZVE0bk44MlNTaVlIb3N3cU9VUlp2UURhTDRLcE5FbHNDRUVlOWJ3RHhNZDczS2NrSWVYelM1Y1U2TGlDMg==
  POSTGRES_USER: YXBw
  OTHER_SECRET_1:xxxxx
  OTHER_SECRET_2:xxxxx
  OTHER_SECRET_3:xxxxx
kind: Secret
metadata:
  name: my-app-secret
type: kubernetes.io/basic-auth

Now I want to use existing secret my-app-secret and the keys from it POSTGRES_USER and POSTGRES_PASSWORD. We can specify the existing secret name in the charts my-app-secret but it expects the keys to be username and password. Application may be using these keys for something else so this causes issues or If I want to maintain standard format across my development.

This is the feature that exists in other charts like bitnami, so along with secret name you can also mention which key will be used for username and password.

Hope it is clear?

[giulianopz]

Hi @mananpreetsingh, now I got it. The keys for username and password seem declared here. It seems that what you request is not possible ATM.

@gbartolini, could you please confirm?

[mananpreetsingh]

Hi @giulianopz I know it is not possible ATM, that is why requesting feature if this can be available?

[gbartolini]

Thanks @mananpreetsingh @giulianopz. We have no plans to support other formats. This is a standard basic-auth secret.

[mananpreetsingh]

@gbartolini Thanks for looking into it. I am not requesting different format for auth. I was requesting just the custom secrets names if it can support, pretty standard feature. It will still be standard basic-auth secret. It already support custom secrets, just add the option for custom keys in that secret as well rather than hardcoded ones.