{"id":7314,"date":"2019-08-06T07:45:04","date_gmt":"2019-08-06T14:45:04","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=7314"},"modified":"2025-06-13T23:06:17","modified_gmt":"2025-06-14T06:06:17","slug":"autonomous-operator-1-2-0-public-connectivity","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/autonomous-operator-1-2-0-public-connectivity\/","title":{"rendered":"Autonomous Operator 1.2.0 Public Connectivity"},"content":{"rendered":"

In my previous article<\/a> I discussed\u2014from a high level\u2014the new Public Connectivity feature in Autonomous Operator 1.2.0.\u00a0 This was intentionally an abstract overview in order to coax the user to learn about the joys of DDNS, TLS and layer 3 Networking.<\/p>\n

Give a man a fish, and you feed him for a day. Teach a man to fish, and you feed him for a lifetime<\/p><\/blockquote>\n

Hopefully you have all invested the time to learn how to fish! (or at least ready to get your feet wet.)\u00a0 This article gives a practical tutorial on configuration of the Operator in order to be able to expose your Couchbase clusters safely on the public internet.<\/p>\n

Why Use This Feature?<\/h2>\n

Today’s tech startups are more cloud-focused than the traditional enterprise. Some would argue that the traditional enterprise is entrenched\u2014guarding data behind firewalls in private data centers\u2014and arguably, from a security standpoint, this is the correct thing to do.<\/p>\n

Increased cloud exposure, while a bigger risk, is also becoming less of a concern as time goes on.\u00a0 Cloud more importantly opens myriad doors to agility and innovation gains. Connecting public service offerings over the public internet is a huge benefit, and one that cannot be easily and economically achieved with services that live on-premises, hidden behind NAT boundaries.<\/p>\n

The one example that I am personally quite fond of, is the rise of Function as a Service (FaaS).\u00a0 Functions are short lived jobs (typically based on containers) that respond to stimuli and return a result.\u00a0 They are created on demand, and automatically scale horizontally instantaneously to handle the required workload.\u00a0 You can use public FaaS service offerings today, with no time wasted installing and configuring virtual or physical infrastructure.\u00a0 AWS Lambda is one such incarnation you may well be familiar with.<\/p>\n

Unless your function is pure (in the sense that it just processes data) it will require inputs, typically in the form of a database.\u00a0 These FaaS offerings, given they operate on the public internet, will also require a connection to a public database. Establishing private VPN tunnels between these services may be difficult or impossible.<\/p>\n

It is for these reasons\u2014interconnectivity, simplicity, and agility\u2014that we offer the option of public connectivity<\/em>.<\/p>\n

Security, Security, Security<\/h2>\n

A service placed on the public internet will be faced with scrutiny from malicious 3rd-party actors.\u00a0 The internet is awash with attempts to glean and exploit personal information. As a simple test, connect a UNIX system to the internet.\u00a0 Your SSH logs will fill up fairly quickly with attempts to access the machine using dictionaries of common\/stolen usernames and passwords. Firewalls will show attempts to scan for open ports.\u00a0 This is just the accepted normal, and has been for as long as I can remember.<\/p>\n

Databases in particular are honey pots to criminals trying to exploit systems in order to gain access to mailing lists for phishing attacks, or extract credit card details for fraud and identity theft. You quite simply have to make these services secure.<\/p>\n

The Public Connectivity feature of the Operator mandates the use of full end-to-end encryption.\u00a0 This prevents snoopers from seeing confidential information while on public networks. Digital certificates form a trust between clients and servers.\u00a0 A client will verify that a server is valid for the host name it tried to connect to, and that it is signed by a trusted certificate authority.<\/p>\n

The Operator allows the use of server certificate chains only, and does not act as a certificate authority, signing server certificates for individual servers as the topology changes.\u00a0 Acting as a CA would allow any certificate to be created and signed, so we opt for the safe approach. As a result, we support a wildcard certificate for the cluster as a whole. When using wildcard certificates we also need to use public DNS in order for the client to confirm that the client can verify the server certificate is valid for the host being contacted.<\/p>\n

This background gives us enough knowledge to begin deploying our database with public connectivity.<\/p>\n

Let’s Get Started<\/h2>\n

DNS<\/h3>\n

As discussed, we need to use public DNS in order to contact the Couchbase cluster nodes when using public connectivity.\u00a0 These can be bought relatively cheaply online from registrars such as Gandi<\/a>, GoDaddy<\/a>, Namecheap<\/a> etc.<\/p>\n

We also need to be able to use Dynamic DNS.\u00a0 As nodes are added and removed from our Couchbase cluster, we need corresponding entries to be added and removed from the DNS.\u00a0 They also need to be updated if public IP addresses of these nodes change. This is due to high performance, client-side sharding used by Couchbase clients and XDCR.\u00a0 We will be using the Kubernetes external-dns<\/a> service to perform DDNS updates.\u00a0 The link lists supported DDNS providers.\u00a0 Once you have purchased a DNS domain you will need to delegate its name servers to your chosen DDNS provider.\u00a0 My personal choice for this example is Cloudflare<\/a>. The final preparation step is the creation of an API key or other credentials for the external-dns controller to authenticate with the DDNS provider and control the DNS records required by the Couchbase cluster.<\/p>\n

TLS<\/h3>\n

For most people this is the most mystical part of the process.\u00a0 HTTPS web pages just work transparently, so there is little need to be concerned with this from day to day by the average user.\u00a0 I\u2019m not going to go into any detail (as that is for another post), but what we need to discuss are the main things that need to be tied to your chosen DNS configuration.<\/p>\n

I\u2019m using my personal DNS domain, spjmurray.co.uk<\/strong>, for this demonstration.\u00a0 I will be installing my Couchbase cluster in its own namespace called 6c3c0075-b44a-11e9-9518-4a8d7629c69a<\/strong>, and the cluster itself will be called couchbase<\/strong>. These are important parameters to know because they allow us to uniquely address a Couchbase cluster within our Kubernetes cluster.\u00a0 The Couchbase cluster will be configured so that its domain is couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk<\/strong>. The operator will require the creation of A records within this domain for each node as well as the Couchbase Web Console.<\/p>\n

Knowing our domain, we can now determine the DNS wildcard certificate subject alternative name *.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk<\/strong>.<\/p>\n

OpenVPN\u2019s EasyRSA tool is a simple method of generating certificates.\u00a0 First, clone the repository and initialize it.<\/p>\n

git clone https:\/\/github.com\/OpenVPN\/easy-rsa\r\n<\/pre>\n
cd easy-rsa\/easyrsa3\r\n<\/pre>\n
.\/easyrsa init-pki\r\n<\/pre>\n
Generate the CA certificate and key pair.\u00a0 If you recall, the CA\u2019s private key is used to digitally sign a server certificate. A client can then verify the server certificate is authentic with the CA\u2019s public key.\u00a0 This command will prompt you for a CA name and a password. After completion the CA certificate can be found in pki\/ca.crt<\/strong>.<\/p>\n
.\/easy-rsa build-ca\r\n<\/pre>\n
The server certificate and key pair are created next.\u00a0 When TLS is specified in your Couchbase cluster configuration the Operator will use TLS to communicate with the cluster.\u00a0 This prevents any passwords or sensitive data being transmitted in plain text. To support Kubernetes\u2019 private DNS names we need another DNS wildcard subject alternative name.\u00a0 The nopass<\/strong> option must also be specified so that the private key is not encrypted and can be read by Couchbase server. The following command will prompt for a password; this is the CA private key\u2019s password used to digitally sign the certificate.<\/p>\n
.\/easy-rsa --subject-alt-name=DNS:*.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.svc,DNS:*.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk build-server-full server nopass\r\n<\/pre>\n
You can verify that the certificate is as expected by examining it in OpenSSL:<\/p>\n
openssl x509 -in cert -noout -text\r\nCertificate:\r\n    Data:\r\n        Version: 3 (0x2)\r\n        Serial Number:\r\n            b8:a2:ab:74:2c:8a:88:bf:67:3f:a8:d3:9b:fd:09:19\r\n        Signature Algorithm: sha256WithRSAEncryption\r\n        Issuer: CN = Couchbase CA\r\n        Validity\r\n            Not Before: Aug  1 10:52:15 2019 GMT\r\n            Not After : Jul 29 10:52:15 2029 GMT\r\n        Subject: CN = Couchbase Server\r\n        Subject Public Key Info:\r\n            Public Key Algorithm: rsaEncryption\r\n                RSA Public-Key: (2048 bit)\r\n                Modulus:\r\n                    00:b8:85:b5:41:16:67:1f:79:32:4c:ed:e1:44:cc:\r\n                    55:65:db:a1:d1:99:6e:d1:d7:90:a6:5e:eb:4c:96:\r\n                    de:a4:70:dd:74:6c:76:13:75:01:5e:36:a2:5f:f0:\r\n                    8b:cd:e8:8b:bd:68:2a:f2:5c:e8:3c:78:6d:71:92:\r\n                    db:2c:58:7c:e7:40:a5:73:cc:cd:f4:b7:c8:69:16:\r\n                    d3:c5:15:18:c0:56:d9:b3:f6:86:c6:22:8b:05:22:\r\n                    77:c7:5c:ce:2a:3d:b8:e8:96:ea:c8:17:a8:3a:27:\r\n                    7b:94:66:a1:80:89:a2:8b:25:5b:ed:72:ac:d5:29:\r\n                    37:a1:e5:dd:9f:16:ac:a4:04:14:d8:89:cc:d0:08:\r\n                    f9:f1:58:1f:a7:fa:ee:2d:1a:e5:bd:03:ba:e7:9a:\r\n                    79:f7:10:d7:0f:9b:bc:f9:cc:c9:03:97:58:78:9f:\r\n                    68:78:b7:20:cf:5e:a8:67:7b:33:41:91:4a:8c:7c:\r\n                    44:1a:25:86:ca:15:eb:9a:25:5e:80:23:65:9b:7a:\r\n                    40:e4:55:c1:9c:93:c8:d6:72:e7:d8:d7:ac:dd:f9:\r\n                    92:a8:89:c1:bc:ff:1a:7d:a5:e9:ab:6b:b8:3e:c4:\r\n                    5f:b6:e6:30:45:5c:b4:5a:ce:fa:d9:12:28:ad:e6:\r\n                    39:7b:39:4b:2e:a2:2a:16:f8:64:36:75:7d:59:78:\r\n                    41:cf\r\n                Exponent: 65537 (0x10001)\r\n        X509v3 extensions:\r\n            X509v3 Key Usage: critical\r\n                Digital Signature, Key Encipherment\r\n            X509v3 Extended Key Usage: \r\n                TLS Web Server Authentication\r\n            X509v3 Basic Constraints: critical\r\n                CA:FALSE\r\n            X509v3 Subject Key Identifier: \r\n                B8:7D:84:E9:AE:DF:38:90:B4:B5:CC:82:EA:B5:38:D2:35:12:4C:3F\r\n            X509v3 Authority Key Identifier: \r\n                keyid:78:49:35:9B:B4:03:26:81:B4:5A:68:8C:94:18:CE:2A:5A:12:FE:EE\r\n\r\n            X509v3 Subject Alternative Name: \r\n                DNS:*.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.svc, DNS:*.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk\r\n    Signature Algorithm: sha256WithRSAEncryption\r\n         79:75:3c:81:ca:78:50:64:4b:4a:4c:67:9a:22:12:28:e6:76:\r\n         a0:00:18:87:0f:09:bc:18:28:fb:5c:06:52:51:91:fe:2b:5f:\r\n         9c:a2:0f:96:67:ec:0d:44:fd:e4:7d:cc:90:f5:5f:8a:9f:e1:\r\n         56:c1:aa:67:fb:fe:8d:6d:fa:fb:04:36:c4:cf:b6:24:ce:4d:\r\n         e8:87:d9:f0:40:b3:9b:7d:d1:a7:77:6a:1b:ea:11:67:46:14:\r\n         84:0b:37:0a:c1:35:b8:53:bd:98:58:3f:98:b5:20:d7:9c:0f:\r\n         99:eb:48:71:03:88:1b:8d:ef:b3:08:76:27:53:87:09:cd:4a:\r\n         5c:26:fc:bd:ad:82:e4:38:0b:6c:e1:8c:e8:61:8e:38:f5:c0:\r\n         aa:7c:69:b1:2d:f3:5e:85:8c:0f:42:fc:19:b0:aa:17:81:44:\r\n         54:6e:8f:5d:d7:1f:f6:27:5c:fc:a3:78:de:45:e2:d3:3e:30:\r\n         14:53:65:fd:01:07:e8:af:b9:a7:fd:04:fb:ec:79:2c:1b:b9:\r\n         d7:f2:d2:90:2c:6f:ac:ca:09:29:07:73:a3:88:c2:bc:d7:a6:\r\n         09:49:31:a6:5b:96:40:12:5e:6f:82:bd:32:7f:ba:dc:6c:ad:\r\n         d2:ed:a8:70:42:99:4e:6c:8a:4f:43:c3:a3:a0:70:42:ea:23:\r\n         e3:a5:61:60\r\n<\/pre>\n
EasyRSA creates private keys in the modern PKCS#7 format, however Couchbase Server only supports PKCS#1.\u00a0 To remedy this we need to convert formats.<\/p>\n
openssl rsa -in pki\/private\/server.key -out server.key.der -outform DER<\/pre>\n
openssl rsa -in server.key.der -inform DER -out server.key -outform PEM\r\n<\/pre>\n
Now that TLS is configured, collect your CA certificate and server certificate\/private key pair, as they will be needed when configuring your Couchbase cluster in a later step.<\/p>\n
DDNS Setup<\/h3>\n
Now we can start deploying some actual Kubernetes resources.\u00a0 First up, let’s create our namespace for the external-dns controller to run in and a service account to run as.<\/p>\n
kubectl create namespace 6c3c0075-b44a-11e9-9518-4a8d7629c69a<\/pre>\n
kubectl -n 6c3c0075-b44a-11e9-9518-4a8d7629c69a create serviceaccount external-dns<\/pre>\n
A role is required to grant permission for the external-dns controller to interrogate Kubernetes resources in the namespace it is running in.\u00a0 The role is bound to the service account that the external-dns controller will run as. I will use a cluster role in this example so it can be shared between all instances of the external-dns controller.\u00a0 It will be bound within the namespace, however, as the controller does not need access to all namespaces. OpenShift users: You will need admin privileges for role creation and binding, as they require privilege escalation, and for security reasons, cannot be performed by normal users.\u00a0 The role looks like the following:<\/p>\n
apiVersion: rbac.authorization.k8s.io\/v1\r\nkind: ClusterRole\r\nmetadata:\r\n  name: external-dns\r\nrules:\r\n- apiGroups:\r\n  - \"\"\r\n  resources:\r\n  - services\r\n  - pods\r\n  - nodes\r\n  verbs:\r\n  - get\r\n  - watch\r\n  - list\r\n<\/pre>\n
And is installed with the following:<\/p>\n
kubectl create -f external-dns-cluster-role.yaml<\/pre>\n
kubectl -n 6c3c0075-b44a-11e9-9518-4a8d7629c69a create rolebinding --clusterrole external-dns --serviceaccount 6c3c0075-b44a-11e9-9518-4a8d7629c69a:external-dns external-dns\r\n<\/pre>\n
The final step is to install the external-dns controller.\u00a0 We will configure it to look for services within the namespace.\u00a0 If a service has an annotation external-dns.alpha.kubernetes.io\/hostname<\/em> then the external-dns controller will create DNS A records in our DDNS provider mapping to the service\u2019s IP address.<\/p>\n
It is possible that multiple instances of external-dns are synchronizing DNS records to the same domain.\u00a0 If it sees a record that doesn\u2019t correspond to a service it is managing, it will delete it. To prevent two or more controllers from continuously adding their own and deleting others’ records, we add in a GUID so that the controller only responds to records it owns.\u00a0 For your curiosity, ownership is managed through DNS TXT records. The deployment YAML looks like the following. You should substitute your own Cloudflare API key and email address in the environment parameters.<\/p>\n
apiVersion: extensions\/v1beta1\r\nkind: Deployment\r\nmetadata:\r\n  name: external-dns\r\nspec:\r\n  selector:\r\n    matchLabels:\r\n      app: external-dns\r\n  template:\r\n    metadata:\r\n      labels:\r\n        app: external-dns\r\n    spec:\r\n      serviceAccountName: external-dns\r\n      containers:\r\n       - name: external-dns\r\n         image: registry.opensource.zalan.do\/teapot\/external-dns:latest\r\n         args:\r\n         - --source=service\r\n         - --domain-filter=spjmurray.co.uk\r\n         - --provider=cloudflare\r\n         - --txt-owner-id=6c3c0075-b44a-11e9-9518-4a8d7629c69a\r\n         env:\r\n         - name: CF_API_KEY\r\n           value: REDACTED\r\n         - name: CF_API_EMAIL\r\n           value: REDACTED\r\n<\/pre>\n
This can be created with the following:<\/p>\n
kubectl -n 6c3c0075-b44a-11e9-9518-4a8d7629c69a create -f external-dns.yaml\r\n<\/pre>\n
Check that the deployment is running and we are ready to install our Couchbase cluster.<\/p>\n
Install the Operator<\/h3>\n
This is covered extensively in the official documentation<\/a>.\u00a0 First, you will need to install the custom resource definitions.\u00a0 Then install the dynamic admission controller into a namespace of your choice and connect it to the Kubernetes API.<\/p>\n
The admission controller is a required component of the Operator 1.2.0 deployment.\u00a0 It applies default values to the cluster, and most importantly, does validation outside of the scope of native JSON schema validation.\u00a0 The most important validation it performs for this setup is ensuring that your DNS and TLS are configured correctly in your Couchbase cluster definition.<\/p>\n
The Operator is installed into the same namespace as the external-dns controller using a very similar process to the external-dns controller.<\/p>\n
Public Couchbase Cluster<\/h3>\n
The final step is actually the easiest.\u00a0 Here\u2019s the YAML definition:<\/p>\n
apiVersion: couchbase.com\/v1\r\nkind: CouchbaseCluster\r\nmetadata:\r\n  name: couchbase\r\nspec:\r\n  authSecret: 6c3c0075-b44a-11e9-9518-4a8d7629c69a\r\n  baseImage: couchbase\/server\r\n  version: enterprise-6.0.1\r\n  exposeAdminConsole: true\r\n  adminConsoleServiceType: LoadBalancer\r\n  adminConsoleServices:\r\n  - data\r\n  exposedFeatureServiceType: LoadBalancer\r\n  exposedFeatures:\r\n  - xdcr\r\n  - client\r\n  dns:\r\n    domain: 6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk\r\n  tls:\r\n    static:\r\n      operatorSecret: couchbase-ca\r\n      member:\r\n        serverSecret: couchbase-cert\r\n  servers:\r\n  - name: default\r\n    services:\r\n    - data\r\n    - index\r\n    - query\r\n    size: 3\r\n<\/pre>\n
The admin console and exposed features (per pod services) are exposed with new parameters that allow the service type to be specified.\u00a0 On this occasion I\u2019m running in GKE. When a LoadBalancer<\/strong> service is created it gets a public IP address associated with it.<\/p>\n
The new DNS setting, when specified, will annotate admin console and per-pod services with the labels understood by the external dns-controller.\u00a0 For the admin console setting this is console.${metadata.name}.${spec.dns.domain}<\/strong> for example.<\/p>\n
Finally, as we are using public connectivity and DNS, the dynamic admission controller will force us to use TLS.\u00a0 The TLS parameters are populated with secrets<\/a> containing the TLS certificates we created earlier for this cluster.<\/p>\n
Create the cluster and watch the status or Operator logs for completion.\u00a0 Eventually you should be able to connect to the console with the url https:\/\/console.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk:18091\/<\/strong> as load balancer IPs are allocated and DNS records are added.\u00a0 You can use this same address to establish XDCR remote clusters and bootstrap Couchbase client SDKs.\u00a0 Congratulations you have enabled public connectivity!<\/p>\n
Troubleshooting<\/h2>\n
Merely explaining how to configure public connectivity is half the job.\u00a0 You need to be able to determine where the problem lies before raising support cases.\u00a0 Given it\u2019s always the network\u2019s fault (well mostly), here are some tips to help you.<\/p>\n
DNS is not instantaneous, it takes time for records to appear, and it takes time for modifications to propagate as TTLs expire.\u00a0 To check that DNS is as expected, first look up the expected DNS names. Find the service names:<\/p>\n
kubectl -n 6c3c0075-b44a-11e9-9518-4a8d7629c69a get svc\r\nNAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                                                           AGE\r\ncouchbase                      ClusterIP      None                           8091\/TCP,18091\/TCP                                                26h\r\ncouchbase-0000-exposed-ports   LoadBalancer   10.40.8.108   34.66.243.123    18091:32281\/TCP,18092:32677\/TCP,11207:31661\/TCP,18093:32233\/TCP   26h\r\ncouchbase-0001-exposed-ports   LoadBalancer   10.40.6.37    35.232.231.230   18091:32171\/TCP,18092:31995\/TCP,11207:30711\/TCP,18093:31243\/TCP   26h\r\ncouchbase-0002-exposed-ports   LoadBalancer   10.40.4.46    35.238.213.211   18091:32117\/TCP,18092:30313\/TCP,11207:32609\/TCP,18093:32433\/TCP   26h\r\ncouchbase-srv                  ClusterIP      None                           11210\/TCP,11207\/TCP                                               26h\r\ncouchbase-ui                   LoadBalancer   10.40.13.78   35.238.226.107   18091:32508\/TCP                                                   26h\r\n<\/pre>\n
Look up the calculated DNS name:<\/p>\n
kubectl -n 6c3c0075-b44a-11e9-9518-4a8d7629c69a get svc couchbase-0000-exposed-ports -o yaml | grep external-dns.alpha.kubernetes.io\/hostname\r\n    external-dns.alpha.kubernetes.io\/hostname: couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk\r\n<\/pre>\n
Does the DNS A record exist?\u00a0 Does the IP address correspond to the service\u2019s public IP address?<\/p>\n
dig +short couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk\r\n34.66.243.123<\/pre>\n
Next you need to be sure that the requested ports are listening.\u00a0 We can check that the TLS enabled Admin port is listening and we can establish a TCP session on that port:<\/p>\n
nc -vz couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk 18091\r\nConnection to couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk 18091 port [tcp\/*] succeeded!\r\n<\/pre>\n
The final thing to do is establish whether TLS is working as expected using the CA certificate:<\/p>\n
openssl s_client -host couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk -port 18091 -CAfile ca.crt \r\nCONNECTED(00000005)\r\ndepth=1 CN = Couchbase CA\r\nverify return:1\r\ndepth=0 CN = Couchbase Server\r\nverify return:1\r\n---\r\nCertificate chain\r\n 0 s:CN = Couchbase Server\r\n   i:CN = Couchbase CA\r\n 1 s:CN = Couchbase CA\r\n   i:CN = Couchbase CA\r\n---\r\nServer certificate\r\n-----BEGIN CERTIFICATE-----\r\nMIIDuDCCAqCgAwIBAgIRALiiq3Qsioi\/Zz+o05v9CRkwDQYJKoZIhvcNAQELBQAw\r\nFzEVMBMGA1UEAxMMQ291Y2hiYXNlIENBMB4XDTE5MDgwMTEwNTIxNVoXDTI5MDcy\r\nOTEwNTIxNVowGzEZMBcGA1UEAxMQQ291Y2hiYXNlIFNlcnZlcjCCASIwDQYJKoZI\r\nhvcNAQEBBQADggEPADCCAQoCggEBALiFtUEWZx95Mkzt4UTMVWXbodGZbtHXkKZe\r\n60yW3qRw3XRsdhN1AV42ol\/wi83oi71oKvJc6Dx4bXGS2yxYfOdApXPMzfS3yGkW\r\n08UVGMBW2bP2hsYiiwUid8dczio9uOiW6sgXqDone5RmoYCJooslW+1yrNUpN6Hl\r\n3Z8WrKQEFNiJzNAI+fFYH6f67i0a5b0DuueaefcQ1w+bvPnMyQOXWHifaHi3IM9e\r\nqGd7M0GRSox8RBolhsoV65olXoAjZZt6QORVwZyTyNZy59jXrN35kqiJwbz\/Gn2l\r\n6atruD7EX7bmMEVctFrO+tkSKK3mOXs5Sy6iKhb4ZDZ1fVl4Qc8CAwEAAaOB+jCB\r\n9zAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwDAYDVR0TAQH\/\r\nBAIwADAdBgNVHQ4EFgQUuH2E6a7fOJC0tcyC6rU40jUSTD8wHwYDVR0jBBgwFoAU\r\neEk1m7QDJoG0WmiMlBjOKloS\/u4wgYEGA1UdEQR6MHiCNCouY291Y2hiYXNlLjZj\r\nM2MwMDc1LWI0NGEtMTFlOS05NTE4LTRhOGQ3NjI5YzY5YS5zdmOCQCouY291Y2hi\r\nYXNlLjZjM2MwMDc1LWI0NGEtMTFlOS05NTE4LTRhOGQ3NjI5YzY5YS5zcGptdXJy\r\nYXkuY28udWswDQYJKoZIhvcNAQELBQADggEBAHl1PIHKeFBkS0pMZ5oiEijmdqAA\r\nGIcPCbwYKPtcBlJRkf4rX5yiD5Zn7A1E\/eR9zJD1X4qf4VbBqmf7\/o1t+vsENsTP\r\ntiTOTeiH2fBAs5t90ad3ahvqEWdGFIQLNwrBNbhTvZhYP5i1INecD5nrSHEDiBuN\r\n77MIdidThwnNSlwm\/L2tguQ4C2zhjOhhjjj1wKp8abEt816FjA9C\/BmwqheBRFRu\r\nj13XH\/YnXPyjeN5F4tM+MBRTZf0BB+ivuaf9BPvseSwbudfy0pAsb6zKCSkHc6OI\r\nwrzXpglJMaZblkASXm+CvTJ\/utxsrdLtqHBCmU5sik9Dw6OgcELqI+OlYWA=\r\n-----END CERTIFICATE-----\r\nsubject=CN = Couchbase Server\r\n\r\nissuer=CN = Couchbase CA\r\n\r\n---\r\nNo client certificate CA names sent\r\nPeer signing digest: SHA256\r\nPeer signature type: RSA\r\nServer Temp Key: DH, 2048 bits\r\n---\r\nSSL handshake has read 2714 bytes and written 737 bytes\r\nVerification: OK\r\n---\r\nNew, TLSv1.2, Cipher is DHE-RSA-AES256-SHA256\r\nServer public key is 2048 bit\r\nSecure Renegotiation IS supported\r\nCompression: NONE\r\nExpansion: NONE\r\nNo ALPN negotiated\r\nSSL-Session:\r\n    Protocol  : TLSv1.2\r\n    Cipher    : DHE-RSA-AES256-SHA256\r\n    Session-ID: 1D4242B756A51A14F1CA360DD7BB2DB74CEB4897E3365576658D2E5A7C7B36A0\r\n    Session-ID-ctx: \r\n    Master-Key: 11D43F8E21FD57A07D091913A892D1BBEC32A701491FCE0EAA1EAEA68084F3754CA746921F9E80FBA3EDB4F809A791A7\r\n    PSK identity: None\r\n    PSK identity hint: None\r\n    SRP username: None\r\n    Start Time: 1564751720\r\n    Timeout   : 7200 (sec)\r\n    Verify return code: 0 (ok)\r\n    Extended master secret: no\r\n---\r\n<\/pre>\n
Additionally, for the particularly brave, you can check that the DNS addresses passed to the clients are correct:<\/p>\n
curl -s https:\/\/couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk:18091\/pools\/default\/nodeServices -u Administrator:BIH6mSJQ33jcIb24LZagxn0GHpxsJEWiiXSHNnyoXxp2GITJWMgc4aEOxVVllcCR --cacert ca.crt | python -m json.tool\r\n{\r\n    \"nodesExt\": [\r\n        {\r\n            \"alternateAddresses\": {\r\n                \"external\": {\r\n                    \"hostname\": \"couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.spjmurray.co.uk\"\r\n                }\r\n            },\r\n            \"hostname\": \"couchbase-0000.couchbase.6c3c0075-b44a-11e9-9518-4a8d7629c69a.svc\",\r\n            \"services\": {\r\n                \"capi\": 8092,\r\n                \"capiSSL\": 18092,\r\n                \"indexAdmin\": 9100,\r\n                \"indexHttp\": 9102,\r\n                \"indexHttps\": 19102,\r\n                \"indexScan\": 9101,\r\n                \"indexStreamCatchup\": 9104,\r\n                \"indexStreamInit\": 9103,\r\n                \"indexStreamMaint\": 9105,\r\n                \"kv\": 11210,\r\n                \"kvSSL\": 11207,\r\n                \"mgmt\": 8091,\r\n                \"mgmtSSL\": 18091,\r\n                \"moxi\": 11211,\r\n                \"n1ql\": 8093,\r\n                \"n1qlSSL\": 18093,\r\n                \"projector\": 9999\r\n            },\r\n            \"thisNode\": true\r\n        },\r\n<\/pre>\n
Next Steps<\/h2>\n
Couchbase Autonomous Operator 1.2.0 is a big release with many new features.\u00a0 The main focuses are upgradability and ease of use. We hope you enjoy doing cool new things with it as much as we have enjoyed creating it.\u00a0 As always your feedback is key!<\/p>\n