Using TLS Encryption with CloudNativePG (CNPG)
Encryption has become essential in modern infrastructure. When working with databases, two main types of encryption come into play:
- At-rest encryption — where the database files stored on disk are encrypted.
- In-transit encryption (transport encryption) — where the connection between the database server and clients is encrypted, protecting data from eavesdropping, spoofing, and man-in-the-middle attacks.
This post focuses exclusively on transport encryption in CloudNativePG.
Encryption Modes in CloudNativePG
The CloudNativePG operator supports two primary modes for managing TLS certificates:
- Operator-managed mode — Certificates are fully handled and automatically renewed by the operator. They are signed by a dedicated Certificate Authority (CA) created by CloudNativePG.
- User-provided mode — You supply your own certificates (generated externally) and import them as Kubernetes Secrets. This mode also integrates smoothly with tools like cert-manager.
Setting Up TLS Encryption
Operator-Managed Mode (Default)
If you use the default operator-managed mode, no extra configuration is required. CloudNativePG automatically enables TLS encryption on the server side.
Here’s what happens behind the scenes:
- The operator creates a Kubernetes Secret named
-ca containing the Certificate Authority certificate. - It also creates a TLS Secret named
-server with the server certificate and private key. - These secrets are automatically mounted into the PostgreSQL pods.
To verify that TLS is active, connect to your database using psql (or any other client) and run:
\conninfo
You should see output similar to this:
my_db=> \conninfo
Connection Information
Parameter | Value
----------------------+------------------------
Database | my_db
Client User | my_db
Host | 127.0.0.1
Server Port | 5432
Options |
Protocol Version | 3.0
Password Used | true
GSSAPI Authenticated | false
Backend PID | 1016607281
SSL Connection | true
SSL Library | OpenSSL
SSL Protocol | TLSv1.3
SSL Key Bits | 256
SSL Cipher | TLS_AES_256_GCM_SHA384
SSL Compression | false
ALPN | postgresql
Superuser | off
Hot Standby | off
This confirms the connection is encrypted with a strong TLSv1.3 cipher.
For additional security, you can download the CA certificate from Kubernetes and configure your client to verify the server certificate using sslmode=verify-ca or sslmode=verify-full.
Replica connections are encrypted in exactly the same way. Certificate renewals happen seamlessly without any downtime.
For most non-production and many production environments, this built-in approach is more than sufficient.
User-Provided Certificates Mode
When you need full control — for example, to use a company-wide internal CA — you can provide your own certificates.
The official documentation explains the process in detail: User-provided certificates mode.
In summary, you create the necessary Secrets and reference them in your Cluster resource. CloudNativePG integrates cleanly with cert-manager if you prefer automated certificate lifecycle management.
How TLS Flows in Kubernetes with CloudNativePG
Here’s a visual overview of the TLS certificate flow in operator-managed mode:
This diagram shows how the operator provisions the certificates as Kubernetes Secrets, mounts them into the database pods, and enables secure client connections.
Final Thoughts
Securing your CloudNativePG cluster with TLS is straightforward — often just a matter of using the defaults. Whether you stick with the operator-managed certificates or bring your own, CloudNativePG makes transport encryption simple, reliable, and production-ready.
Have you tried TLS with CloudNativePG yet? Feel free to share your experience in the comments!
Did you find this post helpful? You can support me.
Related posts
- Databases – Postgresql – Pilot
- Databases – Postgresql – Gitea and PGBouncer
- Databases – Postgresql – PGbouncer
- CNPG – Cloud Native Postgresql – Pilot
- CNPG – considerations for migrating databases
- CNPG – installation
- CNPG – Installation – Roles and Databases
- CNPG – Installation – Database Import
- CNPG – Installation – Connection pooling
- CNPG – Installation – Monitoring
Author Profile
Latest entries
blog06.07.2026CNPG – Configuration – TLS Encryption- blog02.07.2026CNPG – Installation – Monitoring
- blog01.07.2026CNPG – Installation – Connection pooling
- blog27.06.2026CNPG – Installation – Database Import
