Support reading all PostgreSQL connection parameters from Kubernetes secrets

Summary

The GitLab Helm chart currently only supports reading the PostgreSQL password from a Kubernetes secret, while other connection parameters (host, port, database, username) must be provided as plain text values. This limitation makes it difficult to integrate with database operators that manage all connection details dynamically.

Problem Description

Modern Kubernetes database operators (like Crunchy Postgres Operator, Zalando Postgres Operator, etc.) create databases dynamically and provide all connection information in a single Kubernetes secret. For example, the Crunchy Postgres Operator creates a secret with the following structure:

apiVersion: v1
kind: Secret
metadata:
  name: myapp-pguser-myapp
data:
  host: <base64-encoded-host>
  port: <base64-encoded-port>
  dbname: <base64-encoded-database>
  user: <base64-encoded-username>
  password: <base64-encoded-password>
  uri: <base64-encoded-connection-uri>

Currently, to use such an operator-managed database with GitLab, we must:

  1. Manually decode the secret values
  2. Hardcode them in the Helm values
  3. Only reference the secret for the password
global:
  psql:
    host: postgres-cluster-primary.namespace.svc  # Hardcoded
    port: 5432                                     # Hardcoded
    database: gitlabhq_production                  # Hardcoded
    username: gitlab                               # Hardcoded
    password:
      useSecret: true
      secret: gitlab-pguser-gitlab
      key: password

This approach has several disadvantages:

  • Defeats the purpose of operator-managed databases
  • Requires manual intervention when operator updates connection details
  • Increases risk of configuration drift
  • Makes GitOps workflows more complex

Proposed Solution

Add support for reading all PostgreSQL connection parameters from a Kubernetes secret:

global:
  psql:
    # New option: read all connection details from a secret
    connectionSecret:
      name: gitlab-pguser-gitlab
      hostKey: host          # Optional, defaults to "host"
      portKey: port          # Optional, defaults to "port"
      databaseKey: dbname    # Optional, defaults to "database"
      usernameKey: user      # Optional, defaults to "username"
      passwordKey: password  # Optional, defaults to "password"

This would be backward compatible - users could still use the existing configuration method.

Implementation Approach

The implementation would involve:

  1. Adding the new connectionSecret configuration structure to the values schema
  2. Updating the configuration templates to read from secrets when connectionSecret is provided
  3. Maintaining backward compatibility with the existing configuration method
  4. Adding appropriate documentation and examples

Offer to Contribute

I would be happy to submit a merge request implementing this feature if the approach is acceptable to the maintainers. Please let me know if you would like me to proceed with the implementation or if you have any feedback on the proposed solution.

Additional Context

This feature would greatly improve the GitLab Helm chart's compatibility with modern Kubernetes patterns and make it easier to adopt GitLab in environments using database operators.

/cc @gitlab-org/distribution/charts