Creating secrets to protect sensitive PostgreSQL SSL configuration data

If you plan to use SSL for your PostgreSQL database, create a secret manually to protect the certificate data for the database.

About this task

The steps for creating the secret vary depending on whether your database enables server only or both server and client authentication.

You have two types of PostgreSQL SSL configuration:

  • Traditional password authentication with a driver that automatically retrieves the certificate.
  • Certificate-based authentication PostgreSQL supports certificate-based authentication for increased security of your connections. Certificate-based authentication is only available for SSL connections. Instead of a password, the client must provide a valid certificate.

The verification level of the connection depends on the following SSL mode (sslmode):

Table 1. SSL modes
sslmode Eavesdropping protection MITM protection Purposes
require Yes No Network ensures that you always connect to the server you want.
verify-ca Yes Depends on the certificate authority (CA) policy Network ensures that you connect to a server you trust.
verify-full Yes No Network ensures that you connect to the server you specify.

For more information about the SSL modes, see https://jdbc.postgresql.org/documentation/ssl/.

Attention: Due to a dependency on JKS keystores, PostgreSQL JDBC data sources cannot use verify-ca or verify-full SSL options when FIPS is enabled. Use the require SSL mode option.

To establish certificate-based authentication, you must create an SSL secret in the following ways:

  1. In require sslmode: The secret must contain at least the tls.key private key, and the tls.crt public key, in PEM format.
  2. In verify-ca or verify-full sslmode: In addition to these two keys, the secret must contain the ca.crt certificate of the PostgreSQL server certificate authority, in PEM format. For example,
    kubectl create secret generic ibm-postresql-ssl-cert-secret --from-file=tls.crt \
    --from-file=tls.key \
    --from-file=ca.crt \
    --from-literal=sslmode=[require|verify-ca|verify-full]
    To define the secret for the database connection, you do not need to specify a password. The db-user key is sufficient. For example,
    kubectl create secret generic <ibm-ban-secret> --from-literal=db-user=<user_name>
    Make a note of the SSL secret name, so you can add it to the datasource_configuration section of the custom resource file or enter it in the user interface if you use the Red Hat OpenShift console.
    Note: Multiple certificates are supported in crt file.

What to do next

Use the name of your secret to create the configuration for an SSL database connection when you complete your CR YAML file.
The following values specify the SSL database configuration and provide the name of the SSL secret that you created:
dc_ssl_enabled: true
database_ssl_secret_name: "<postgresql ssl secret name>"
For example, for the relevant datasource for your Business Automation Navigator deployment, your CR might look like the following sample snip:
datasource_configuration:
    # the candidate value is "db2" or "db2HADR" or "oracle" or "sqlserver" or "postgresql"
    dc_ssl_enabled: true
    dc_icn_datasource:
      dc_database_type: "postgresql"
      ...
      database_ssl_secret_name: "ibm-postgresql-ssl-cert-secret"

Also remember to add the database username and password to the ibm-ban-secret.