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):
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:
- In require sslmode: The secret must contain at least the tls.key private key, and the tls.crt public key, in PEM format.
- 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,
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-postresql-ssl-cert-secret --from-file=tls.crt \ --from-file=tls.key \ --from-file=ca.crt \ --from-literal=sslmode=[require|verify-ca|verify-full]
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.kubectl create secret generic <ibm-ban-secret> --from-literal=db-user=<user_name>
Note: Multiple certificates are supported in crt file.
What to do next
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
.