Suport keys in backup config instead of a configuration file

[benjamin-bergia]

Overview

Currently, credentials are passed to pgbackrest using a configuration file stored in a secret. This is not very flexible and doesn't always play well with tools like bitnami sealed-secrets.

Use Case

I have a cluster pushing backups to S3 . My configuration looks something like this:

spec:
  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.35-0
      configuration:
      - secret:
          name: < name of the secret containing my s3.conf >
      global:
        repo1-path: ***
      repos:
      - name: repo1
        s3:
          bucket: ***
          endpoint: ***
          region: ***

Desired Behavior

I would like to be able to do something like this instead:

spec:
  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.35-0
      global:
        repo1-path: ***
        repo1-s3-key:
          secretKeyRef:
            name: ***
            key: ***
        repo1-s3-key-secret:
          secretKeyRef:
            name: ***
            key: ***
      repos:
      - name: repo1
        s3:
          bucket: ***
          endpoint: ***
          region: ***

In this case I use the secretKeyRef since it's a structure that is already known to most users and used to reference secrets in environments, but it could be also just secretName and secretKey. I think removing the config file secret, would simplify the configuration by making it a direct one on one matcing of the pgbackrest configuration. On top of that it makes it easier and more flexible to reference different secrets for different repos.

Environment

• Platform: Kubernetes
• Platform Version: 1.21
• PGO Image Tag: 8-13.4-1
• Postgres Version 13
• Storage: s3

[Richard87]

As a new user, I was very supprised that this wasnt already the case, so following this! :)

What I expected was something like this:

  backups:
    pgbackrest:
      image: registry.developers.crunchydata.com/crunchydata/crunchy-pgbackrest:centos8-2.35-0
      repos:
        - name: repo1
          gcs:
            bucket: bucketName
           project: abcd1234
           secretKeyRef:
             name: gcs-secret
             key:  gcs.json

Which is the style of certmanager among others (for inspiration!)

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: example-issuer
spec:
  acme:
    ...
    solvers:
    - dns01:
        cloudDNS:
          # The ID of the GCP project
          project: $PROJECT_ID
          # This is the secret used to access the service account
          serviceAccountSecretRef:
            name: clouddns-dns01-solver-svc-acct
            key: key.json

https://cert-manager.io/docs/configuration/acme/dns01/

[cristianrat]

so I guess still not supported?

[lukastopiarz]

Any update? Password change via secret managed solely by PGO is not very flexible. We use gitops approach using ArgoCD and Bitnami sealed secrets, which is an unfortunate story. We have to create a Kyverno policy to patch pguser secret (Add sealed secrets annotation) and then patch password and verifier keys using sealed secret. Having an external secret and using secretKeyRef in the PG DB pod would be a clean and easy solution.