Enhancement of PostgreSQL Secret Management to Improve GitOps Practices

[timbastin]

Summary

This merge request addresses a critical limitation in the current design, which does not allow for the definition of an existing PostgreSQL secret. As a result, sensitive information, such as passwords, must be hardcoded in cleartext within the values file, undermining GitOps practices, particularly the ability to securely encrypt secrets.

Key Changes:

• Support for referencing existing PostgreSQL secrets has been introduced, enabling the secure management of sensitive information.
• The need for hardcoding passwords has been eliminated, promoting better security practices.

Tests

A new deployment was created using a valid secret defined as follows:

apiVersion: v1
kind: Secret
metadata:
  name: postgresql-secret
  namespace: mage-ai
type: Opaque
stringData:
  adminPassword: "super-secret-admin-password"
  userPassword: "super-secret-password"
  replicationPassword: "super-secret-replication-password"
  connectionString: "postgresql://mageai:super-secret-password@postgresql:5432/mageai"

The values definition looks like this:

# values.yaml
postgresql:
  enabled: true
  auth:
    database: mageai
    username: mageai

    # either specify the password in cleartext (not recommended for gitops) or use an existing secret 
    # defining a cleartext password will override the secret

    # password: your_password

    # Use an existing secret for the password
    existingSecret: "postgresql-secret"
    # the keys in the secret to use
    secretKeys:
      adminPasswordKey: "adminPassword"
      userPasswordKey: "userPassword"
      replicationPasswordKey: "replicationPassword"
      # the connection string needs to match the database name and username defined above
      connectionStringKey: connectionString # postgresql://your_username:your_password@postgresql-service:5432/your_database