Client TLS/SSL Connections v1
Please refer to the "Certificates" page for more details on how EDB Postgres for Kubernetes supports TLS certificates.
The EDB Postgres for Kubernetes 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 comes 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 instead of using 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 an
which is owned by a user called
app (you can change this convention through the
About CNP plugin for kubectl
Please refer to the "Certificates" section in the "EDB Postgres for Kubernetes 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 90 days 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 EDB Postgres for Kubernetes 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 EDB Postgres for Kubernetes operator, including:
sslcert: the TLS client public certificate
sslkey: the TLS client certificate private key
sslrootcert: the TLS Certification Authority certificate, that signed the certificate on the server to be used to verify the identity of the instances
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
using the necessary options. The PostgreSQL server is exposed through the read-write Kubernetes service. We will point
psql command to connect to this service: