cloudnative-pg / charts

CloudNativePG Helm Charts
Apache License 2.0
137 stars 62 forks source link

Issue when setting up a new/existing secret for main user in the Cluster chart in case we are in a recovery #310

Open JulienVall3 opened 1 month ago

JulienVall3 commented 1 month ago

Hi, I'm trying to set an existing secret when I deploy a cluster chart in case we are in a recovery method (bootstrap.recovery).

Indeed, I can see in the doc Configure the application database that for the recovered cluster, we can configure the application database name and credentials with additional configuration. As mentioned in the section we can generate our own passwords, store them as secrets, and update the database to use the secrets. Or we can also let the operator generate a secret with a randomly secure password for use. I am in the case that I would like to generate my own secret when we are in a recovery method.

Following the documentation, this example configures the application database app with owner app and supplied secret app-secret :

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
[...]
spec:
  bootstrap:
    recovery:
      database: app
      owner: app
      secret:
        name: app-secret
      [...]

With this configuration, the following happens after recovery is complete:

1 - If database app doesn't exist, a new database app is created. 2 - If user app doesn't exist, a new user app is created. 3 - if user app isn't the owner of the database, user app is granted as owner of database app. 4- If the value of username matches the value of owner in the secret, the password of application database is changed to the value of password in the secret.

I can see too that in the template cluster chart folder the file charts/cluster/templates/_bootstrap.tpl that the parameters for bootstrap.recovery.database, bootstrap.recovery.owner and bootstrap.recovery.secret.name are not managed in the recovery section (only in bootstrap.initDb section).

I deploy the chart using terraform, and I set the parameters like this :

 resource "helm_release" "cnpg_cluster" {
  name       = var.cluster_name
  repository = "${path.module}/helm"
  chart      = "."
  namespace  = var.namespace

  # Main configuration
  [...]

  # Recovery method settings
  set {
      name  = "recovery.database"
      value = var.database_name # test
  }

  set {
      name  = "recovery.owner"
      value = var.username # test
  }

  set {
      name  = "recovery.secret.name"
      value = var.secret_name 
      # test-postgres secret is created outside the chart helm with terraform but deployed in the same namespace at the same time
  }
}

To give you more context, we are in the case of a recovery of a cluster named test cluster. The cluster was created like it was a new cluster. His main database is named test . For testing purpose, we want to deploy a new cluster from a backup of this cluster. So I deploy a new one, in recovery, using the object_store method . I call him recovered-test-cluster. So the recovery works well, I have no issue with this part that I can recovered all data from the initial test database of test-cluster. But we need in our case to set up a new secret for the test database.

So I follow your documentation in order to override this part in my recovered-test-cluster, but the chart still create and deploy the default app-secret (here named recovered-test-cluster-app with new credential for the app database with app user as owner).

I also configured the .spec.bootstrap.initdb section in order to test all case with the same value as .spec.recovery.

In our test phase for the recovered-test-cluster, we're deploying it on a kubernetes cluster that we turn off every evening (for cost reasons). When we restart the kubernetes cluster, however, I notice that the cloudnative-pg operator restarts my instance of my recovered-test-cluster and at that point, the right secret test-postgres is associated with my postgres cluster. Is it because I also configured the .spec.bootstrap.initdb section ?

Why isn't the association made directly on creation of my cluster when it's in recovery? Am I doing something wrong in my chart helm configuration?

Thank you.