DSM 2.2: Using the API to change the database admin password

Many of our customers have security policies in place which require all passwords to be rotated on a regular basis. Many of our customers are also looking at ways to automate this process, and avoid having to login via the DSM UI and update all of their database passwords manually. As you can imagine, doing this manually can be a very tedious task. Fortunately, there is way to automate this process via the DSM API for Postgres databases. In this post, I will demonstrate the steps involved to allow you to automate the changing of DSM provisioned database admin passwords via the API.

Step 1: Retrieve the kubeconfig from the DSM UI

As a DSM admin user, download the kubeconfig YAML file from the DSM Appliance UI. Set the KUBECONFIG environment variable to point to downloaded kubeconfig.

Step 2: Examine the database and passwords

Using the kubectl command, and referencing the downloaded kubeconfig, examine the manifest of the database where you wish to change the admin password (kubectl get postgresdatabase). When you examine a newly deployed postgres database which has been deployed with a default pgadmin password, you will notice that there is no reference to the password in the spec part of the database manifest.Note that when I say a database that has been deployed with a default pgadmin password, I mean that the DSM admin did not provide their own pgadmin password at deployment time, but allowed the system to choose one.

The only reference to a password field is in the status.connection.passwordRef.name field.

% kubectl describe postgrescluster demo-4-alex 
kind: PostgresCluster
metadata:
.
.
.
status:
  alertLevel: OK
  availableUpgrades:
  connection:
    dbname: demo-4-alex
    host: xx.yy.zz.217
    passwordRef:
      name: pg-demo-4-alex
    port: 5432
    username: pgadmin

This status.connection.passwordRef.name is a reference to a secret called pg-demo-4-alex.

% kubectl get secret pg-demo-4-alex
NAME                              CREATED AT
pg-demo-4-alex                    2025-02-14T10:45:35Z

This secret contains the current pgadmin password. It has been synchronised with the actual admin password. You can check using the following commands. The first returns the base64 encoded password, whilst the second one returns the decoded password. You can compare this to the database connection string.

% kubectl get secrets pg-demo-4-alex --template='{{.data.password}}'
WTIxVVRDTTRCRlJHNUdRZFZnM0UwMDdtWkxMOTNu%


% kubectl get secrets pg-demo-4-alex --template='{{.data.password}}' | base64 -d
Y21UTCM4BFRG5GQdVg3E007mZLL93n%

Step 3: Create a new secret and password

To change the pgadmin password, you must first create a new secret with the new password included in base64 encoding. Here is a sample secret called demo-4-alex-secret-new. The username is a base64 encoding of pgadmin (which is optional in this case), and the password is a base64 encoding of my new desired password.

apiVersion: v1
data:
  password: Vk13YXJlMTIzIQ==
  username: cGdhZG1pbg==
kind: Secret
metadata:
  annotations:
    dsm.vmware.com/owner: dsmadmin@rainpole.com
    dsm.vmware.com/owner-role: DSM_ADMIN
  name: demo-4-alex-secret-new
  namespace: default
type: kubernetes.io/basic-auth

The easiest way to create a new secret is to display a current secret (kubectl get secret <some-secret-name> -o yaml). Redirect the YAML output to a new file and edit it appropriately.

As mentioned, the username and password in this secret are both base64 encoded. You can decode it as follows, selecting the appropriate field from the yaml as shown here:

% kubectl get secret demo-4-alex-secret-new --template='{{.data.username}}'| base64 -d
pgadmin%

% kubectl get secret demo-4-alex-secret-new --template='{{.data.password}}'| base64 -d
helloworld

Step 4: Edit the database, add the new password entry

The next step is to edit the postgres cluster (kubectl edit postgresdatabase) and add a reference to the password/secret in the .spec.adminPasswordRef.name as shown here:

% kubectl edit postgrescluster demo-4-alex 
spec:
  adminPasswordRef:
    name: demo-4-alex-secret-new
  adminUsername: pgadmin
  backupConfig:
    backupRetentionDays: 30
    schedules:
    - name: default-full-backup
      schedule: 59 23 * * 6
      type: full
    - name: default-incremental-backup
      schedule: 59 23 1/1 * *
      type: incremental
.
.
.
  replicas: 0
  requestedSharedMemorySize: 64Mi
  storagePolicyName: vSAN Default Storage Policy
  storageSpace: 60Gi
  version: 14.15+vmware.v2.2.0
  vmClass:
  name: small

Step 5: Validate the password change

After making the edit to the database manifest, wait a few seconds so that the Kubernetes in DSM can reconcile the connect password secret with the new pgadmin secret. In this example, the .data.password field in the pg-demo-4-alex secret which we examined at the start of this process will change to reflect the new password “helloworld”.

Next, retrieve the database connection string via the DSM UI, it should show the new password: postgresql://pgadmin:helloworld%0A@xx.yy.zz.217:5432/demo-4-alex

For future password rotations, you can simply update the password at any time by editing the secret that was created (demo-4-alex-secret-new), replacing the .data.password field with a new base64 encoded password, saving it, and then waiting a few seconds for the connect reference to reconcile in the database.