.. _secret_management: 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. .. code-block:: yaml envFrom: - configMapRef: name: {{ template ".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 ".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.