Secrets Management

The GoodData.CN helm chart uses several credentials which are stored in a plain text format directly in the chart. We do not recommend this setup for production environments as it is an insecure method of protecting data. Instead, proper secrets management should be used.

Provide existing secrets

It is possible to provide existing Kubernetes secrets with the required credentials. You can provide the credentials to the secrets in the following ways.

Postgres Admin Secrets

Required Format:

apiVersion: v1
kind: Secret
metadata:
  name: your-postgres-secret
type: Opaque
data:
  postgresql-password: "Zm9vYmFy"
  repmgr-password: "Q3RicU40WmVvWA=="

This secret is referenced in the GoodData.CN helm chart as shown below.

Installation with Included Postgres Helm Chart

You can reference the secret in the following ways:

deployPostgresHA: true
global:
  postgresql:
    existingSecret: your-postgres-secret
deployPostgresHA: true
postgresql-ha:
  postgresql:
    existingSecret: your-postgres-secret

Installation with external Postgres

deployPostgresHA: false
service:
  postgres:
    existingSecret: your-postgres-secret

Metadata Bootstrap secret

Required Format:

apiVersion: v1
kind: Secret
metadata:
  name: your-metadata-bootstrap-secret
type: Opaque
data:
  user: "Zm9vYmFy"
  password: "Q3RicU40WmVvWA=="

You can reference the secret in following way:

metadataApi:
  bootstrap:
    existingSecret: your-metadata-bootstrap-secret

Dedicated users and secrets for Postgres databases

GoodData.CN uses Postgres as internal database. There are two, respectively three databases, based on whether you choose to use the internal OIDC identity provider or not:

  • Metadata database
  • SqlExecutor database
  • The internal OIDC identity provider database

It is encouraged to use dedicated credentials on production environments.

Metadata Postgres database credentials

The Metadata Postgres credentials can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml and the password should be provided as a dedicated secret.

Required Format:

apiVersion: v1
kind: Secret
metadata:
  name: your-md-postgres-secret
type: Opaque
data:
  postgresql-password: "Zm9vYmFy"

You can set the Metadata user and reference the secret in the following way:

metadataApi:
  database:
    name: md
    user: 'md'
    password: ''
    existingSecret: your-md-postgres-secret

SqlExecutor Postgres database credentials

The SqlExecutor Postgres credentials can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml and the password should be provided as a dedicated secret.

Required Format:

apiVersion: v1
kind: Secret
metadata:
  name: your-sqlexec-postgres-secret
type: Opaque
data:
  postgresql-password: "Zm9vYmFy"

You can set the Metadata user and reference the secret in the following way:

sqlExecutor:
  database:
    name: execution
    user: 'execution'
    password: ''
    existingSecret: your-sqlexec-postgres-secret

Internal OIDC Identity Provider Postgres database credentials

The Postgres credentials for the internal OIDC identity provider can be supplied directly in the values.yaml. However, it is recommended to set only user in values.yaml and the password should be provided as a dedicated secret.

Required Format:

apiVersion: v1
kind: Secret
metadata:
  name: your-dex-postgres-secret
type: Opaque
data:
  postgresql-password: "Zm9vYmFy"

You can set the internal OIDC identity provider user and reference the secret in the following way:

  config:
    database:
      name: dex
      user: 'dex'
      password: ''
      existingSecret: your-dex-postgres-secret

Secrets management

GoodData.CN is un-opinionated about how secrets are managed as long they are secure. There are many ways to do it and there’s no one-size-fits-all solution. Here are some solutions for managing secrets: