How to set default password for a user in percona-postgresql-operator

[ntqp97]

Report

I am trying to set up PostgreSQL in a Kubernetes cluster (in my local environment with kind), using the percona-postgresql-operator. I am trying to set a default password for a user, but it doesn't work

users:
    - name: postgres
      databases:
        - quotesdb
      options: "SUPERUSER"
      password:
        type: ASCII
      secretName: postgres-user-secret

More about the problem

I tried creating a secret named postgres-user-secret with a key named password however this gets overwritten when the pods related to percona pg starts up. Is it possible to setup a default password?

Steps to reproduce

Versions

1. Kubernetes
2. Operator
3. Database

Anything else?

No response

[gkech]

Hello @ntqp97

Recently, we introduced an improvement under this ticket: https://perconadev.atlassian.net/browse/K8SPG-570, which is going to be released with version 2.8 in a few weeks.

You can create a secret like that

apiVersion: v1
data:
  password: YWJjZDEyMzQ1Njc4OQ==
kind: Secret
metadata:
  name: cat-credentials
type: Opaque

Configure it on the cr.yaml like the following:

  users:
    - name: cat
      databases:
        - zoo1
      options: "SUPERUSER"
      password:
        type: ASCII
      secretName: "cat-credentials"
      grantPublicSchemaAccess: false    

And end up with your own default password configured.

[ntqp97]

Looking forward to the 2.8 release — this feature will definitely simplify credential management.

Thanks again!

[shepz]

👋 @gkech Quick question — if the secret already exists, does the operator completely overwrite it, or simply read the password value and generate a new one for its own use?

I’m asking because in environments where Kubernetes secrets are managed by an external secret manager (for example, via External Secrets syncing from Vault or AWS Secrets Manager), any modification made by the operator would be reverted to the original value by the external system. I’m wondering if this behavior could cause a continuous reconciliation loop.