Skip to content

K8SPG-570 update custom secret with labels when they are missing, update missing secret data with autogeneration #1218

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 11 commits into from
Jul 17, 2025
Merged

K8SPG-570 update custom secret with labels when they are missing, update missing secret data with autogeneration #1218

merged 11 commits into from
Jul 17, 2025

Conversation

gkech
Copy link
Contributor

@gkech gkech commented Jul 9, 2025 •
edited
Loading

K8SPG-570 Powered by Pull Request Badge

CHANGE DESCRIPTION

Problem:
By default, the operator will overwrite the user secret if it is custom-created and create a new one with fresh credentials for the user. The only way to avoid this is to provide all the data fields of the secret, or, as pointed out here: https://perconadev.atlassian.net/browse/K8SPG-570?focusedCommentId=426612, provide some specific labels to the secret so that the operator can track it and utilize it to fill in the missing secret data fields.

Cause:
Short explanation of the root cause of the issue if applicable.

Solution:

Testing

cr:

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

Demo secret with only password defined created before applying the cat user cr:

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

Secret after applying the CR for the user:

apiVersion: v1
data:
  dbname: em9vMQ==
  host: Y2x1c3RlcjEtcHJpbWFyeS5rZWNoNS5zdmM=
  jdbc-uri: amRiYzpwb3N0Z3Jlc3FsOi8vY2x1c3RlcjEtcHJpbWFyeS5rZWNoNS5zdmM6NTQzMi96b28xP3Bhc3N3b3JkPWFiY2QxMjM0NTY3ODkmdXNlcj1jYXQ=
  password: YWJjZDEyMzQ1Njc4OQ==
  pgbouncer-host: Y2x1c3RlcjEtcGdib3VuY2VyLmtlY2g1LnN2Yw==
  pgbouncer-jdbc-uri: amRiYzpwb3N0Z3Jlc3FsOi8vY2x1c3RlcjEtcGdib3VuY2VyLmtlY2g1LnN2Yzo1NDMyL3pvbzE/cGFzc3dvcmQ9YWJjZDEyMzQ1Njc4OSZwcmVwYXJlVGhyZXNob2xkPTAmdXNlcj1jYXQ=
  pgbouncer-port: NTQzMg==
  pgbouncer-uri: cG9zdGdyZXNxbDovL2NhdDphYmNkMTIzNDU2Nzg5QGNsdXN0ZXIxLXBnYm91bmNlci5rZWNoNS5zdmM6NTQzMi96b28x
  port: NTQzMg==
  uri: cG9zdGdyZXNxbDovL2NhdDphYmNkMTIzNDU2Nzg5QGNsdXN0ZXIxLXByaW1hcnkua2VjaDUuc3ZjOjU0MzIvem9vMQ==
  user: Y2F0
  verifier: U0NSQU0tU0hBLTI1NiQ0MDk2OkJwUnVjaXpGbHEyTzN0ZEdOY1Z0L2c9PSRhNjNROW9OR0lpT3c5UEZTZnR6Wmh3OUMxWWVmbVFIVXFuYUVFYlBxWTZ3PTpRaHdneXFFcWRhWEUva0R0QWNaNUJOTEErMHBEZFNZeGhkWWdMbTY4ZDlVPQ==
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","data":{"password":"YWJjZDEyMzQ1Njc4OQ=="},"kind":"Secret","metadata":{"annotations":{},"name":"cat-credentials","namespace":"kech5"},"type":"Opaque"}
  creationTimestamp: "2025-07-10T09:33:21Z"
  labels:
    app.kubernetes.io/instance: cluster1
    app.kubernetes.io/managed-by: percona-postgresql-operator
    app.kubernetes.io/name: percona-postgresql
    app.kubernetes.io/part-of: percona-postgresql
    postgres-operator.crunchydata.com/cluster: cluster1
    postgres-operator.crunchydata.com/pguser: cat
    postgres-operator.crunchydata.com/role: pguser
  name: cat-credentials
  namespace: kech5
  resourceVersion: "1752140058349791006"
  uid: 3b4f4e2b-b5d3-4a5c-b8a3-424f4e42468a
type: Opaque

Notice that all the related properties were automatically added to the secret, keeping the original password that was specified by the secret that was created manually.

Note that the aforementioned scenario is also added on the users e2e test.

CHECKLIST

Jira

  • Is the Jira ticket created and referenced properly?
  • Does the Jira ticket have the proper statuses for documentation (Needs Doc) and QA (Needs QA)?
  • Does the Jira ticket link to the proper milestone (Fix Version field)?

Tests

  • Is an E2E test/test case added for the new feature/change?
  • Are unit tests added where appropriate?

Config/Logging/Testability

  • Are all needed new/changed options added to default YAML files?
  • Are all needed new/changed options added to the Helm Chart?
  • Did we add proper logging messages for operator actions?
  • Did we ensure compatibility with the previous version or cluster upgrade process?
  • Does the change support oldest and newest supported PG version?
  • Does the change support oldest and newest supported Kubernetes version?

@gkech gkech changed the title K8SPG-570 update custom secret with labels when they are missing K8SPG-570 update custom secret with labels when they are missing, update missing secret data with autogeneration Jul 9, 2025
@gkech gkech marked this pull request as ready for review July 10, 2025 09:45
hors
hors previously approved these changes Jul 15, 2025
View reviewed changes
pooknull
pooknull requested changes Jul 15, 2025
View reviewed changes
@gkech gkech requested review from pooknull and hors July 15, 2025 11:21
@JNKPercona
Copy link
Collaborator

Test Name Result Time
backup-enable-disable passed 00:07:32
custom-extensions passed 00:09:43
custom-tls passed 00:05:48
database-init-sql passed 00:03:39
demand-backup passed 00:25:15
finalizers passed 00:03:54
init-deploy passed 00:03:17
monitoring passed 00:08:18
monitoring-pmm3 passed 00:08:02
one-pod passed 00:05:50
operator-self-healing passed 00:08:06
pgvector-extension passed 00:02:35
pitr passed 00:12:02
scaling passed 00:04:55
scheduled-backup passed 00:25:58
self-healing passed 00:08:27
sidecars passed 00:02:37
start-from-backup passed 00:10:58
tablespaces passed 00:07:38
telemetry-transfer passed 00:03:14
upgrade-consistency passed 00:07:14
upgrade-minor passed 00:06:02
users passed 00:04:23
We run 23 out of 23 03:05:37

commit: 06816f1
image: perconalab/percona-postgresql-operator:PR-1218-06816f10a

@hors hors merged commit 19b203c into main Jul 17, 2025
18 checks passed
@hors hors deleted the K8SPG-570 branch July 17, 2025 16:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@egegunes egegunes egegunes approved these changes

@pooknull pooknull pooknull approved these changes

@nmarukovich nmarukovich nmarukovich approved these changes

@jvpasinatto jvpasinatto Awaiting requested review from jvpasinatto jvpasinatto is a code owner

@eleo007 eleo007 Awaiting requested review from eleo007 eleo007 is a code owner

@valmiranogueira valmiranogueira Awaiting requested review from valmiranogueira valmiranogueira is a code owner

@hors hors Awaiting requested review from hors hors is a code owner

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
6 participants
@gkech @JNKPercona @hors @egegunes @pooknull @nmarukovich