Creating TLS Certificates
This section shows a simple way to create and manage a TLS certificate hierarchy.
Tutorials are accurate at the time of writing but rely heavily on third party software. Tutorials are provided to demonstrate how a particular problem may be solved. Use of third party software is not supported by Couchbase. For further help in the event of a problem, contact the relevant software maintainer.
Creating X.509 certificates is beyond the scope of this documentation and is given only for illustrative purposes only. Please consult the Couchbase Server documentation^ for additional details on certificate and TLS configuration.
EasyRSA by OpenVPN makes operating a public key infrastructure (PKI) relatively simple, and is the recommended method to get up and running quickly.
First clone the repository:
$ git clone https://github.com/OpenVPN/easy-rsa
Initialize and create the CA certificate/key. You will be prompted for a private key password and the CA common name (CN), something like Couchbase CA is sufficient. The CA certificate will be available as
$ cd easy-rsa/easyrsa3
$ ./easyrsa init-pki
$ ./easyrsa build-ca
You need to create a server wildcard certificate and key to be used on Couchbase Server pods.
The Operator will access pods using Kubernetes endpoint records, e.g.
Clients will access the cluster using Kubernetes service discovery records, e.g.
UI access will be with port-forwarding using
The following list contains the required set of DNS subject alternative names (SANs) that you will need to include in the Couchbase cluster certificate. The Operator dynamic admission controller enforces the presence of all of these SANs.
DNS:*.<cluster> DNS:*.<cluster>.<namespace> DNS:*.<cluster>.<namespace>.svc DNS:*.<cluster>.<namespace>.svc.cluster.local DNS:<cluster>.-srv DNS:<cluster>-srv.<namespace> DNS:<cluster>-srv.<namespace>.svc DNS:*.<cluster>-srv.<namespace>.svc.cluster.local DNS:localhost #DNS:*.<couchbaseclusters.spec.networking.dns.domain> (1)
|1||If you plan to configure public networking for the cluster, then you must add the wildcard SAN
SANs depend on search domains being configured for your stub resolver. By default, Kubernetes will do this for you. However, if you use the inter-Kubernetes networking with forwarded DNS networking model for connecting your clients, then you will need to configure this yourself.
For example, the FQDN for a Couchbase pod would be similar to
To generate a certificate for the cluster
cb-example in the
$ ./easyrsa --subject-alt-name='DNS:*.cb-example,DNS:*.cb-example.default,DNS:*.cb-example.default.svc,DNS:*.cb-example.default.svc.cluster.local,DNS:cb-example-srv,DNS:cb-example-srv.default,DNS:cb-example-srv.default.svc,DNS:*.cb-example-srv.default.svc.cluster.local,DNS:localhost' build-server-full couchbase-server nopass
The key/certificate pair can be found in
pki/issued/couchbase-server.crt and used as
tls.crt, respectively, in the
The use of passphrase protected keys require Server 7.1.
Passphrase protected keys may be generated with
openssl as PKCS#8 RSA formatted.
ca.key is required for the following steps to sign the server certificates.
Refer to EasyRSA section to initialize and create the CA certificate/key.
# create a private RSA key openssl genrsa -out key.pem 2048 # Convert to pkcs8 (enter encryption passphrase) openssl pkcs8 -topk8 -inform PEM -outform PEM -in key.pem -out key-pkcs8.pem # Use the key to create a signing request openssl req -new -newkey rsa:2048 -key key-pkcs8.pem -out server.csr -config csr.conf -sha256 # Send signing request to the CA to create the crt openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 -extensions v3_ext -extfile csr.conf -sha256 cp key-pkcs8.pem tls.key cp server.crt tls.crt
Ensure that the resulting
tls.key can be decrypted by running the following command:
$ openssl rsa -noout -modulus -text -in tls.key Enter pass phrase for tls.key: <passphrase>
Due to an issue with Couchbase Server’s private key handling, server keys may need to be PKCS#1 formatted.
This was addressed in Autonomous Operator 2.2 (and this tutorial) with the implementation of
However, if you are using legacy TLS configuration with
couchbaseclusters.spec.networking.tls.static, you will need to format the server keys in PKCS#1:
$ openssl rsa -in pkey.key -out pkey.key.der -outform DER
$ openssl rsa -in pkey.key.der -inform DER -out pkey.key -outform PEM
This section is only relevant if you wish to manually deploy the dynamic admission controller.
Most users should use
cao to automatically install the DAC.
To create a server certificate that can be used by the dynamic admission controller, simply specify the service name that the Kubernetes API webhooks will connect to.
This is in the form
<service>.<namespace>.svc, so if our service is called
couchbase-operator-admission and we were deploying it in the
operator-admission namespace, run the following:
$ ./easyrsa --subject-alt-name='DNS:couchbase-operator-admission.operator-admission.svc' build-server-full couchbase-admission-controller nopass`
This process is very similar to creating a server certificate.
Assuming the administrative user defined for Couchbase Server is
Administrator you can create a client certificate for the Operator to use with the following command:
$ ./easyrsa build-client-full Administrator nopass
The created files
pki/issued/Administrator.crt can be used as
tls.crt respectively when specifying the