Secret Management

The PostgreSQL instance deployed by the ska-db-oda-umbrella chart has authentication using a username and password.

The ska-db-oda-umbrella chart defines a template to create a Kubernetes Secrets that pulls a PGPASSWORD from Vault. This Secret is then used by the PGDBInstance to define the user’s password. See the Dev Portal for more details on Vault.

The ska-db-oda chart defines a similar Secret that can be used by clients of Postgres - e.g. the ska-db-oda application The Secret above used to provision the database could be reused, however this makes clear the distinction between the database and the application, and sets a pattern for the other applications to follow.

Other applications accessing the ODA

Within OSO, other applications such as ska-oso-services will also need the password to connect to the ODA.

These application could access the password by reusing the Secret that is deployed by the ska-db-oda chart however a better pattern would for each application to define its own Secret that is pulled from Vault.

envFrom:
  - configMapRef:
      name: {{ template "<application>.name" . }}-postgres-environment-{{ .Release.Name }}
  - secretRef:
      {{ if $.Values.global.oda.postgres.secret.existingSecret.name }}
      name: {{ $.Values.global.oda.postgres.secret.existingSecret.name }}
      {{ else }}
      name: {{ template "<application>.postgres-secret" . }}
      {{- end }}

With this the PGHOST, PGDATABASE, etc would come from the ConfigMap, as they are often dynamic with values being set in the pipeline. However this configuration also allows all the full set of PG_ environment varibles to be set via a Secret. This could be useful for an ITF deployment where the Postgres instance is managed externally and a Secret is already available with all the connection details.