Certificates v1
EDB Postgres for Kubernetes was designed to natively support TLS certificates. To set up a cluster, the operator requires:
- A server certification authority (CA) certificate
- A server TLS certificate signed by the server CA
- A client CA certificate
- A streaming replication client certificate generated by the client CA
Note
You can find all the secrets used by the cluster and their expiration dates in the cluster's status.
EDB Postgres for Kubernetes is very flexible when it comes to TLS certificates. It primarily operates in two modes:
- Operator managed – Certificates are internally managed by the operator in a fully automated way and signed using a CA created by EDB Postgres for Kubernetes.
- User provided – Certificates are generated outside the operator and imported in the cluster definition as secrets. EDB Postgres for Kubernetes integrates itself with cert-manager (See Cert-manager example.)
You can also choose a hybrid approach, where only part of the certificates is generated outside CNP.
Operator-managed mode
By default, the operator generates a single CA and uses it for both client and server certificates, which are then managed and renewed automatically.
Server certificates
Server CA secret
The operator generates a self-signed CA and stores it in a generic secret containing the following keys:
ca.crt
– CA certificate used to validate the server certificate, used assslrootcert
in clients' connection strings.ca.key
– The key used to sign the server SSL certificate automatically.
Server TLS secret
The operator uses the generated self-signed CA to sign a server TLS
certificate. It's stored in a secret of type kubernetes.io/tls
and configured
to be used as ssl_cert_file
and ssl_key_file
by the instances. This
approach enables clients to verify their identity and connect securely.
Server alternative DNS names
In addition to the default ones, you can specify DNS server alternative names as part of the generated server TLS secret.
Client certificates
Client CA secret
By default, the same self-signed CA as the server CA is used. The public part
is passed as ssl_ca_file
to all the instances so it can verify client
certificates it signed. The private key is stored in the same secret and used
to sign client certificates generated by the kubectl cnp
plugin.
Client `streaming_replica`` certificate
The operator uses the generated self-signed CA to sign a client certificate for
the user streaming_replica
, storing it in a secret of type
kubernetes.io/tls
. To allow secure connection to the primary instance, this
certificate is passed as sslcert
and sslkey
in the replicas' connection
strings.
User-provided certificates mode
Server certificates
If required, you can also provide the two server certificates, generating them using a separate component such as cert-manager. To use a custom server TLS certificate for a cluster, you must specify the following parameters:
serverTLSSecret
– The name of a secret of typekubernetes.io/tls
containing the server TLS certificate. It must contain both the standardtls.crt
andtls.key
keys.serverCASecret
– The name of a secret containing theca.crt
key.
Note
The operator still creates and manages the two secrets related to client certificates.
Note
If you want ConfigMaps and secrets to be reloaded by instances, you can add
a label with the key k8s.enterprisedb.io/reload
to it. Otherwise you must reload the
instances using the kubectl cnp reload
subcommand.
Example
Given the following files:
server-ca.crt
– The certificate of the CA that signed the server TLS certificate.server.crt
– The certificate of the server TLS certificate.server.key
– The private key of the server TLS certificate.
Create a secret containing the CA certificate:
Create a secret with the TLS certificate:
Create a PostgreSQL cluster referencing those secrets:
The new cluster uses the provided server certificates for TLS connections.
Cert-manager example
This simple example shows how to use cert-manager to set up a self-signed CA and generate the needed TLS server certificate:
Cert-manager creates a secret named my-postgres-server-cert
. It contains all
the needed files and can be referenced from a cluster as follows:
You can find a complete example using cert-manager to manage both server and client CA and certificates in the cluster-example-cert-manager.yaml deployment manifest.
Client certificate
If required, you can also provide the two client certificates, generating them using a separate component such as cert-manager or HashiCorp vault. To use a custom CA to verify client certificates for a cluster, you must specify the following parameters:
replicationTLSSecret
– The name of a secret of typekubernetes.io/tls
containing the client certificate for userstreaming_replica
. It must contain both the standardtls.crt
andtls.key
keys.clientCASecret
– The name of a secret containing theca.crt
key of the CA to use to verify client certificate.
Note
The operator still creates and manages the two secrets related to server certificates.
Note
As the cluster isn't in control of the client CA secret key, you can no
longer generate client certificates using kubectl cnp certificate
.
Note
If you want ConfigMaps and secrets to be automatically reloaded by
instances, you can add a label with the key k8s.enterprisedb.io/reload
to it. Otherwise,
you must reload the instances using the kubectl cnp reload
subcommand.
Cert-manager example
This simple example shows how to use cert-manager to set up a self-signed CA and generate the needed TLS server certificate:
Cert-manager creates a secret named my-postgres-client-cert
that contains all
the needed files. You can reference it from a cluster as follows:
You can find a complete example using cert-manager to manage both server and client CA and certificates in the cluster-example-cert-manager.yaml deployment manifest.