Client TLS/SSL ConnectionsFeedback
The Cloud Native PostgreSQL operator has been designed to work with TLS/SSL for both encryption in transit and
authentication, on server and client sides. Clusters created using the CNP operator come with a Certification
Authority (CA) to create and sign TLS client certificates. Through the
cnp plugin for
kubectl you can
issue a new TLS client certificate which can be used to authenticate a user in lieu of passwords.
Please refer to the following steps to authenticate via TLS/SSL certificates, which assume you have
installed a cluster using the cluster-example.yaml deployment manifest.
According to the convention over configuration paradigm, that file automatically creates a
which is owned by a user called
app (you can change this convention through the
!!! See also "About CNP plugin for kubectl"
Please refer to the "Certificates" section in the "Cloud Native PostgreSQL Plugin"
page for details on how to use the plugin for
You can create a certificate for the
app user in the
cluster-example PostgreSQL cluster as follows:
You can now verify the certificate with:
As you can see, TLS client certificates by default are created with one year of validity, and with a simple CN that
corresponds to the username in PostgreSQL. This is necessary to leverage the
cert authentication method for
Now we will test this client certificate by configuring a demo client application that connects to our Cloud Native PostgreSQL cluster.
The following manifest called
cert-test.yaml creates a demo Pod with a test application
in the same namespace where your database cluster is running:
This Pod will mount secrets managed by the Cloud Native PostgreSQL operator, including:
- TLS client certificate
- TLS client certificate private key
- TLS Certification Authority certificate
They will be used to create the default resources that
psql (and other libpq based applications like
requires to establish a TLS encrypted connection to the Postgres database.
psql searches for certificates inside the
~/.postgresql directory of the current user, but we can use
the sslkey, sslcert, sslrootcert options to point libpq to the actual location of the cryptographic material.
The content of the above files is gathered from the secrets that were previously created by using the
cnp plugin for
Now deploy the application:
Then we will use created Pod as PostgreSQL client to validate SSL connection and authentication using TLS certificates we just created.
A readiness probe has been configured to ensure that the application is ready when the database server can be reached.
You can verify that the connection works by executing an interactive
bash inside the Pod's container to run
psql using the necessary
options. The PostgreSQL server is exposed through the read-write Kubernetes service. We will point the
command to connect to this service: