Managing secrets to protect sensitive PostgreSQL SSL configuration data
About this task
The steps for creating the secret vary depending on whether your database enables server only or both server and client authentication.
There are 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 SSL mode (sslmode
), as
described in the following table.
sslmode | Eavesdropping protection | MITM protection | Description |
---|---|---|---|
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 you connect to a server you trust. |
verify-full | Yes | Yes | Network ensures that you connect to the server you specify. |
For more information about the SSL modes, see https://jdbc.postgresql.org/documentation/ssl/.
verify-ca
or verify-full
SSL options when FIPS is enabled. Use the
require
SSL mode option.ca.cert
) in PEM format and run the following
command:kubectl create secret generic <your-secret-name> \
--from-file=ca.crt=`<your-server-certification-name>.crt` \
--from-literal=sslmode=[require|verify-ca|verify-full]
To establish certificate-based authentication, you must create an SSL secret in the following way.
- In
require
sslmode: The secret must contain at least thetls.key
private key, and thetls.crt
public key, in PEM format. - In
verify-ca
orverify-full
sslmode: In addition to thetls.key
private key and thetls.crt
public key, the secret must contain theca.crt
certificate of the PostgreSQL server Certificate Authority, in PEM format. Example:kubectl create secret generic <your-secret-name> \ --from-file=tls.crt=`<your-client-certification-name>.crt` \ --from-file=tls.key=`<your-client-key-name>.crt` \ --from-file=ca.crt=`<your-server-certification-name>.crt` \ --from-literal=sslmode=[require|verify-ca|verify-full]
In the <your-client-certification-name>.crt / <your-server-certification-name>.crt file, you can add multiple certificates like in the following example:
-----BEGIN CERTIFICATE-----
MIIGXTCCBU****
Kwa==
-----END CERTIFICATE-----
...
-----BEGIN CERTIFICATE-----
MIIGX****
Kws==
-----END CERTIFICATE-----
To define the secret for the database connection, you do not need to specify a password in
ibm-fncm-secret
secret. The DBUsername
key is sufficient. For
example:
kubectl create secret generic ibm-fncm-secret \
--from-literal=gcdDBUsername=<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 OpenShift console.
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.
dc_ssl_enabled: true
database_ssl_secret_name: "<postgresql ssl secret name>"
datasource_configuration:
# the candidate value is "db2" or "db2HADR" or "oracle" or "sqlserver" or "postgresql"
dc_ssl_enabled: true
dc_gcd_datasource:
dc_database_type: "postgresql"
...
database_ssl_secret_name: "ibm-postresql-ssl-cert-secret"
dc_os_datasources:
- 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-fncm-secret
.